From exim@www1.ietf.org Mon Mar 1 00:37:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06233 for ; Mon, 1 Mar 2004 00:37:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg6j-0006HN-C7 for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 00:36:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i215an4u024131 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 00:36:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg6j-0006H8-6L for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:36:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06211 for ; Mon, 1 Mar 2004 00:36:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axg6g-0003IA-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:36:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axg5m-0003Bh-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:35:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axg5G-00033y-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:35:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg51-0005ms-UW; Mon, 01 Mar 2004 00:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axg4X-0005lS-3o for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 00:34:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06026 for ; Mon, 1 Mar 2004 00:34:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axg4U-00031W-00 for ipv6@ietf.org; Mon, 01 Mar 2004 00:34:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axg3Y-0002wB-00 for ipv6@ietf.org; Mon, 01 Mar 2004 00:33:33 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Axg3I-0002qZ-00 for ipv6@ietf.org; Mon, 01 Mar 2004 00:33:16 -0500 Subject: RE: [2461bis issue 250] Reception of prefix option with prefix length > 64 Date: Mon, 1 Mar 2004 00:32:43 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [2461bis issue 250] Reception of prefix option with prefix length > 64 Thread-Index: AcP9AhmmJenR3jfsRpWf6uiGS4AsEACSy+8g From: "Soliman Hesham" To: "JINMEI Tatuya / ????" Cc: "IETF Mailing List" Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,SUBJ_HAS_SPACES autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Jinmei, But there is still the conflict between the address architecture and ND at the moment. It may not affect the actual ND spec but it seems like a confusing contradiction for someone trying to understand how the ADDRARCH and ND specs fit together. The was also mentioned in the IAB response to Robert Elz' appeal (i.e. that ND needs to be clarified or addr arch needs to be modified...). Hesham > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Friday, February 27, 2004 2:20 AM > To: Soliman Hesham > Cc: IETF Mailing List > Subject: Re: [2461bis issue 250] Reception of prefix option > with prefix length > 64 > > > Catching up an old topic... > > >>>>> On Tue, 10 Feb 2004 07:26:05 -0500, > >>>>> Soliman Hesham said: > > > What should a node do upon reception of a prefix option > with the prefix > > length set to a value >64? > > > The issue can be stated more accurately to say: > > What should a host do upon reception of a prefix option > with the prefix > > length set to a value != 64? > > You appear to focus on the address configuration side of this issue. > And RFC2461 is quite clear that the prefix handling in RFC2461 should > be separate from that in RFC2462, so I'd see this as a 2462bis issue > and not a 2461bis issue. > > Regarding rfc2461bis, my impression is that the receiving node must > accept an prefix information in terms of the ND (2461 or bis) part > regardless of the prefix length. > > For example, assuming a 64-bit interface identifier, if we receive an > RA containing an prefix information option with 80-bit prefix length > and with the L and A bits both being set, RFC2462 clearly says that > the prefix MUST be ignored in terms of address configuration: > > If the sum of the prefix length and interface > identifier length > does not equal 128 bits, the Prefix Information option MUST be > ignored. > (RFC2462 Section 5.5.3, ) > > However, I think the receiving node should still consider the prefix > as valid in terms of ND (i.e., consider it as "on-link") and modify > the next-hop determination accordingly. > > The questions are: > > 1. is this a correct understanding of the intention of RFC2461? > 2. if yes, is this a reasonable behavior? > 3. if yes (for both 1 and 2), should this explicitly be documented in > rfc2461bis? > > And my personal answers are: > > yes for 1 (of course. this is my understanding). > not sure for 2, but I don't oppose to the behavior (though I'll need > to change my own implementation). > probably yes for 3. > > 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 exim@www1.ietf.org Mon Mar 1 01:17:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08541 for ; Mon, 1 Mar 2004 01:17:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgjL-0003JU-Ts for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 01:16:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i216Gh9m012730 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 01:16:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgjL-0003JF-Nl for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 01:16:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08515 for ; Mon, 1 Mar 2004 01:16:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgjI-0007Tb-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 01:16:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgiS-0007ND-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 01:15:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axghv-0007GQ-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 01:15:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axghi-0002sR-N7; Mon, 01 Mar 2004 01:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axgh6-0002mI-Rk for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 01:14:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08346 for ; Mon, 1 Mar 2004 01:14:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axgh3-0007E5-00 for ipv6@ietf.org; Mon, 01 Mar 2004 01:14:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axgg5-000797-00 for ipv6@ietf.org; Mon, 01 Mar 2004 01:13:21 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Axgf5-00071d-00 for ipv6@ietf.org; Mon, 01 Mar 2004 01:12:20 -0500 Message-ID: <032701c3ff54$3a811660$3e6015ac@dclkempt40> From: "James Kempf" To: "Nick 'Sharkey' Moore" , Cc: References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Sun, 29 Feb 2004 22:12:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > My assumption is that SEND WG will adapt to the changes that RFC2462bis > will make. So if we tweak 2462 to require configuration of a link-local > address per suffix, SEND-CGA nodes will do this. This will then prevent > (well, detect) collision as discussed above. > SEND doesn't use a common suffix, so I am not sure how this applies to them. Basically, SEND will DAD all addresses. Could you clarify? > Why not just specify this in SEND then? Well, because it's a DAD > issue which applies to other protocols which would like to configure > one or more arbitrary suffixes, eg: privacy addressing. > SEND doesn't make changes in the basic DAD algorithm, so it will conform to whatever 2462bis specifies. Since the SEND spec is about to be sent to the IESG, the SEND WG needs to know if any changes are needed in the SEND spec right now. So far, I don't see any. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 02:58:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26929 for ; Mon, 1 Mar 2004 02:58:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiJr-0004O1-1h for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 02:58:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i217wU6U016861 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 02:58:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiJp-0004Nk-HL for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 02:58:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26867 for ; Mon, 1 Mar 2004 02:58:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiJl-0002H0-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 02:58:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiIo-000298-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 02:57:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxiHq-00022j-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 02:56:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiHT-0003pP-8M; Mon, 01 Mar 2004 02:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiH8-0003nu-6P for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 02:55:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26731 for ; Mon, 1 Mar 2004 02:55:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiH4-0001xf-00 for ipv6@ietf.org; Mon, 01 Mar 2004 02:55:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiGM-0001s9-00 for ipv6@ietf.org; Mon, 01 Mar 2004 02:54:54 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxiFi-0001kU-00 for ipv6@ietf.org; Mon, 01 Mar 2004 02:54:14 -0500 Received: from ocean.jinmei.org (unknown [2001:220:101a:224:202:2dff:fe6a:d20]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4300315214; Mon, 1 Mar 2004 16:54:13 +0900 (JST) Date: Mon, 01 Mar 2004 16:54:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: additional agenda item 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Sun, 29 Feb 2004 18:24:33 -0800 (PST), >>>>> Erik Nordmark said: > It would be good to ask (e.g. on the appsarea list - discuss@apps.ietf.org > I think) if there are applications that need other configuration information > than the list of interfaces/ifindicies (which we already have) and > a list of all IP address (which is what you are proposing). Fair enough, but let me make a quick check: is this a direct response to my request for a slot (positive or negative), or just a general input on this issue itself? > Is that all we need to add to avoid having applications use SIOCGIF > ioctls? Perhaps this is included in "IP address", but the prefix lengths/net masks of addresses will also be needed (I know applications that need this information). getifaddrs(3) can provide it. FYI: currently getifaddrs(3) provides the following information: char *ifa_name; /* Interface name */ u_int ifa_flags; /* Interface flags */ struct sockaddr *ifa_addr; /* Interface address */ struct sockaddr *ifa_netmask; /* Interface netmask */ struct sockaddr *ifa_broadaddr; /* Interface broadcast address */ struct sockaddr *ifa_dstaddr; /* P2P interface destination */ void *ifa_data; /* Address specific data */ The ifa_data field references address family specific data. For AF_LINK addresses it contains a pointer to the struct if_data (as defined in include file ) which contains various interface attributes and statistics. For all other address families, it contains a pointer to the struct ifa_data (as defined in include file ) which contains per-address interface statistics. 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 exim@www1.ietf.org Mon Mar 1 03:01:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27153 for ; Mon, 1 Mar 2004 03:01:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiM1-0004vv-59 for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 03:00:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2180jow018957 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 03:00:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiM0-0004vg-MG for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 03:00:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27110 for ; Mon, 1 Mar 2004 03:00:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiLw-0002a9-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 03:00:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiL7-0002St-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 02:59:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxiKO-0002LR-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 02:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiKM-0004Pp-8k; Mon, 01 Mar 2004 02:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxiK5-0004OY-1V for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 02:58:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26912 for ; Mon, 1 Mar 2004 02:58:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiK1-0002JD-00 for ipv6@ietf.org; Mon, 01 Mar 2004 02:58:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiJF-0002CO-00 for ipv6@ietf.org; Mon, 01 Mar 2004 02:57:53 -0500 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 1AxiIL-0001zH-00 for ipv6@ietf.org; Mon, 01 Mar 2004 02:56:57 -0500 Received: from [IPv6:::1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id E59EA8; Mon, 1 Mar 2004 10:09:00 +0200 (EET) In-Reply-To: <20040301055112.GA20621@zoic.org> References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, James Kempf From: Pekka Nikander Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Mon, 1 Mar 2004 16:56:17 +0900 To: "Nick 'Sharkey' Moore" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Nick, > My assumption is that SEND WG will adapt to the changes that RFC2462bis > will make. So if we tweak 2462 to require configuration of a > link-local > address per suffix, SEND-CGA nodes will do this. This will then > prevent > (well, detect) collision as discussed above. Well, strictly speaking, a (pure) SEND node cannot configure a link-local address with such a suffix, since the resulting address will not be a SEND address. The CGA test will fail. Let me clarify: 1. Say that a (pure, strict) SEND node configures a new global address P::A, where A is computed by the CGA algorithm: A = cga(public key, prefix P, other info) 2. If a SEND node now would like to configure a link local address fe80::A, it (strictly speaking) cannot do that, since for fe80 it MUST use a different suffix, L, where L = cga(public key, prefix fe80, other info). Putting that aside, a SEND node could well *defend* the address fe80::A for DAD/DIID purposes, but it would never actually use it. --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 03:50:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02933 for ; Mon, 1 Mar 2004 03:50:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axj7e-0002Rd-Vb for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 03:49:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i218nwji009390 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 03:49:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxikQ-0007oH-Qo for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 03:25:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01551 for ; Mon, 1 Mar 2004 03:25:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axik9-00054a-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 03:25:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxijG-0004x3-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 03:24:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxiiW-0004pm-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 03:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigq-0006QX-IP; Mon, 01 Mar 2004 03:22:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifw-0006HQ-6e for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 03:21:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01075 for ; Mon, 1 Mar 2004 03:21:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiYO-0003q4-00 for ipv6@ietf.org; Mon, 01 Mar 2004 03:13:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiXN-0003kC-00 for ipv6@ietf.org; Mon, 01 Mar 2004 03:12:29 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AxiWb-0003fx-00 for ipv6@ietf.org; Mon, 01 Mar 2004 03:11:41 -0500 Message-ID: <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> From: "James Kempf" To: "Pekka Nikander" , "Nick 'Sharkey' Moore" Cc: , References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Mon, 1 Mar 2004 00:12:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Putting that aside, a SEND node could well *defend* the address > fe80::A for DAD/DIID purposes, but it would never actually use it. > I think that's the issue. Should a SEND or 3041 node be required to defend LL addresses that use suffixes configured for their global unicast addresses even though they will never use the LL addresses? Since it's a backward compatibility issue, I think it would depend on how widely implemented DIID is. If it's not widely implemented, then there's no point in doing it. My personal feeling is that it is an extra bit of signaling that is unnecessary unless there is a widely deployed IPv6 capable OS out there that does DIID. In any event, the SEND spec doesn't need to change, because this behavior would have to be specified in RFC 2462bis since it would apply to 3041 nodes too or for that matter any node that used a different algorithm for configuring its suffix. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 04:33:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05044 for ; Mon, 1 Mar 2004 04:33:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axjmt-0006In-2M for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 04:32:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i219WYoI024219 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 04:32:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axjms-0006IY-NS for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 04:32:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04984 for ; Mon, 1 Mar 2004 04:32:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axjmp-0004HU-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 04:32:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axjly-00049w-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 04:31:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axjl3-00043D-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 04:30:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxjkT-0005q0-DA; Mon, 01 Mar 2004 04:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axjk3-0005ov-LR for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 04:29:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04883 for ; Mon, 1 Mar 2004 04:29:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axjk0-0003x8-00 for ipv6@ietf.org; Mon, 01 Mar 2004 04:29:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axjj5-0003sS-00 for ipv6@ietf.org; Mon, 01 Mar 2004 04:28:40 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Axjie-0003nC-00 for ipv6@ietf.org; Mon, 01 Mar 2004 04:28:12 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9BBF015210; Mon, 1 Mar 2004 18:28:12 +0900 (JST) Date: Mon, 01 Mar 2004 18:28:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "James Kempf" Cc: "Pekka Nikander" , "Nick 'Sharkey' Moore" , , Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) In-Reply-To: <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Mon, 1 Mar 2004 00:12:11 -0800, >>>>> "James Kempf" said: >> Putting that aside, a SEND node could well *defend* the address >> fe80::A for DAD/DIID purposes, but it would never actually use it. > I think that's the issue. Should a SEND or 3041 node be required to defend > LL addresses that use suffixes configured for their global unicast addresses > even though they will never use the LL addresses? > Since it's a backward compatibility issue, I think it would depend on how > widely implemented DIID is. If it's not widely implemented, then there's no > point in doing it. My personal feeling is that it is an extra bit of > signaling that is unnecessary unless there is a widely deployed IPv6 capable > OS out there that does DIID. > In any event, the SEND spec doesn't need to change, because this behavior > would have to be specified in RFC 2462bis since it would apply to 3041 nodes > too or for that matter any node that used a different algorithm for > configuring its suffix. I agree on all the points. And my conclusion still does not change: I don't see the need for any change on this in rfc2462bis. I don't know the deployment status of the DIID implementation, and we should be careful not to underestimate it. However, I think we should also consider the reality of the problematic case from an operational point of view. Recall the scenario I described again. The problem occurs when the DIID node *happens to* configure fe80::A and P::A. But can this really occur in a practical sense? In this particular case, "A" is a CGA identifier, so it cannot equal to a normal EUI-64 identifier. Also, "A" would look like a non-readable, random 64-bit number, so it should be very unlikely (in a practical sense) for the DIID node's administrator to use it as a manually assigned interface identifier. A similar argument should apply to the case of RFC3041. Meanwhile, if we agree on the proposed change in rfc2462bis (MUST do always DAD for each unicast address), new implementations will simply follow the requirement. Also, existing DIID implementations will gradually migrate to rfc2462bis. So, the actual odds to have the problem will get smaller and smaller (starting with very small odds). It should also be noted that one of the key motivations of the proposed change in rfc2462bis is to simplify the specification and implementation. If we introduce an additional defence algorithm to avoid the "compatibility" issue, the resulting specification will relatively complicated, degrading the effort to simply it. To summarize the points, I'd propose to do nothing on this in rfc2462bis because: - the actual odds of the problem in the real world should be very low, even in the current status. - if we take the proposed change in rfc2462bis, the odds will be getting lower and lower. - if we add something for this to rfc2462bis, the protocol will become complicated, degrading one of the motivations of this clarification. 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 exim@www1.ietf.org Mon Mar 1 05:54:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09115 for ; Mon, 1 Mar 2004 05:54:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl3i-0005Dh-9k for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 05:54:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21As2eO020063 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 05:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl3i-0005DW-0V for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 05:54:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08978 for ; Mon, 1 Mar 2004 05:53:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axl3e-0004w4-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 05:53:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axl2H-0004eg-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 05:52:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axl1G-0004U0-01 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 05:51:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxkzK-00052U-7Q for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 05:49:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axkyr-0004PW-Kq; Mon, 01 Mar 2004 05:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkyP-0004OY-Os for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 05:48:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08818 for ; Mon, 1 Mar 2004 05:48:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxkyM-0004JJ-00 for ipv6@ietf.org; Mon, 01 Mar 2004 05:48:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxkxP-0004FY-00 for ipv6@ietf.org; Mon, 01 Mar 2004 05:47:31 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Axkwd-0004C5-00 for ipv6@ietf.org; Mon, 01 Mar 2004 05:46:43 -0500 Message-ID: <03f301c3ff7a$90214ba0$3e6015ac@dclkempt40> From: "James Kempf" To: Cc: , "IPV6 WG" , "Nick 'Sharkey' Moore" , "Pekka Nikander" References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Mon, 1 Mar 2004 02:47:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I agree. jak ----- Original Message ----- From: )> To: "James Kempf" Cc: "Pekka Nikander" ; "Nick 'Sharkey' Moore" ; ; Sent: Monday, March 01, 2004 1:28 AM Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) > >>>>> On Mon, 1 Mar 2004 00:12:11 -0800, > >>>>> "James Kempf" said: > > >> Putting that aside, a SEND node could well *defend* the address > >> fe80::A for DAD/DIID purposes, but it would never actually use it. > > > I think that's the issue. Should a SEND or 3041 node be required to defend > > LL addresses that use suffixes configured for their global unicast addresses > > even though they will never use the LL addresses? > > > Since it's a backward compatibility issue, I think it would depend on how > > widely implemented DIID is. If it's not widely implemented, then there's no > > point in doing it. My personal feeling is that it is an extra bit of > > signaling that is unnecessary unless there is a widely deployed IPv6 capable > > OS out there that does DIID. > > > In any event, the SEND spec doesn't need to change, because this behavior > > would have to be specified in RFC 2462bis since it would apply to 3041 nodes > > too or for that matter any node that used a different algorithm for > > configuring its suffix. > > I agree on all the points. And my conclusion still does not change: > I don't see the need for any change on this in rfc2462bis. > > I don't know the deployment status of the DIID implementation, and we > should be careful not to underestimate it. However, I think we should > also consider the reality of the problematic case from an operational > point of view. > > Recall the scenario I described again. The problem occurs when the > DIID node *happens to* configure fe80::A and P::A. But can this > really occur in a practical sense? In this particular case, "A" is a > CGA identifier, so it cannot equal to a normal EUI-64 identifier. > Also, "A" would look like a non-readable, random 64-bit number, so it > should be very unlikely (in a practical sense) for the DIID node's > administrator to use it as a manually assigned interface identifier. > > A similar argument should apply to the case of RFC3041. > > Meanwhile, if we agree on the proposed change in rfc2462bis (MUST do > always DAD for each unicast address), new implementations will simply > follow the requirement. Also, existing DIID implementations will > gradually migrate to rfc2462bis. So, the actual odds to have the > problem will get smaller and smaller (starting with very small odds). > > It should also be noted that one of the key motivations of the > proposed change in rfc2462bis is to simplify the specification and > implementation. If we introduce an additional defence algorithm to > avoid the "compatibility" issue, the resulting specification will > relatively complicated, degrading the effort to simply it. > > To summarize the points, I'd propose to do nothing on this in > rfc2462bis because: > > - the actual odds of the problem in the real world should be very low, > even in the current status. > - if we take the proposed change in rfc2462bis, the odds will be > getting lower and lower. > - if we add something for this to rfc2462bis, the protocol will become > complicated, degrading one of the motivations of this clarification. > > 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 exim@www1.ietf.org Mon Mar 1 06:18:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10676 for ; Mon, 1 Mar 2004 06:18:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlQl-0008D2-Fi for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 06:17:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21BHpBC031550 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 06:17:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlQl-0008Cn-AH for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 06:17:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10665 for ; Mon, 1 Mar 2004 06:17:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxlQh-0007ZX-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 06:17:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxlPp-0007TE-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 06:16:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxlP9-0007MH-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 06:16:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlP1-0007je-Nr; Mon, 01 Mar 2004 06:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlOe-0007gH-OA for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 06:15:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10488 for ; Mon, 1 Mar 2004 06:15:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxlOa-0007I7-00 for ipv6@ietf.org; Mon, 01 Mar 2004 06:15:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxlNX-0007By-00 for ipv6@ietf.org; Mon, 01 Mar 2004 06:14:31 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AxlMW-00073Q-00 for ipv6@ietf.org; Mon, 01 Mar 2004 06:13:29 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 08FDD7024EC; Mon, 1 Mar 2004 22:13:26 +1100 (EST) Date: Mon, 1 Mar 2004 22:13:26 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Message-ID: <20040301111326.GA22558@zoic.org> Mail-Followup-To: ipv6@ietf.org, "JINMEI Tatuya / ?$B?@L@C#:H" References: <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-03-01, JINMEI Tatuya / ?$B?@L@C#:H wrote: > I don't see the need for any change on this in rfc2462bis. Okay, no worries, I'm happy too: I had assumed the DIID behaviour was widespread. >[...] In this particular case, "A" is a > CGA identifier, so it cannot equal to a normal EUI-64 identifier. I had not thought of this! So it is not a problem at all. In that case I'm entirely happy to go with just raising SHOULD to MUST and deleting the text explaining DIID. Sorry to have wasted your time ... -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 08:50:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19424 for ; Mon, 1 Mar 2004 08:50:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axno7-0006dr-SS for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 08:50:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Do7wt025500 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 08:50:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axno5-0006cv-Ez for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 08:50:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19386 for ; Mon, 1 Mar 2004 08:50:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axno4-0001pp-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 08:50:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axnn3-0001dM-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 08:49:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axnls-0001Nq-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 08:47:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axnls-0006pT-VB for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 08:47:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxnlH-00069n-AC; Mon, 01 Mar 2004 08:47:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axnkx-00063i-5j for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 08:46:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18925 for ; Mon, 1 Mar 2004 08:46:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axnkv-0001A5-00 for ipv6@ietf.org; Mon, 01 Mar 2004 08:46:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxnjI-0000oD-00 for ipv6@ietf.org; Mon, 01 Mar 2004 08:45:10 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxnhW-0000Sp-00 for ipv6@ietf.org; Mon, 01 Mar 2004 08:43:18 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 527A615214; Mon, 1 Mar 2004 22:43:11 +0900 (JST) Date: Mon, 01 Mar 2004 22:43:23 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: additional agenda item 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Mon, 1 Mar 2004 00:08:54 -0800 (PST), >>>>> Erik Nordmark said: >> Fair enough, but let me make a quick check: is this a direct response >> to my request for a slot (positive or negative), or just a general >> input on this issue itself? > Latter. > On the former; Getting the API for the list of addresses documented seems > quite useful so I think it makes sense spending face time on this. Understood, and thanks. >> u_int ifa_flags; /* Interface flags */ > Aren't the flags implementation specific? I'm not sure, but probably yes, it is implementation specific. >> The ifa_data field references address family specific data. For AF_LINK >> addresses it contains a pointer to the struct if_data (as defined in >> include file ) which contains various interface attributes and >> statistics. For all other address families, it contains a pointer to >> the struct ifa_data (as defined in include file ) which >> contains per-address interface statistics. > The actual statistics that are provided might be implementation specific. Again, probably correct. > Do we want an API that can be provided for non-BSD IP stacks? Windows? If we agree on the need for this kind of API, I believe it should be portable, that is, it should work for non-BSD, Windows, or whatever. So, the resulting API might lose some of the information that the current getifaddrs(3) library can provide. But I'd rather be happier to have a portable API. 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 exim@www1.ietf.org Mon Mar 1 11:44:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19426 for ; Mon, 1 Mar 2004 11:42:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqUg-0007b0-Vs for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 11:42:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21GgE29029191 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 11:42:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqUg-0007a8-4h for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 11:42:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18745 for ; Mon, 1 Mar 2004 11:42:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqGK-0003fP-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 11:27:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxqDm-0002V4-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 11:24:47 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxqAz-0001sV-01 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 11:21:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axpvp-0000mp-3J for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 11:06:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpvm-0002VK-J8; Mon, 01 Mar 2004 11:06:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpv8-0002CT-4f for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 11:05:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13481 for ; Mon, 1 Mar 2004 11:05:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axplf-000155-00 for ipv6@ietf.org; Mon, 01 Mar 2004 10:55:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxpdX-0005xi-00 for ipv6@ietf.org; Mon, 01 Mar 2004 10:47:21 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxpIL-00079T-00 for ipv6@ietf.org; Mon, 01 Mar 2004 10:25:25 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1015715210; Tue, 2 Mar 2004 00:25:23 +0900 (JST) Date: Tue, 02 Mar 2004 00:25:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Nick 'Sharkey' Moore" Cc: ipv6@ietf.org Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) In-Reply-To: <20040301111326.GA22558@zoic.org> References: <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> <20040301111326.GA22558@zoic.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Mon, 1 Mar 2004 22:13:26 +1100, >>>>> "Nick 'Sharkey' Moore" said: >> [...] In this particular case, "A" is a >> CGA identifier, so it cannot equal to a normal EUI-64 identifier. > I had not thought of this! So > it is not a problem at all. > In that case I'm entirely happy > to go with just raising SHOULD > to MUST and deleting the text > explaining DIID. Okay, I'm happy to reach the consensus, too. > Sorry to have wasted your time ... No need for an apology, you identified an issue that no one has ever imagined, and I think the discussion so far was really productive. Thanks for taking your time. 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 exim@www1.ietf.org Mon Mar 1 14:56:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01709 for ; Mon, 1 Mar 2004 14:56:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtWB-000506-Mn for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 14:56:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21JtxBQ019213 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 14:55:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqU5-0007HU-II for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 11:41:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16691 for ; Mon, 1 Mar 2004 11:25:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axq2c-0007bc-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 11:13:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axpzh-0006fi-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 11:10:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axpvb-00053K-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 11:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpum-00020U-Aq; Mon, 01 Mar 2004 11:05:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpud-0001wo-EP for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 11:05:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13034 for ; Mon, 1 Mar 2004 11:04:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxprX-0003Hp-00 for ipv6@ietf.org; Mon, 01 Mar 2004 11:01:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxpkD-0000We-00 for ipv6@ietf.org; Mon, 01 Mar 2004 10:54:16 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxpbN-0005Gr-00 for ipv6@ietf.org; Mon, 01 Mar 2004 10:45:05 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AC39C15210; Tue, 2 Mar 2004 00:45:04 +0900 (JST) Date: Tue, 02 Mar 2004 00:45:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jari Arkko Cc: ipv6@ietf.org Subject: Re: Optimistic DAD _again!_ In-Reply-To: <4041E313.6060307@kolumbus.fi> References: <002a01c3fa09$a308f9f0$67cadba8@LocalHost> <4041E313.6060307@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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Sun, 29 Feb 2004 15:03:15 +0200, >>>>> Jari Arkko said: > Most or maybe even all of these aspects are being worked by different > groups. For instance, (snip) > Does this count as a "comprehensive scenario" you were looking > for? I think so, thanks for the list. In the optimistic DAD slot on Tuesday, I want to see this kind of big picture, and how each of them is going to be addressed with consideration for effects to existing/future non-mobility nodes. BTW: to make my position clear, I do not object to the proposed optimistic DAD per se. I'm personally not so interested in eliminating the handoff delay, but my impression on the optimistic DAD draft (after reading it) is that it is very carefully trying to minimize the effect to non-mobility nodes. So, I agree that this can be a reasonable compromise. My point is that if we need to introduce an optimization on this I'd like to be sure this is a part of a reasonable big picture. This is because otherwise we'd just introduce additional complexity, even if it is only implemented in mobile nodes, as an incomplete solution (wrt "the big picture"). 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 exim@www1.ietf.org Mon Mar 1 15:39:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05310 for ; Mon, 1 Mar 2004 15:39:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxuBx-0000qz-0X for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 15:39:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Kd8h4003275 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 15:39:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxuBw-0000qk-Ob for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 15:39:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05305 for ; Mon, 1 Mar 2004 15:39:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxuBv-0005uO-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 15:39:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxuB2-0005o3-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 15:38:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxuAN-0005gn-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 15:37:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axu9s-0000Cj-UY; Mon, 01 Mar 2004 15:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axu8x-0000Aq-M7 for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 15:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05075 for ; Mon, 1 Mar 2004 15:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axu8w-0005WJ-00 for ipv6@ietf.org; Mon, 01 Mar 2004 15:36:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axu82-0005Oh-00 for ipv6@ietf.org; Mon, 01 Mar 2004 15:35:07 -0500 Received: from cs180204.pp.htv.fi ([213.243.180.204] helo=hades.pp.htv.fi ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Axu7A-0005Ff-00 for ipv6@ietf.org; Mon, 01 Mar 2004 15:34:13 -0500 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id i21KYoTg006154; Mon, 1 Mar 2004 22:34:51 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id i21KYmB7006153; Mon, 1 Mar 2004 22:34:48 +0200 Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) From: Mika Liljeberg To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= Cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org In-Reply-To: References: <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> <20040301111326.GA22558@zoic.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1078173287.904.12.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 01 Mar 2004 22:34:47 +0200 Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Mon, 2004-03-01 at 17:25, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: > Okay, I'm happy to reach the consensus, too. Futile though it may be, I would like to register disagreement. If the intention truly was to simplify the specification, we would be going to pure DIID. As it is, removing mention of DIID seems like a gratuitous change at best. As an author of one of those DIID implementations, I find this somewhat unfortunate. Also, there is the problem of DAD storms occurring whenever a new prefix appears on a link. Will the revision be introducing a random delay before a node begins the DAD procedure for each new address, or will that make the specification too complex? MikaL -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 18:12:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11902 for ; Mon, 1 Mar 2004 18:12:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axwa3-0005a7-3z for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 18:12:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21NCBaF021455 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 18:12:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axwa2-0005Zy-Ux for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 18:12:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11836 for ; Mon, 1 Mar 2004 18:12:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axwa0-0006iZ-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 18:12:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxwZ7-0006cP-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 18:11:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxwYU-0006WB-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 18:10:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwY1-0004Yk-4u; Mon, 01 Mar 2004 18:10:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axobt-00075J-5X for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 09:41:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28310 for ; Mon, 1 Mar 2004 09:41:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axobr-0004sn-00 for ipv6@ietf.org; Mon, 01 Mar 2004 09:41:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxoSo-0002V0-00 for ipv6@ietf.org; Mon, 01 Mar 2004 09:32:13 -0500 Received: from roof.dave.sonera.fi ([131.177.130.23]) by ietf-mx with esmtp (Exim 4.12) id 1AxoFS-0006kJ-00 for ipv6@ietf.org; Mon, 01 Mar 2004 09:18:22 -0500 Received: from roof.dave.sonera.fi (localhost [127.0.0.1]) by roof.dave.sonera.fi (Sendmail) with ESMTP id i21EIJkh006938 for ; Mon, 1 Mar 2004 16:18:20 +0200 (EET) Received: from kallio.eur.soneragroup.net (kallio.eur.soneragroup.net [131.177.121.200]) by roof.dave.sonera.fi (Sendmail) with ESMTP id i21EIJAL006935 for ; Mon, 1 Mar 2004 16:18:19 +0200 (EET) Received: from teliasonera.com ([192.194.74.152]) by kallio.eur.soneragroup.net with Microsoft SMTPSVC(5.0.2195.4905); Mon, 1 Mar 2004 16:18:19 +0200 Message-ID: <40434626.6030900@teliasonera.com> Date: Mon, 01 Mar 2004 16:18:14 +0200 From: Jyrki Soini Organization: TeliaSonera Finland User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: icmpv6-v3 comment Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2004 14:18:19.0851 (UTC) FILETIME=[0C08A1B0:01C3FF98] Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There is discussion and motivation why ICMPv6 error messages in general case MUST NOT be send in response to multicast packets. In contrast ICMP Echo Reply message has the following text: "An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast or anycast address. In this case, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received." Even though ping to multicast addresses has some operational use for instance to diagnose multicast propagation issues, I find it hard to justify this when comparing to potential risks as an DoS attack mechanism. Once we are updating the standard, should we make this behaviour deprecated and write instead: "An Echo Reply [SHOULD NOT| MAY] be sent in response to an Echo Request message sent to an IPv6 multicast or anycast address. If this potentially dangerous reply is sent, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received." Some other possible limitations could be: - echo reply to multicast packet only on link-local scope addresses - rate limit to very low accepted packet frequency --- Jyrki Soini -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 18:25:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12731 for ; Mon, 1 Mar 2004 18:25:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwmW-00083K-OH for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 18:25:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21NP4r2030948 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 18:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwmV-000835-UW for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 18:25:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12694 for ; Mon, 1 Mar 2004 18:25:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxwmT-0000At-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 18:25:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxwlZ-00003s-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 18:24:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axwkl-0007lb-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 18:23:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwkY-0007k1-51; Mon, 01 Mar 2004 18:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxwjZ-0007iB-0g for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 18:22:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12585 for ; Mon, 1 Mar 2004 18:21:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxwjW-0007bz-00 for ipv6@ietf.org; Mon, 01 Mar 2004 18:21:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxwiY-0007VZ-00 for ipv6@ietf.org; Mon, 01 Mar 2004 18:20:59 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axwhc-0007Le-00 for ipv6@ietf.org; Mon, 01 Mar 2004 18:20:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i21NJTr13749; Tue, 2 Mar 2004 01:19:29 +0200 Date: Tue, 2 Mar 2004 01:19:29 +0200 (EET) From: Pekka Savola To: Jyrki Soini cc: ipv6@ietf.org Subject: Re: icmpv6-v3 comment In-Reply-To: <40434626.6030900@teliasonera.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Jyrki Soini wrote: > "An Echo Reply [SHOULD NOT| MAY] be sent in response to an Echo > Request message > sent to an IPv6 multicast or anycast address. If this potentially > dangerous reply > is sent, the source address of the reply MUST be a unicast address > belonging to > the interface on which the Echo Request message was received." First, at this point, I'd leave anycast addresses as is. Second, I think with multicast debugging, the behaviour has to be consistent -- either you MUST answer or you MUST NOT. If you receive an answer from some nodes, but not from others, debugging will be difficult. So, whatever we choose (I don't have really strong opinions), it should be a MUST or MUST NOT. > - echo reply to multicast packet only on link-local scope addresses Or maybe only "global" or some other scope (e.g., "up to scope B") could be forbidden/rate-limited. The problem with rate-limiting is that it requires the separate timers, which some will argue must be configurable, causing more complexity than it's worth.. -- 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 exim@www1.ietf.org Mon Mar 1 18:48:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13698 for ; Mon, 1 Mar 2004 18:48:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx8n-0001z3-9F for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 18:48:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Nm5oD007619 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 18:48:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx8n-0001yo-4V for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 18:48:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13663 for ; Mon, 1 Mar 2004 18:48:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx8k-0002md-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 18:48:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axx7t-0002ga-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 18:47:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axx73-0002aE-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 18:46:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx6o-0001WE-Mq; Mon, 01 Mar 2004 18:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axx5s-0001KX-KE for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 18:45:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13464 for ; Mon, 1 Mar 2004 18:45:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axx5p-0002Sb-00 for ipv6@ietf.org; Mon, 01 Mar 2004 18:45:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axx55-0002NU-00 for ipv6@ietf.org; Mon, 01 Mar 2004 18:44:16 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1Axx48-00029a-00 for ipv6@ietf.org; Mon, 01 Mar 2004 18:43:16 -0500 Received: from ssprunk (ip145.post-vineyard.dfw.ygnition.net [66.135.181.145]) by ns2.sea (8.12.11/8.12.5) with SMTP id i21Ngdjh028934; Mon, 1 Mar 2004 15:42:40 -0800 Message-ID: <024001c3ffe6$e2ee60e0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Jyrki Soini" Cc: References: <40434626.6030900@teliasonera.com> Subject: Re: icmpv6-v3 comment Date: Mon, 1 Mar 2004 17:30:49 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" 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 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Jyrki Soini" > There is discussion and motivation why ICMPv6 error messages in general > case MUST NOT be send in response to multicast packets. In contrast > ICMP Echo Reply message has the following text: > > "An Echo Reply SHOULD be sent in response to an Echo Request message > sent to an IPv6 multicast or anycast address. In this case, the > source address of the reply MUST be a unicast address belonging to > the interface on which the Echo Request message was received." > > Even though ping to multicast addresses has some operational use for > instance to diagnose multicast propagation issues, I find it hard to justify > this when comparing to potential risks as an DoS attack mechanism. > Once we are updating the standard, should we make this behaviour > deprecated and write instead: How can this possibly be used as a DoS attack? Multicast inherently prevents source address spoofing, at least outside the sender's own subnet. 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 exim@www1.ietf.org Mon Mar 1 19:26:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15170 for ; Mon, 1 Mar 2004 19:26:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxjW-0005Gh-PQ for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 19:26:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220Q2Xa020245 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 19:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxjW-0005GM-I9 for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:26:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15109 for ; Mon, 1 Mar 2004 19:25:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxjU-0006pS-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:26:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxiW-0006hU-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:25:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axxha-0006al-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxha-0004mO-Kl; Mon, 01 Mar 2004 19:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxgc-0004Ql-Q9 for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 19:23:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14970 for ; Mon, 1 Mar 2004 19:23:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxgb-0006UH-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:23:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxfa-0006Lj-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:21:59 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1Axxec-00067y-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:20:58 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i220KSL27820 for ; Mon, 1 Mar 2004 16:20:28 -0800 Received: from innovationslab.net (WXP-LAPBRIANH.dhcp.ietf59.or.kr [218.37.230.133]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i220WcQP025758 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 1 Mar 2004 16:32:43 -0800 Message-ID: <4043D345.5050800@innovationslab.net> Date: Mon, 01 Mar 2004 19:20:21 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: IETF 59 IPv6 WG Document Status Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, The chairs have decided to handle document status differently at IETF 59. Rather than spending valuable meeting time on status, we have created a webpage with the current status of all documents. It is now available at: http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html If you have questions or comments on the status, feel free to raise them at the beginning of the meeting. This pointer will also be on the agenda slide prior to the beginning of the meeting. Regards, Brian & Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 19:42:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16468 for ; Mon, 1 Mar 2004 19:42:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxzD-0008FL-VO for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 19:42:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220gFqh031687 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 19:42:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxzA-0008En-QW for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:42:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16453 for ; Mon, 1 Mar 2004 19:42:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxz9-00015P-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:42:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxyF-0000yH-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:41:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxxU-0000rL-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:40:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxxF-0007sE-Te; Mon, 01 Mar 2004 19:40:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxwW-0007iq-Ep for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 19:39:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16152 for ; Mon, 1 Mar 2004 19:39:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxwU-0000iG-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:39:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxvf-0000Xs-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:38:35 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxuk-0000Jx-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:37:39 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i220auK15118; Tue, 2 Mar 2004 02:36:56 +0200 Date: Tue, 2 Mar 2004 02:36:56 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: ipv6@ietf.org Subject: Re: IETF 59 IPv6 WG Document Status In-Reply-To: <4043D345.5050800@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Brian Haberman wrote: > http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html What about the other work we should be doing, but isn't done yet (PPP updates, "link-scoped multicast", point-to-point link support, rfc3041bis, etc.) ? One comment: RFC Editor's Queue: * draft-ietf-ipv6-flow-label-09.txt This in AUTH state ("waiting for authors for something"). Any problems there? > > If you have questions or comments on the status, feel free to raise > them at the beginning of the meeting. This pointer will also be > on the agenda slide prior to the beginning of the meeting. > > Regards, > Brian & Bob > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- 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 exim@www1.ietf.org Mon Mar 1 19:49:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16899 for ; Mon, 1 Mar 2004 19:49:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy5w-0000sz-UE for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 19:49:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220nCBk003399 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 19:49:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy5w-0000sk-Oh for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:49:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16851 for ; Mon, 1 Mar 2004 19:49:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy5v-0001yk-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:49:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy51-0001ri-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:48:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axy4G-0001le-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:47:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy3q-00007D-7r; Mon, 01 Mar 2004 19:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axy3B-00006E-OI for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 19:46:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16659 for ; Mon, 1 Mar 2004 19:46:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axy39-0001c8-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:46:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axy2A-0001UH-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:45:19 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Axy1c-0001Mm-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:44:45 -0500 Received: from ocean.jinmei.org (unknown [2001:220:101a:224:202:2dff:fe6a:d20]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7C55F1521D; Tue, 2 Mar 2004 09:44:38 +0900 (JST) Date: Tue, 02 Mar 2004 09:44:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: IETF 59 IPv6 WG Document Status In-Reply-To: <4043D345.5050800@innovationslab.net> References: <4043D345.5050800@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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Mon, 01 Mar 2004 19:20:21 -0500, >>>>> Brian Haberman said: > The chairs have decided to handle document status differently > at IETF 59. Rather than spending valuable meeting time on status, > we have created a webpage with the current status of all documents. > It is now available at: > http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html > If you have questions or comments on the status, feel free to raise > them at the beginning of the meeting. Please let me make a quick check. According to the status page, draft-ietf-ipv6-scoping-arch-01.txt is in the status of "Ready for WG Last Call". Does this mean we'll need another cycle of wg last call for this draft? Actually the 01 revision was submitted in response to the previous wg last call. (If we need another one, then that's fine. I'm just trying to make it sure) 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 exim@www1.ietf.org Mon Mar 1 19:58:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17416 for ; Mon, 1 Mar 2004 19:58:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyEh-0001rB-EA for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 19:58:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220wFTg007136 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 19:58:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyEh-0001r1-AN for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:58:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17395 for ; Mon, 1 Mar 2004 19:58:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyEf-000324-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:58:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyDf-0002ug-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:57:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxyCt-0002oB-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:56:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyCZ-0001Oz-Iq; Mon, 01 Mar 2004 19:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyBo-0001FF-Hf for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 19:55:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17258 for ; Mon, 1 Mar 2004 19:55:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyBm-0002hX-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:55:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyAt-0002b5-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:54:20 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AxyAT-0002UB-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:53:53 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i220rNL28143; Mon, 1 Mar 2004 16:53:23 -0800 Received: from innovationslab.net (WXP-LAPBRIANH.dhcp.ietf59.or.kr [218.37.230.133]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i2215NQP026027 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 1 Mar 2004 17:05:36 -0800 Message-ID: <4043DAF0.3060603@innovationslab.net> Date: Mon, 01 Mar 2004 19:53:04 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org Subject: Re: IETF 59 IPv6 WG Document Status References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: > On Mon, 1 Mar 2004, Brian Haberman wrote: > >>http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html > > > What about the other work we should be doing, but isn't done yet (PPP > updates, "link-scoped multicast", point-to-point link support, > rfc3041bis, etc.) ? We have a PPP update author, but no document as of yet. The linked- scoped multicast address document has timed out, but should be ready to submit to the IESG. We do not have an editor for the 3041 update. What issue are you identifying with "point-to-point link support"? > > One comment: > > RFC Editor's Queue: > * draft-ietf-ipv6-flow-label-09.txt > > This in AUTH state ("waiting for authors for something"). Any > problems there? > There was delay due to Brian C.'s vacation. It has been resolved. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 20:04:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17763 for ; Mon, 1 Mar 2004 20:04:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyKT-00036g-D2 for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 20:04:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2214D5d011936 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 20:04:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyKS-000324-8f for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 20:04:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17733 for ; Mon, 1 Mar 2004 20:04:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyKQ-0003jL-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:04:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyJQ-0003bK-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:03:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxyIU-0003UI-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:02:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyIL-000273-Es; Mon, 01 Mar 2004 20:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyHY-0001zF-OK for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 20:01:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17570 for ; Mon, 1 Mar 2004 20:01:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyHW-0003NU-00 for ipv6@ietf.org; Mon, 01 Mar 2004 20:01:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyGb-0003HA-00 for ipv6@ietf.org; Mon, 01 Mar 2004 20:00:14 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AxyFm-000341-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:59:22 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i220wqL28201; Mon, 1 Mar 2004 16:58:52 -0800 Received: from innovationslab.net (WXP-LAPBRIANH.dhcp.ietf59.or.kr [218.37.230.133]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i221B0QP026055 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 1 Mar 2004 17:11:06 -0800 Message-ID: <4043DC42.2090905@innovationslab.net> Date: Mon, 01 Mar 2004 19:58:42 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JINMEI Tatuya CC: ipv6@ietf.org Subject: Re: IETF 59 IPv6 WG Document Status References: <4043D345.5050800@innovationslab.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I was planning on doing a short (1 week) WG Last Call to allow commenters a chance to review the changes. Regards, Brian JINMEI wrote: >>>>>>On Mon, 01 Mar 2004 19:20:21 -0500, >>>>>>Brian Haberman said: > > >> The chairs have decided to handle document status differently >>at IETF 59. Rather than spending valuable meeting time on status, >>we have created a webpage with the current status of all documents. >>It is now available at: > > >>http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html > > >>If you have questions or comments on the status, feel free to raise >>them at the beginning of the meeting. > > > Please let me make a quick check. According to the status page, > draft-ietf-ipv6-scoping-arch-01.txt is in the status of "Ready for WG > Last Call". Does this mean we'll need another cycle of wg last call > for this draft? Actually the 01 revision was submitted in response to > the previous wg last call. (If we need another one, then that's > fine. I'm just trying to make it sure) > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 20:10:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18182 for ; Mon, 1 Mar 2004 20:10:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyQF-0004MT-7X for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 20:10:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221ABbH016759 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 20:10:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyQF-0004ME-1H for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 20:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18140 for ; Mon, 1 Mar 2004 20:10:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyQD-0004Tp-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:10:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyPF-0004MR-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:09:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxyOL-0004FL-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:08:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyOD-0003kK-1S; Mon, 01 Mar 2004 20:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyNO-0003T5-Nw for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 20:07:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17927 for ; Mon, 1 Mar 2004 20:07:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyNM-00047I-00 for ipv6@ietf.org; Mon, 01 Mar 2004 20:07:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxyMO-0003zX-00 for ipv6@ietf.org; Mon, 01 Mar 2004 20:06:12 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AxyLT-0003s4-00 for ipv6@ietf.org; Mon, 01 Mar 2004 20:05:15 -0500 Received: from ocean.jinmei.org (unknown [2001:220:101a:224:202:2dff:fe6a:d20]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7D2781521D; Tue, 2 Mar 2004 10:05:14 +0900 (JST) Date: Tue, 02 Mar 2004 10:04:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: IETF 59 IPv6 WG Document Status In-Reply-To: <4043DC42.2090905@innovationslab.net> References: <4043D345.5050800@innovationslab.net> <4043DC42.2090905@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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Mon, 01 Mar 2004 19:58:42 -0500, >>>>> Brian Haberman said: > I was planning on doing a short (1 week) WG Last Call to allow > commenters a chance to review the changes. Fine, 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 exim@www1.ietf.org Mon Mar 1 20:51:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21649 for ; Mon, 1 Mar 2004 20:51:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axz42-0002qB-E3 for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 20:51:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221pIuG010913 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 20:51:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axz42-0002pw-9E for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 20:51:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21603 for ; Mon, 1 Mar 2004 20:51:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axz3z-0002se-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:51:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axz30-0002hT-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:50:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axz22-0002WY-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:49:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axz1p-0002Ga-NG; Mon, 01 Mar 2004 20:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyhq-0006ey-46 for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 20:28:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19763 for ; Mon, 1 Mar 2004 20:28:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyhn-0007Ww-00 for ipv6@ietf.org; Mon, 01 Mar 2004 20:28:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axyh3-0007PY-00 for ipv6@ietf.org; Mon, 01 Mar 2004 20:27:34 -0500 Received: from bay11-f39.bay11.hotmail.com ([64.4.39.39] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AxygR-0007E3-00 for ipv6@ietf.org; Mon, 01 Mar 2004 20:26:55 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Mar 2004 17:26:25 -0800 Received: from 218.37.225.72 by by11fd.bay11.hotmail.msn.com with HTTP; Tue, 02 Mar 2004 01:26:25 GMT X-Originating-IP: [218.37.225.72] X-Originating-Email: [fnumber@msn.com] X-Sender: fnumber@msn.com From: "Jung-Soo Park" To: brian@innovatiionslab.net.cnri.reston.va.us, pekkas@netcore.fi Cc: ipv6@ietf.org Subject: RE: IETF 59 IPv6 WG Document Status Date: Tue, 02 Mar 2004 10:26:25 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Mar 2004 01:26:25.0492 (UTC) FILETIME=[60F00940:01C3FFF5] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Brian and folks I revised my draft (-04) according to comments of ML. My revised draft is available as follows: http://www.ipv6.or.kr/eng/draft-ietf-ipv6-link-scoped-mcast-04.txt In my previous draft, if scope <=2, my proposal only has to use(MUST). According to Erik's comment, "MUST" is updated by "SHOULD". It's big change. And, many editorial problem are corrected. Jungsoo >-----Original Message----- >From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Brian >Haberman >Sent: Tuesday, March 02, 2004 9:53 AM >To: Pekka Savola >Cc: ipv6@ietf.org >Subject: Re: IETF 59 IPv6 WG Document Status > >Pekka, > >Pekka Savola wrote: > > > On Mon, 1 Mar 2004, Brian Haberman wrote: > > >>http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6Documen >tStatus.ht > >>ml > > > > What about the other work we should be doing, but isn't done yet >(PPP > updates, "link-scoped multicast", point-to-point link support, > >rfc3041bis, etc.) ? > >We have a PPP update author, but no document as of yet. The linked- scoped >multicast address document has timed out, but should be ready to submit to >the IESG. We do not have an editor for the 3041 update. >What issue are you identifying with "point-to-point link support"? > > > > One comment: > > > RFC Editor's Queue: > > * draft-ietf-ipv6-flow-label-09.txt > > > This in AUTH state ("waiting for authors for something"). Any > >problems there? > > > >There was delay due to Brian C.'s vacation. It has been resolved. > >Regards, >Brian > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 1 21:48:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25002 for ; Mon, 1 Mar 2004 21:48:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axzwk-0000Ui-Ae for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 21:47:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i222loFa001894 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 21:47:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axzwj-0000UT-VK for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 21:47:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24828 for ; Mon, 1 Mar 2004 21:47:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axzwh-0002Ve-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 21:47:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzvZ-0002Ir-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 21:46:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axzuw-00028H-01 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 21:45:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axzie-0007VI-Ga for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 21:33:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxziP-0007Zt-G5; Mon, 01 Mar 2004 21:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzhW-0007Jf-3f for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 21:32:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24389 for ; Mon, 1 Mar 2004 21:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzhT-0000s6-00 for ipv6@ietf.org; Mon, 01 Mar 2004 21:32:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzgU-0000jK-00 for ipv6@ietf.org; Mon, 01 Mar 2004 21:31:03 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzfU-0000TU-00 for ipv6@ietf.org; Mon, 01 Mar 2004 21:30:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i222TSh17434; Tue, 2 Mar 2004 04:29:28 +0200 Date: Tue, 2 Mar 2004 04:29:28 +0200 (EET) From: Pekka Savola To: Jung-Soo Park cc: ipv6@ietf.org Subject: RE: IETF 59 IPv6 WG Document Status In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 2 Mar 2004, Jung-Soo Park wrote: > I revised my draft (-04) according to comments of ML. > My revised draft is available as follows: > http://www.ipv6.or.kr/eng/draft-ietf-ipv6-link-scoped-mcast-04.txt I don't think this addresses my concerns. This does not work with source-specific multicast in general, or even source-specific multicast w/ link-local scope in specific. My suggestion to turn this into an Informational RFC which describes a possible procedure which could used to derive the link-local multicast address which should be unique. I think I've mentioned some ideas how to do this differently before. -- 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 exim@www1.ietf.org Mon Mar 1 23:31:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29655 for ; Mon, 1 Mar 2004 23:31:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1Yo-0006uM-JL for ipv6-archive@odin.ietf.org; Mon, 01 Mar 2004 23:31:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i224VEoL026548 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 23:31:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1Yo-0006u7-Dn for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 23:31:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29625 for ; Mon, 1 Mar 2004 23:31:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1Ym-00076l-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 23:31:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1Xw-0006zv-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 23:30:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1X9-0006t4-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 23:29:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1Wf-0006To-9o; Mon, 01 Mar 2004 23:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay1Vs-0006Ng-JG for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 23:28:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29488 for ; Mon, 1 Mar 2004 23:28:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1Vq-0006kB-00 for ipv6@ietf.org; Mon, 01 Mar 2004 23:28:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay1Uz-0006eU-00 for ipv6@ietf.org; Mon, 01 Mar 2004 23:27:17 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1Ay1UG-0006R5-00 for ipv6@ietf.org; Mon, 01 Mar 2004 23:26:32 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i224Q2L29813 for ; Mon, 1 Mar 2004 20:26:02 -0800 Received: from innovationslab.net (WXP-LAPBRIANH.wireless.ietf59.or.kr [218.37.230.133]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i224cDQP026647 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 1 Mar 2004 20:38:17 -0800 Message-ID: <40440CD2.7030208@innovationslab.net> Date: Mon, 01 Mar 2004 23:25:54 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Adopt Address Selection API as a WG document? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, The address selection draft authors have asked the WG to adopt draft-chakrabarti-ipv6-addrselect-api-02.txt as a WG document. Are there any objections to the group adopting it? As with other API documents, this would be Informational in nature. Regards, Brian & Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 00:12:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02150 for ; Tue, 2 Mar 2004 00:12:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2CY-0004uL-2f for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 00:12:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i225CIg2018859 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 00:12:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2CX-0004u6-Tj for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 00:12:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02109 for ; Tue, 2 Mar 2004 00:12:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2CV-0004Gg-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 00:12:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2BW-00049E-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 00:11:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2Ac-00043N-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 00:10:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2AO-0004Tz-OL; Tue, 02 Mar 2004 00:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay29b-0004Qi-71 for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 00:09:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01945 for ; Tue, 2 Mar 2004 00:09:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay29Y-0003wx-00 for ipv6@ietf.org; Tue, 02 Mar 2004 00:09:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay28j-0003rv-00 for ipv6@ietf.org; Tue, 02 Mar 2004 00:08:22 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1Ay28Q-0003lq-00 for ipv6@ietf.org; Tue, 02 Mar 2004 00:08:02 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 21:06:33 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 01 Mar 2004 21:07:33 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Mar 2004 21:07:52 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 1 Mar 2004 21:07:32 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 1 Mar 2004 21:07:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IETF 59 IPv6 WG Document Status Date: Mon, 1 Mar 2004 21:07:26 -0800 Message-ID: Thread-Topic: IETF 59 IPv6 WG Document Status thread-index: AcP//rYx/5sTWn/YSQ2JKXVvLhAbsgAFPB0Q From: "Dave Thaler" To: "Pekka Savola" , "Jung-Soo Park" Cc: X-OriginalArrivalTime: 02 Mar 2004 05:07:33.0166 (UTC) FILETIME=[45166CE0:01C40014] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka Savola writes: > On Tue, 2 Mar 2004, Jung-Soo Park wrote: > > I revised my draft (-04) according to comments of ML. > > My revised draft is available as follows: > > http://www.ipv6.or.kr/eng/draft-ietf-ipv6-link-scoped-mcast-04.txt >=20 > I don't think this addresses my concerns. This does not work with > source-specific multicast in general, or even source-specific > multicast w/ link-local scope in specific. With source-specific multicast, the problem this draft addresses does not exist. That is, there is no need for ensuring uniqueness on the link. RFC 3306 already specifies how SSM addresses are done (including for link-local scope multicast addresses). -Dave=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 00:26:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02959 for ; Tue, 2 Mar 2004 00:26:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2Q2-0006qm-Oe for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 00:26:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i225QEGi026326 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 00:26:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2Q2-0006qX-JA for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 00:26:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02924 for ; Tue, 2 Mar 2004 00:26:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2Q0-0005uy-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 00:26:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2P3-0005oK-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 00:25:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2OB-0005hr-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 00:24:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2Nu-0006ED-6m; Tue, 02 Mar 2004 00:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2ND-00068o-Uk for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 00:23:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02703 for ; Tue, 2 Mar 2004 00:23:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2NB-0005Zf-00 for ipv6@ietf.org; Tue, 02 Mar 2004 00:23:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2MA-0005TF-00 for ipv6@ietf.org; Tue, 02 Mar 2004 00:22:14 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2LL-0005GU-00 for ipv6@ietf.org; Tue, 02 Mar 2004 00:21:23 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i225KmS11063; Tue, 2 Mar 2004 06:20:48 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i225KmSj056723; Tue, 2 Mar 2004 06:20:48 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403020520.i225KmSj056723@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman cc: ipv6@ietf.org Subject: Re: Adopt Address Selection API as a WG document? In-reply-to: Your message of Mon, 01 Mar 2004 23:25:54 EST. <40440CD2.7030208@innovationslab.net> Date: Tue, 02 Mar 2004 06:20:48 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In your previous mail you wrote: The address selection draft authors have asked the WG to adopt draft-chakrabarti-ipv6-addrselect-api-02.txt as a WG document. Are there any objections to the group adopting it? As with other API documents, this would be Informational in nature. => I have no objection but I have a concern: as I don't expect to see all applications changed to handle this I am really afraid that this draft doesn't address the right problem... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 00:40:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03718 for ; Tue, 2 Mar 2004 00:40:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2dc-00015w-UE for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 00:40:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i225eGaW004147 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 00:40:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2dc-00014c-FD for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 00:40:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03665 for ; Tue, 2 Mar 2004 00:40:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2dZ-0007an-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 00:40:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2cb-0007T7-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 00:39:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2bi-0007Me-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 00:38:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2bT-0000Xm-Ot; Tue, 02 Mar 2004 00:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay2ag-0000NI-QA for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 00:37:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03533 for ; Tue, 2 Mar 2004 00:37:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2ae-0007FK-00 for ipv6@ietf.org; Tue, 02 Mar 2004 00:37:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay2Zn-00079v-00 for ipv6@ietf.org; Tue, 02 Mar 2004 00:36:19 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay2ZT-00073y-00 for ipv6@ietf.org; Tue, 02 Mar 2004 00:36:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i225ZQv19607; Tue, 2 Mar 2004 07:35:26 +0200 Date: Tue, 2 Mar 2004 07:35:26 +0200 (EET) From: Pekka Savola To: Dave Thaler cc: Jung-Soo Park , Subject: link-scoped multicast [RE: IETF 59 IPv6 WG Document Status] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 1 Mar 2004, Dave Thaler wrote: > Pekka Savola writes: > > On Tue, 2 Mar 2004, Jung-Soo Park wrote: > > > I revised my draft (-04) according to comments of ML. > > > My revised draft is available as follows: > > > http://www.ipv6.or.kr/eng/draft-ietf-ipv6-link-scoped-mcast-04.txt > > > > I don't think this addresses my concerns. This does not work with > > source-specific multicast in general, or even source-specific > > multicast w/ link-local scope in specific. > > With source-specific multicast, the problem this draft addresses > does not exist. That is, there is no need for ensuring uniqueness > on the link. RFC 3306 already specifies how SSM addresses are done > (including for link-local scope multicast addresses). No, the problem is not that. It is that this document overloads the link-local multicast semantics so that a SSM ll multicast address and a "link-scoped address" are semantically undistinguishable. SSM range is FF3X::/32. This draft invades in that territory. As stated before, there are a number of ways to achieve the same behaviour without these problems, e.g., using - FF32:40:fe80::<32 bits where you can plug the least significant 32 bits off your EUI64 -- pretty good method> - FF32:A:fe80::, - FF02::: ("transient address") -- 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 exim@www1.ietf.org Tue Mar 2 01:30:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05982 for ; Tue, 2 Mar 2004 01:30:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3Q2-0007QR-Ua for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 01:30:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i226UIxt028533 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 01:30:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3Q2-0007Q8-GI for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 01:30:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05952 for ; Tue, 2 Mar 2004 01:30:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3Pz-0005kA-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 01:30:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3P2-0005dD-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 01:29:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3O4-0005Wu-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 01:28:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3Nq-00074g-AF; Tue, 02 Mar 2004 01:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3N4-00072u-6h for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 01:27:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05829 for ; Tue, 2 Mar 2004 01:27:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3N1-0005Q5-00 for ipv6@ietf.org; Tue, 02 Mar 2004 01:27:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3M2-0005J5-00 for ipv6@ietf.org; Tue, 02 Mar 2004 01:26:11 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3L1-00057J-00 for ipv6@ietf.org; Tue, 02 Mar 2004 01:25:08 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0AE0415210; Tue, 2 Mar 2004 15:25:07 +0900 (JST) Date: Tue, 02 Mar 2004 15:25:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mika Liljeberg Cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) In-Reply-To: <1078173287.904.12.camel@hades> References: <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> <20040301111326.GA22558@zoic.org> <1078173287.904.12.camel@hades> 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_Tue_Mar__2_15:25:17_2004-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --Multipart_Tue_Mar__2_15:25:17_2004-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Mon, 01 Mar 2004 22:34:47 +0200, >>>>> Mika Liljeberg said: >> Okay, I'm happy to reach the consensus, too. > Futile though it may be, I would like to register disagreement. I think it is not necessarily futile, though in my understanding (I must admit it may be biased) many people have agreed on the proposed change. > If the intention truly was to simplify the specification, we would be > going to pure DIID. As it is, removing mention of DIID seems like a > gratuitous change at best. As an author of one of those DIID > implementations, I find this somewhat unfortunate. Please check the proposed change posted to this list the other day (attached below). This is basically "removing mention of DIID" on which you seem to be able to agree. Actually, we'd need to change "DAD MUST take place on all unicast addresses" to "DAD SHOULD take place on all unicast addresses" in a literal sense of what you said, but I'm personally fine with the change as already stated. > Also, there is the problem of DAD storms occurring whenever a new prefix > appears on a link. Will the revision be introducing a random delay > before a node begins the DAD procedure for each new address, or will > that make the specification too complex? Valid point. I've already filed this as a separate issue, and I admit this may affect the decision of this particular issue. So far, I personally believe we will not have to change the decision here regardless of the conclusion of the other problem. But I'm sure we'll need further discission on the other one. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Tue_Mar__2_15:25:17_2004-1 Content-Type: message/rfc822 Return-Path: X-Mail-Format-Warning: Bad RFC2822 header formatting in >From jinmei Thu Feb 26 17:42:26 2004 Return-Path: X-Original-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@shuttle.wide.toshiba.co.jp Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-6.2.4) for jinmei@localhost (single-drop); Thu, 26 Feb 2004 18:02:59 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [3ffe:501:100f:0:220:edff:fe2b:92c]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 78E631521D; Thu, 26 Feb 2004 17:42:26 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (Postfix) with ESMTP id 73D573334D; Thu, 26 Feb 2004 17:42:26 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id RAA01635; Thu, 26 Feb 2004 17:42:26 +0900 (JST) Received: from mx4.toshiba.co.jp (mx4.toshiba.co.jp [133.199.160.112]) by isl.rdc.toshiba.co.jp (8.11.7/8.11.6/1.4) with ESMTP id i1Q8gP105806; Thu, 26 Feb 2004 17:42:25 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id RAA09568; Thu, 26 Feb 2004 17:42:23 +0900 (JST) Received: from inet-tsb5.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id i1Q8gM8U018418; Thu, 26 Feb 2004 17:42:22 +0900 (JST) Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by inet-tsb5.toshiba.co.jp with ESMTP id i1Q8gJ4u003704; Thu, 26 Feb 2004 17:42:20 +0900 (JST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwH4q-00089K-FC; Thu, 26 Feb 2004 03:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwH4D-00088y-Cc for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 03:40:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27719 for ; Thu, 26 Feb 2004 03:40:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwH4A-0001BL-00 for ipv6@ietf.org; Thu, 26 Feb 2004 03:40:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwH3G-00016s-00 for ipv6@ietf.org; Thu, 26 Feb 2004 03:39:27 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AwH2T-00012A-00 for ipv6@ietf.org; Thu, 26 Feb 2004 03:38:37 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7FCE015210 for ; Thu, 26 Feb 2004 17:38:37 +0900 (JST) Date: Thu, 26 Feb 2004 17:38:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-UIDL: g=p"!'HC"!\F*!!J'%!! X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on ocean.jinmei.org X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL autolearn=no version=2.61 >>>>> On Mon, 23 Feb 2004 22:21:49 +0900, >>>>> JINMEI Tatuya said: > Since we have a discussion about optimistic DAD, this is probably a > good chance to start a related discussion for rfc2462bis. (...snip...) > Having considered these points, possible resolutions *for rfc2462bis* > that I can think of are: > 1. harden the requirement: Each individual unicast address MUST be > tested for uniqueness. No MAY for omitting the rule (i.e., remove > it). We can use SHOULD instead of MUST if we need compromise. > I personally prefer option 1, because this makes the intention very > clear, avoiding further similar discussions and waste of energy. > "MUST" may be too strong for compatibility with existing > implementations, and if so, we can use "SHOULD". (And this does even > not conflict with the proposed "optimistic DAD") So far, I've not seen an objection to Option 1, and two people (Francis and Jari) seem to agree on this approach. So, I'd now like to propose a concrete change. The simplest way to implement the option would be to remove the second exception shown in Section 5.4 of RFC2462. That is, the revised text would be: 5.4 Duplicate Address Detection Duplicate Address Detection is performed on unicast addresses prior to assigning them to an interface whose DupAddrDetectTransmits variable is greater than zero. Duplicate Address Detection MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration. On the other hand, Duplicate Address Detection MUST NOT be performed on anycast addresses. The procedure for detecting duplicate addresses uses Neighbor Solicitation and Advertisement messages as described below... Can we live with this simple resolution? If yes, is the requirement of "DAD **MUST** take place" acceptable? I believe this is acceptable in essence, but I'd like to know this does not cause a severe compatibility issue with existing implementations that conform to RFC2462. 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_Tue_Mar__2_15:25:17_2004-1-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 01:59:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07576 for ; Tue, 2 Mar 2004 01:59:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3s8-0003HV-D5 for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 01:59:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i226xKc1012607 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 01:59:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3s8-0003HG-6D for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 01:59:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07516 for ; Tue, 2 Mar 2004 01:59:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3s4-0001Wb-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 01:59:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3r6-0001Ob-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 01:58:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3qD-0001HD-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 01:57:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3pu-0002rq-2m; Tue, 02 Mar 2004 01:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3pR-0002qT-MJ for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 01:56:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07291 for ; Tue, 2 Mar 2004 01:56:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3pO-00018E-00 for ipv6@ietf.org; Tue, 02 Mar 2004 01:56:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3oX-0000zE-00 for ipv6@ietf.org; Tue, 02 Mar 2004 01:55:38 -0500 Received: from cms1.etri.re.kr ([129.254.16.11]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3nm-0000q1-00 for ipv6@ietf.org; Tue, 02 Mar 2004 01:54:50 -0500 Received: from pec.etri.re.kr (MKSHIN_IPV6.wireless.ietf59.or.kr [218.37.226.87]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHD55ZCX; Tue, 2 Mar 2004 15:56:56 +0900 Message-ID: <40442F98.1D41CA4D@pec.etri.re.kr> Date: Tue, 02 Mar 2004 15:54:16 +0900 From: Myung-Ki Shin Organization: ETRI X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: Dave Thaler , Jung-Soo Park , ipv6@ietf.org Subject: Re: link-scoped multicast [RE: IETF 59 IPv6 WG Document Status] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please see comments below : Pekka Savola wrote: > On Mon, 1 Mar 2004, Dave Thaler wrote: > > Pekka Savola writes: > > > On Tue, 2 Mar 2004, Jung-Soo Park wrote: > > > > I revised my draft (-04) according to comments of ML. > > > > My revised draft is available as follows: > > > > http://www.ipv6.or.kr/eng/draft-ietf-ipv6-link-scoped-mcast-04.txt > > > > > > I don't think this addresses my concerns. This does not work with > > > source-specific multicast in general, or even source-specific > > > multicast w/ link-local scope in specific. > > > > With source-specific multicast, the problem this draft addresses > > does not exist. That is, there is no need for ensuring uniqueness > > on the link. RFC 3306 already specifies how SSM addresses are done > > (including for link-local scope multicast addresses). > > No, the problem is not that. It is that this document overloads the > link-local multicast semantics so that a SSM ll multicast address and > a "link-scoped address" are semantically undistinguishable. > > SSM range is FF3X::/32. This draft invades in that territory. No, as mentioned before, SSM format is FF3X::/96 in section 7 of RFC 3306. Thus, it is distinguishable. So, which one is correct ? (FF3X::/32 or FF3X::/96) We shoud ask it to the authors of RFC 3306. Anyway, I think this issue can be easily resolved. (depending on decision) Thanks, M-K. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 02:04:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12198 for ; Tue, 2 Mar 2004 02:04:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3wD-0005Hr-SD for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 02:03:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2273XDl020315 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 02:03:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3wC-0005HM-DT for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 02:03:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11603 for ; Tue, 2 Mar 2004 02:03:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3w9-00025W-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 02:03:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3v0-0001wW-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 02:02:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3u0-0001oD-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 02:01:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3tq-00044X-At; Tue, 02 Mar 2004 02:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay3tB-0003dC-1b for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 02:00:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07934 for ; Tue, 2 Mar 2004 02:00:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3t7-0001ft-00 for ipv6@ietf.org; Tue, 02 Mar 2004 02:00:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay3sI-0001Yf-00 for ipv6@ietf.org; Tue, 02 Mar 2004 01:59:31 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay3rO-0001JF-00 for ipv6@ietf.org; Tue, 02 Mar 2004 01:58:34 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i226vpF20984; Tue, 2 Mar 2004 08:57:51 +0200 Date: Tue, 2 Mar 2004 08:57:51 +0200 (EET) From: Pekka Savola To: Myung-Ki Shin cc: Dave Thaler , Jung-Soo Park , Subject: Re: link-scoped multicast [RE: IETF 59 IPv6 WG Document Status] In-Reply-To: <40442F98.1D41CA4D@pec.etri.re.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 2 Mar 2004, Myung-Ki Shin wrote: > > SSM range is FF3X::/32. This draft invades in that territory. > > No, as mentioned before, > SSM format is FF3X::/96 in section 7 of RFC 3306. > Thus, it is distinguishable. Sorry, SSM WG does not agree with this interpretation. > So, which one is correct ? (FF3X::/32 or FF3X::/96) > We shoud ask it to the authors of RFC 3306. The current belief among SSM people is that to identify an SSM address, the implementations check for FF3X::/32, even though currently only FF3X::/96 is being used. -- 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 exim@www1.ietf.org Tue Mar 2 03:02:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24244 for ; Tue, 2 Mar 2004 03:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4qo-0003B0-L5 for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 03:02:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22822Kp012210 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 03:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4qo-0003Ar-Ae for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 03:02:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24120 for ; Tue, 2 Mar 2004 03:01:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4qk-0002GB-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 03:01:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4pJ-0001x8-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 03:00:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay4oW-0001po-01 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 02:59:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ay4mB-0002z6-5t for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 02:57:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4ly-0002KV-3w; Tue, 02 Mar 2004 02:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4lG-0002F2-Cu for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 02:56:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23930 for ; Tue, 2 Mar 2004 02:56:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4lC-0001U8-00 for ipv6@ietf.org; Tue, 02 Mar 2004 02:56:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4kF-0001Ov-00 for ipv6@ietf.org; Tue, 02 Mar 2004 02:55:16 -0500 Received: from yue.hongo.wide.ad.jp ([203.178.135.30]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4jf-0001Jw-00 for ipv6@ietf.org; Tue, 02 Mar 2004 02:54:39 -0500 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 8BF0D33CA5; Tue, 2 Mar 2004 16:55:46 +0900 (JST) Date: Tue, 02 Mar 2004 16:55:46 +0900 (JST) Message-Id: <20040302.165546.07036992.yoshfuji@linux-ipv6.org> To: jinmei@isl.rdc.toshiba.co.jp Cc: Erik.Nordmark@sun.com, ipv6@ietf.org, yoshfuji@linux-ipv6.org Subject: Re: additional agenda item From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040301.172722.52127223.yoshfuji@linux-ipv6.org> References: <20040301.172722.52127223.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In article <20040301.172722.52127223.yoshfuji@linux-ipv6.org> (at Mon, 01 Mar 2004 17:27:22 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B says: > 2. The description for "ifa_flags" is rather bogus. > For L3 addresses, it seems to return IFA_xxx (or IN6_IFA_xxx?) flags, > instead of IFF_xxx flags for L2. Sorry, this is not correct. ifa_flags always describe IFF_xxx flags. (I don't remember why I did not think so...) Sorry, again. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 03:05:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24666 for ; Tue, 2 Mar 2004 03:05:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4u8-0003zd-UQ for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 03:05:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2285SJT015344 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 03:05:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4u8-0003zB-DY for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 03:05:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24604 for ; Tue, 2 Mar 2004 03:05:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4u4-0002xW-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 03:05:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4t0-0002l4-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 03:04:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4s6-0002ak-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 03:03:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4rm-0003QD-LS; Tue, 02 Mar 2004 03:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4qw-0003BO-2H for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 03:02:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24151 for ; Tue, 2 Mar 2004 03:02:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4qs-0002HE-00 for ipv6@ietf.org; Tue, 02 Mar 2004 03:02:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4pR-0001ya-00 for ipv6@ietf.org; Tue, 02 Mar 2004 03:00:38 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4ob-0001nT-00 for ipv6@ietf.org; Tue, 02 Mar 2004 02:59:45 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i227xF0J029222; Mon, 1 Mar 2004 23:59:15 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i227xCQ18878; Tue, 2 Mar 2004 08:59:13 +0100 (MET) Date: Mon, 1 Mar 2004 23:59:17 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: rfc2462bis: new section 5.7 To: jinmei@isl.rdc.toshiba.co.jp Cc: ipv6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 The new section looks good but I think it should require that the host store the times when the address would become deprecated and invalid together with the address itself in stable storage. Without that an address might accidentally be used long after it has become invalid. Erik Example stable storage file from an existing implementation: 2002:c0a8:717:a807::c01d:a308/64 '2003-04-22 16:18' '2003-04-22 18:18' -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 03:58:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27674 for ; Tue, 2 Mar 2004 03:58:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5jK-0001WF-SD for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 03:58:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i228wM2E005835 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 03:58:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5jK-0001Vz-8T for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 03:58:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27629 for ; Tue, 2 Mar 2004 03:58:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5jH-0002Wq-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 03:58:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay5iM-0002OC-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 03:57:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5hQ-0002FJ-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 03:56:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5h5-00018B-1E; Tue, 02 Mar 2004 03:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5gO-00012S-In for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 03:55:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27454 for ; Tue, 2 Mar 2004 03:55:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5gL-00026M-00 for ipv6@ietf.org; Tue, 02 Mar 2004 03:55:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay5fa-0001zp-00 for ipv6@ietf.org; Tue, 02 Mar 2004 03:54:31 -0500 Received: from mignon.ki.niif.hu ([193.6.222.240] helo=mignon.ki.iif.hu) by ietf-mx with esmtp (Exim 4.12) id 1Ay5em-0001js-00 for ipv6@ietf.org; Tue, 02 Mar 2004 03:53:40 -0500 Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id A21ED57FE; Tue, 2 Mar 2004 09:53:10 +0100 (CET) Received: from mignon.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 77547-01-7; Tue, 2 Mar 2004 09:53:09 +0100 (CET) Received: by mignon.ki.iif.hu (Postfix, from userid 1003) id 17A4957A1; Tue, 2 Mar 2004 09:53:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id 158DB5738; Tue, 2 Mar 2004 09:53:09 +0100 (CET) Date: Tue, 2 Mar 2004 09:53:08 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Pekka Savola Cc: Jyrki Soini , ipv6@ietf.org Subject: Re: icmpv6-v3 comment In-Reply-To: Message-ID: <20040302094840.Q77225@mignon.ki.iif.hu> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 2 Mar 2004, Pekka Savola wrote: > On Mon, 1 Mar 2004, Jyrki Soini wrote: > > "An Echo Reply [SHOULD NOT| MAY] be sent in response to an Echo > > Request message > > sent to an IPv6 multicast or anycast address. If this potentially > > dangerous reply > > is sent, the source address of the reply MUST be a unicast address > > belonging to > > the interface on which the Echo Request message was received." > > First, at this point, I'd leave anycast addresses as is. Agree. > > Second, I think with multicast debugging, the behaviour has to be > consistent -- either you MUST answer or you MUST NOT. If you receive > an answer from some nodes, but not from others, debugging will be > difficult. > > So, whatever we choose (I don't have really strong opinions), it > should be a MUST or MUST NOT. I strongly for MUST. It is rather common debugging technique to test p2p links and tunnel to ping with multicast address. This should not disappear... For bigger scopes I would recommend careful enable answering to multicast pings.... > > > - echo reply to multicast packet only on link-local scope addresses > > Or maybe only "global" or some other scope (e.g., "up to scope B") > could be forbidden/rate-limited. > > The problem with rate-limiting is that it requires the separate > timers, which some will argue must be configurable, causing more > complexity than it's worth.. Agreed. Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 09:53:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12191 for ; Tue, 2 Mar 2004 09:53:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBG3-0004rr-WD for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 09:52:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22EqVZd018679 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 09:52:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBG3-0004py-8B for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 09:52:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12138 for ; Tue, 2 Mar 2004 09:52:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBG1-00019T-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 09:52:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBF4-00011X-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 09:51:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyBE9-0000vD-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 09:50:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBCh-00047f-Hk; Tue, 02 Mar 2004 09:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBCC-00045E-Gv for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 09:48:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12003 for ; Tue, 2 Mar 2004 09:48:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBCA-0000hC-00 for ipv6@ietf.org; Tue, 02 Mar 2004 09:48:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBBD-0000Yu-00 for ipv6@ietf.org; Tue, 02 Mar 2004 09:47:32 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1AyBAM-0000LK-00 for ipv6@ietf.org; Tue, 02 Mar 2004 09:46:39 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i22EjxHI113978; Tue, 2 Mar 2004 14:45:59 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i22Ek2h0285148; Tue, 2 Mar 2004 15:46:02 +0100 Received: from zurich.ibm.com (sig-9-145-139-114.de.ibm.com [9.145.139.114]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA21642; Tue, 2 Mar 2004 15:45:56 +0100 Message-ID: <40449E46.D41272C@zurich.ibm.com> Date: Tue, 02 Mar 2004 15:46:30 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Francis Dupont CC: Brian Haberman , ipv6@ietf.org Subject: Re: Adopt Address Selection API as a WG document? References: <200403020520.i225KmSj056723@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As we are seeing in the multi-addressing discussions in multi6, there is indeed strong pressure from applications people against apps having to know anything at all about address selection. This becomes even more true when you get into Java land. So while this API is probably harmless, I agree with Francis its applicability is very limited. In fact, I would be tempted to argue for it becoming Experimental. However, I think it is perfectly valid for it to become a WG draft. Brian Francis Dupont wrote: > > In your previous mail you wrote: > > The address selection draft authors have asked the WG to adopt > draft-chakrabarti-ipv6-addrselect-api-02.txt as a WG document. Are > there any objections to the group adopting it? As with other API > documents, this would be Informational in nature. > > => I have no objection but I have a concern: as I don't expect to > see all applications changed to handle this I am really afraid that > this draft doesn't address the right problem... > > Regards > > Francis.Dupont@enst-bretagne.fr > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 11:21:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17518 for ; Tue, 2 Mar 2004 11:21:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCdL-0002HF-Iz for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 11:20:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22GKdGP008742 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 11:20:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCdK-0002Gv-9p for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 11:20:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17467 for ; Tue, 2 Mar 2004 11:20:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyCdJ-0005FX-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 11:20:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyCcG-00055j-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 11:19:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyCbJ-0004xC-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 11:18:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCZq-0001g2-H5; Tue, 02 Mar 2004 11:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCZP-0001fO-P9 for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 11:16:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17255 for ; Tue, 2 Mar 2004 11:16:33 -0500 (EST) From: brian@innovationslab.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyCZO-0004h8-00 for ipv6@ietf.org; Tue, 02 Mar 2004 11:16:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyCYQ-0004Ye-00 for ipv6@ietf.org; Tue, 02 Mar 2004 11:15:34 -0500 Received: from mu-102074.dhcp.missouri.edu ([128.206.102.74] helo=ibm-8t82z8o5t0e) by ietf-mx with smtp (Exim 4.12) id 1AyCXU-0004R2-00 for ipv6@ietf.org; Tue, 02 Mar 2004 11:14:36 -0500 Date: Tue, 02 Mar 2004 10:14:36 -0600 To: ipv6@ietf.org Subject: ^_^ mew-mew (-: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vqqxxyxraidbeicahjoj" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 ----------vqqxxyxraidbeicahjoj Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The access is open !!! archive password: 15376 ----------vqqxxyxraidbeicahjoj Content-Type: application/octet-stream; name="Message.zip" Content-Disposition: attachment; filename="Message.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAAAIBMYjD4jH2aWFEAAExRAAANAAAAb25yc2NwdHdkLnNjcuttG8a1UGBiMrfS 3M0x2IT/XdtDKVSIwZGj1x+TjaIXYS18XzdrSLQDxzY82p0rkkBiXjB5G+J3TGtOTxU2NyQI gmqx07r2TI0PByjYuOWld24/UCX9OLzxwVRfY4DKjKJjDhBCi4UHXr6GqSlwfq+xHJbGm3q1 hG4HuBS1/tqVJGWyQ+1ev/pxtG1imYYy3OPqT2dP7U5PzQvGXld86pmzIaqwz6LsE5l/ZEk+ 9r2uKP4HwHFlyU5/oGb6v4Q0MgJJ7yCZze+6KCO/+ICiVoS1qWskHNfwPWW5KXWj/gWIlp+G uXncJ51hpC9bMEqyobbQNhmw2J5NppzQE5E1mOHD86R8cu7H4q43EQLWr7+tHKpFmOszZAUF F60d+VqxJlZBjlkejqcBybBI1OvksTYWvGKyekgLxsa1+IGalBnX1M8m9UNuymI8Eb0pFH8v 9YN2ftvy8t8AzAO0z/SRDvMXwtcwegr3bseL9He6yCXmbuDiw7NgsYFixAuYNTju18WYvInP foaChK8QgMCg3ckvRqvy560kzSHYoNwBYmu6b/oVFfBLdBbM/Gh5yq4pAMgHwVPL9xN6y2x7 EwjtUB1hvBjRxhyTMmLfhi61she16ruDpX0CNbQ7Ek8kG4MfKiV5jwycIThGls39AnsrYlzH gTYLHct6VDWk7ulNWWM8Rd7tzQ6gFutfsLVX19Pro9xvZQdq5AXQFNrznQin06TI2jdH2P1D nPL4Il1jpi8dr4D5W/SQPWhvlnZjd56QYbIs3MFHOi6VeU+sAvdj84UjfNKJViIyrhky1V4+ jjG9TS/qpMMBrAxl+woDW1OixMx/jsJwdTd/4FxIy+D0nLV/0SkMDfBb9N/6BEZ09QnwzMfi QOdTbv3bOqNH4+a0pC2Puwb840CjQZzLMFmTJdesYrX9y3gEsv9H6U7euRe7iZAk6XaYg/nv /vWVg11EYOZYrzTQMtFqbM/7uxIVIxtAnTFG90OuFMYreq8QbIRHQgcTr0OjBM5QOL6c1HcH IkdESYMen/SPiHT+x93HeRTvzdNVBnsumMi7JX5592yFcrVlV4ial3gvalY3dWGKjh9He6dn qazxNpUVaDxln5yFv0xrGdCuwX3dZ8fZ4vrBIlkDK7UNYb4v+NbCUG1UOTTBO37G0QAcmcgR uPtpl8oJUXD56krBAlmqcj0OjR7+xaxbv29gcgUfF1VHdPqglQqsH6ffwntr0bqU0r0VrTUI 3DK+cMg5E6Ih9BXMExDTOgUWUIPqTNvYPaxk5FP0xcGCo5q0pD4YhMOXal5K22FYwI1wNlj+ kqWj0JRQ0ZG0NNPW4AlUkAsdUC3x7BgQwx3RU7CZbGfY8+fOfhWaVPvHOl6PlX1suWt2+9e8 Qpd1rm0ipX/UTGa0NQK0AvzKz4thCBjS1Sj4Ue5iAuBKKdQssrlUlyOSwPbOgMg46xk5Xvln +xchy3W6uawjwV2flm9kgyWiFvWrkCJsnkLMVLxKilXnGrvtEbls40RMbkFhKkX4MCarVGV7 shUC0QPgWps2u4JdWiNADgAkiI81aEZDP6tylEitrqvwYgymI+1bNIQhLCEPFyTwk8gVvPFD jK+cNifE8TtD9eTJ9j+DYIK6DZPNLGVet3PHgeuzwQybpZePxTr8O4d7G1pxnWGh9PYYvhz8 BUHLrdW3r5ohoxeWVslZE5FCm2pYgdlXcm2r4agbksEx8GE3/UMA4uCjUwq3EXBwX1QCzDK2 IL6CEsZhLphnmcKhARtB5vp52XiLjRqYonyeR6MPkv+OaA3YICw76Y0Nkjo0qaPUStO9Hnga UKoU4HxkB+U65K/cmNSzecbjyOHhH5wGH356zYwY1kE75kQaM0Ukyp9Ic0F50uOnPIrLN1AR 9SeIiylrnBtYaP/L6S+zUG9zv6RKCEic7vF4BgJgceHqWLcRF4JWr7DGw+HniTRGBqzNFLj/ xAz2xJC5VjFdaUYgWOUUlLylDvGVfQLkLevUEbM21tBi7XfVA0LUV/2Orl2RHebahqGF1qK7 4+HEnShnpBLrbHv9LK3j1pQHFoA9F+E0BpkQI/Imc2xT6O2EoPRvzB3134ycrhYQhHeRyPYK s3ZTs6NHLSJAjSr6WNPLyocSGxbSbyw5oF0QK51foWF5VXfdGir/ruHBZ802HSBxrqi+CbIe ZU/9BXj+PWQ97dBd5z9vDUA6mR2XRDi9i4Mu2S5co73L2W5wU7ENcKub8Y/LvDZiOczV6umA Ze0EiovDZwBcDjjz+X4yXIY8OBKhpom4fNimvKEllDL+PQt3OrOoTACyATS3JjjjEaCcOHJi ojJvzi8bGGWsLYAF1hTMUkxHkHpJeLY+sGBuGFH2WFP2huFpq7URN1H1gQBemOk5pnyLiHv1 0m56antrCIAECBNk+JScLR58LSO3VRsinWCuWlXy3KmXCFxooH2In8EuFNBKgmcP2oUrfltf pueg5E83Vt+HCqqgLphBg7QdFNY/j5L6EDqclvOUFlIa8yyUO25Mit0IL2ELdDgrSSIplSKz gU/pvuuiZCgAZhnsBNvcbrxeTFfRvXsftV9gBz8uxwo28DZQZ7pRv+XcOSFTEli7q+HdQInm wwQEceoOPbUxUGU1btdqu1cl0BW5yDQiOJmMZ7zfufB1LT3ckWJoarks3tvKcHplW3qrEKy9 jF9Oquc39l5htGCh0ipN+eVoPA6fgLg3681hoPD8+LDWtC4rtf4ticwHhvadVKCOc6UzZ5OT tTe6zjNtLVN2iOA7QfDCdo7uP3QsGaXEjcSqOkF1FUxKvM3ixSLvRVzCkg5n16kSxpJ5Hpw8 L9klaINRXMoKHhxlLaG81L1Q+4oVCCphb/xmbl1HxUQC7RH64ewfB+F7h4VEPAShFiOpiANW lScei++wDx+W1+5pHtTtmu3upY/1oLMSFt/jmA+3F8WzuNF/oKe/9ddhlloSc26l0syr+MBJ bjSZMirURn8M5Q8WU+ioYc9S88Bo2zWjhiF60EQ/xRtkAozceEkZRcy2h+t9VldXiEXOyQiT DGr8xb/MGjpxt6WsNWXL8VR2UlpPSDeWJrFVNoFqDr77UVxGjBCrgF5+m0Htn4EiIOAZ4sb6 VuWgBd4ou1VcM5BiB0E2QVxGXA4bm5ZfjcufpjM6Te3yd7WD/YPtBOyTHyensqkJNINDaz65 jyZ4fzBKmbeKv2DCjE8aFkKF1xMmCtI0xbAs0HyvA5+kKIsXuKdMPGYhtm6wO46pN7WDKECo bj6iViarhx1GLrP1W4FOJkUvaqPi25yD1JkN2M26j7AjuDHrHeghV2G7h77AD7XhXRHJUU0h l6OX/09NKuAORVxgCdnwRM12kvuXA5gqJD/rsKUcfprtDrfq6lOyOSWVDOP8oWQLzw0LfiUf cHz4AsgnzOX8bf2sSminAda05sx5RfFTl5kyQkmQjGKsBxYoOZrAIKwAA3VxVoE0ysgP8drg f1DASO7cOm5SCVaEpekvjXRzisG28RR6xhCWLPuoX0qmRoTmAvmjU/CxD69kpwMprU/XnnFP +wdE2L0gj5n9iJMujsMxMJ1wfMBWuP7tBDxFk8fLVEm58iZywKrjjpZqy3eHNGsXlScAyy7B USJoa+bjBD61uzRcRHA+Wxj/BmliVnZM/FMiK1afmAY0A3yqCUUQXY11PUn9SIDe9Apyf820 D1Z9Gq6BgfwRt2Ij7eAIuq9PRS/5/HrnMw5l21GDwPf7Lww+TRJQ3z8OpLVD4OSFIu3AKzhl bP1r7pAW109nfwiAJgFJM2xa1gCo7VxpNx7mPWn6+WXsiXOaOzlvB/7YTxqciO/b6sm+sstD RweYYl9bri/mUXRRCLPH9HCbzOwJsZIBaRymn9F+bzOIFkpolJUPeq3rhOvbYqdJIoL4dnUY oPdxiI6tVMroniHk+g7Lh5T2ySdyoznLxF9J7fH/yg6IbAbN8EP90y3FC53cziczyG10n0Sk n8zNHq+iPTzcfhlcjqvdLxJJ7WZWQBLPmOlTWT9tU8TajIX7/8zRTPyaiWOYYTV0rrSK57M/ 4e4AznirVOKGWv785h0bR15kMpZsc2xPXCKLwEnyM8MDZmV0B5cGUWMIHL+oTV22FF3SR152 6OLxNBRtTNeQL2V8hQV8bznsI2V3FudC0e1FiIF+CP+4pljhT6J4itbNBV8TemG2EhlSnxmE wnH5WNI6zzmNnapON3CHMt1yVzfYtEVDNCkr5NNJ1sVFvE9a9pQjrAOeyQMOucwVIePnoW0W vUF+Wo1dZCXhhpqiAQDQPqbPeYlHNfQI9JmMkwJb/J8NQbOyGyfWpDheA0/x1jWMkTrg/njM ELY1itq3He0Lp+kjtnCzqDT5mAiFn7ejANMJkCvrIpH9WP/rvIl0bwGzDnmeaYX/DM7rkoMS 3H1Zb0YnDlVmobF6+H3c9GGK4duwbRcSViYeU0YlOTXYZ8pOkIOdmf5lmI5rIV6Y5SvrQ/xU Hk2rVmhKXGVGFAsGZ/lJRfbiMpUZYCADxqDW9c4KF1MVdMRjFGjvW3ueZs6Ap4iaP5ngt3LG ZRXB4hwITJzb3ihCy4VL3tBQhBhFUI0m/AwPorUR86Lkm9bks7ab33gcZJj1OvXYiW+706Y1 civ00nXGz0zKYsYtFcofNrpwPQd/XKqBVx5kHzZuzwXNmxBmxDu6CFGMJJt8UlrpPzSblq1+ Vnw+uQeWrjYPCfQ9XiHLikT0aGmaxrrkVqN+sRMfRaKKfPbDmrqpOYXVrbaFXOIx9eeXMJD1 o3xcEtImgw2YIwwTY0vQlxaNwpw4TkNsemc94x/OH8GilBr+07pM7wz8gYL1ma3PTgTcQZ74 iOYlE+ZypQbb9Lf3gChPg0aXE74vldHbtb4qRr3nlGwag61ABU8T1waJjpj/66HFPAxZIPJW fl7PHsPAFo4guhIRBtKMcceEFxmTSAOCGfB3JD9qD86tDFdB0NaYLwor3VkcO3ub3teCdtaI blADdqx5OFb4Vc7ZEf69vlNNxpYH6Ry7/Lk4Wr2YFRTbjtjvvSvvYQrtcYxYykPPERhmVavC VF+Tt0RnNv/QHT7Rhq6jns7SszuqtrF56pPPOj4BoKE7wZHvbIr0NpBZ7iKXNf37S2wA1D2Z MRCQQwoajW48JRpU7xllVBbpafn6svkDlJ+4r7QbFbYiYkjpK1qTFbvXVbhbh1mvF/ge7UUb q9QSfBpqYZDi/1NLet0cpc8owyyuW9AA0SNqr+akq61lK7dMOjQ3l9s8RC5w6B8S4irdAGFs OrVmpXOdluAesW+pvMgTTIoMUJDSaHCE5VmHd+AQbTbFXGO2ImtxvZc0zcaQUCfTg9odOxJ9 dypvN/6bKBVxYwfYTyM5aX/JuzjxpgOV3Nu+sXWy3tmzbOAHPrHvuTA51DR5GkJ+r+W6uOQa 8uVsQuQyh169SSnmT41QiuiKvY2bQjcN4TU6d4aZ0atNNccwwarB0VhcO7a/aIKBzyrrR1Er kDVM11RRFLxauJYjHFGj5m7he65UTj5De66DivDO47gL7aDkS5f4EVje4zbOy2zUKw4Gyr6H ktEXWe9aWntAqWF6s1kmAt/UFGTeo2cMVh3FXeyCSP6ywejHWVLJtNbCaFiVH8EcvUxzTM6D UAbXVQlDOcyfxRoyGKvT54fw57ZGRufES4uuV4q5rn8wjy+/OZY9WOm+n+iekH1t2B+UGk9W X8Z0M4TXs3DjalqEfShNXNSUJDSDXwv3CLXOFsH0Qetb0e3aa1dt8tE5ErCEVCgJlIev3qvW aO5TOVcG8MYf0avFAUUWMdmiYLAyhkUpIUEXsmjy1kV97bJbP1BqC/nZg+YVE/sqwxEA0Blp tJLuqIjPIVXm4RsTWO0ttvBiVu8VusIm1MiI2IGTo6bRMZq5wjTaIRgO78uRSbAl4DL5rSQT 6wS8/7Slxk6/M2aAqm59Imhcvn18tdzHviVGuhRLFHphQoCQzdG/UWTbp9s+l+Hzw5pLKXSD eJkpG40f28V9PHYcTXfCaEXN12EB7js1F5zUhS6s+Hh8+PWHioyc3d7D3kydbP9XXgxtS3kU Jd2lahXVcboVqQYlu/UaRcSlnblsXtk0JcLrWo9DHWqmLED0sbHAp8N5Y4cXHUXlzTr3KMlQ ndViRU+lzZBAbJRb5Cf1gGC24A5LpUmVVPVFT2QcxHCSj9JThJe7/r31bBE+eo9gjpmq/Nd1 jB40imRaAJsu/QdHlVUJ+t4wfQV0T2obbqnwWFNJjsJZjrroAbm/1GRXOTkFB/OJFbqMMIwD 0UXRiN6oWqat1KTmNICtihZ2GelKwJUjbXBVWVqcBApCNn8wqXNhTL1rujqiDqZxSM4s7Mty tTzXJu5mYG+Lw5f0T5Et7/1pnLz3nUuF2Nnr8yASan/WCl2uCzbAfVdnW9HA/TGEjYChXu/d 8z8QUY2+NSMKkUOdgAQ+KzCyhPIGLxdscutH0COucJ4ffQbMuLWyitZSOAbG6K/uIGIHiS9k +BFKZZxSxUt+XA/+8VFBQy4EpwNvb4yhnR4iMiIFPk15WKiWf3RDZQnRCnHcJjF/CVN6ZTaX J7ewtYa7SF1RxF1lhDibOxSZgoAYTHw3Mea5jMdYyNdzWtd9dA3VyrmTuw+ylVdQaN7EMsn9 Ry93aXBz9NVbXlHi0oVO8pn2EsHvMS7zGdcJCT+hXEcz3vCIPm/z+Jlydajae4cs5z9P2I4r YsSiGMLBNZnH3uVxt2ANSLQk0epjn6h7ohlERuQG/1ahVmKltXBb7KMTXxq8P4PI/3WtdsWD VyvT7LpUDYrza8vmUWltxGedKi6T2GGJBgK/xbQByTI8cHp0Na/tNJblCX9HlefMTkr/vcPH NisbEU3XnJW2Tp6e1Xblamp7NgLUvlAjdPvDRkLNRmr85Q4g+Bv7VbQu56ANTLLHWF5n6YcH 9XX51uDIK3oDhl9/aslDFvfvKPaIlCUlZkO/0qt4jy3/dAqkHFVR4B+91aEbaEGjAsezP3CT voUsiBmsXI4pV1ySeuAeEgVpFkin8iqydk9a+DoCyaU0ijV97uWtbFp3Gebey7ZypUoiPa1+ +K3N+P1EXBL6FkFqs6zsjYKV89ZiBE7+HZSwDhbN/S7L8jSdjznezSCZblYg1Pu0FchJ849e 7vlJ9rlrLd+OnVZzSG6HvBqqcOIC+oVdJySI8xeJTTGttsqg2qzf5owEyR546qIjt3iHRmQt UXDf24LAl/KFVsvMbNqgI4RWim08AOxrcFoYd72qIZVp0M+q4JnmK2B8cs012kij22FnUoql rgHbsgx/xpMtRIvUOLMgun5eRea0pH3iLQ3fIc7HG3fxSBRACnKxqxTQi823i7UdFYxa/mJJ HCmqXUyog+7fAHXCWdQfRxzZRLA5XDi82H4zaKCl5NR6XIQ+UpU0RxtMHTiK+gBsLQ9eigkD qdQQhc84sZDD/Cpbzye4kZ04SrPJbGqRmhrIRHBCKFIApmY9si3IGLJIRuQgvIvP70mn8N17 gphkDLWXXbizhVnr+V9a6hmVBSQV3bOU3gvnrrSoazjaTJFSyRFIbhSGjAtJZs/ySea2I1/O gErd/q6v/xmWWX6qU+isnNFO5EzfCrtv1TTXsSh7indE4hLt9fm8tG36ZCCgya4mb82E8d5d HOMcRNyuOUaAGPrfOE1BJEMRf6ub+Yy5l6biBwFQ7vtoRWPWAUJkSPNZ1DOsG0vvweJUHcJr k0WzYygFMFwh24T8wQZNfXouTCxELLELywtONIrXSVMWU9DOe1pVhAE+x/RoqoPzRZ6hXCRm 6AycynLOIav5Tdnufm4/1JkJW3gR7wZMi7ZskbRsTX/40cYWp49WQUYHvQ3iRokmrepR6D+R 2tp+CCvWBWMfnf0A6TE8FH/FqKfUWJoWExdbMy5OVHpDP4mM7BFnNy/qs00K5YmsxZ/F2VEd 4aZgG9XIpa1ZGtVZq2Z7MF7PqGnV+EPGdIAXn1vKQqtZX40POUmgG2aC5heCCDZzYtDoP86P 8K8bd9+yhpMNI/P7V3bxAXMBfn3HWtKrAVYWXb1Q99xw+rRimz3wvLh93zVzwK/frlrR+Dkt 3hnpF9Dyi37XwpjST/SB9ByMpxxMW0HHh31uz+1mjYg8Kdy8mDmbFQYjX0u8TkeG926gXkpA xvDBD8YANApZwpcCXFLxx/UnJJoGRUUTJ5NhCLNC335DLu3GslwAMRZQWFzvTCG7u01TxWPY ANKNtBM/3rEvWTw+4iUbnNhCywEzF8omXVSBVP1RyLQ2NumTgW96iFIApd7OpATLuicG8vwT g3xNqf00qfJawODMAH/jT+AItTA0gM/IBWi0Hsve2MxgPEX6DhxEvZpAkL3q42HlHzNOKqWi HbiYLqvuw1Q+Yymj09ANMxieJsr+qrysuoRm0MRvt87hyrPZFu6phgxhPNAL5ezR4kI1qVpj C2t49j9dW/kDJ9vTJv4x2ADc/9qRgSsSPJqYs0AAlqOLZqSbeHakka91T2fNVim6FqU48sUl LiJc3lR1g7myzWH71Uafdg18Sl4mmpN109XUFXHbb0sE5UKQQOIHeHdetCYkFwxkd7wpnlJO WkB7d/9e/FsagIxtTf6SWhiT+KtwCiQ955mo0WZXnoj1GuHz3bg8mAXWN+Xy/6UOcB36ctF7 VImleTpfLQPS2OQNpaY2ETS156tUL6Hxd1v15KVZ3gVIKBWIFEJ4UQThd/kUREIz8cNo5dVa qtKS2/Zb5RDsYugTfNOROAxnQwat7fSmkZCEKQpeGLnv2OhP35EhsnuulZFy7Wx0+hEqskcs hLX9BSNAK6JX9Ov9xm8F6C6n33LTu9YEMXCkJuRMtjNiUsvJNvCLCL6MJxJHCLSiWngub30y BFDMyItySAkokI1zYGr8T3jwBNk/rln3gAVS4ntyve9SiOgpxlSoTyDpXoKlsxjM3mdqNKca /Xie9swryVV3oaQh1H7Shp2tTpNcOldcK91+xJy+nyqpfJn5RW01qRaWNJdgfZKGWpWDTzln RjbwS8RGtk7wSEeo54d+8sH2zxOmzOxk87sNthaPjOJhzeV26NTOgkg7F8mnQ4PHR2hNTdZe Eif5Fw1C5jB/hk9wx3cb2gZuLkFmTzOQRp6tV9PeQhiAXNApCdbAWt7erXTj0gkJG6mkVmqT j2/mDMqwqT1l4mXULehhNZgb0RChjyf++NKGj9TR6DILYxD882eKKEBeEvwiXqaMgeuX+V9V gD22lpD4twp1IYW6fvH5aJ5NHXLW7ueYL/vXe3+yMj4hRsTkM8viM5VJ+dhm0cN27hgSPnNf XC001TjaaiBgLRn/bfeVVNfyHzNm0Aav+GjicpWnKqJFSoPFic0hi4Gkiwz+wNCewCCGWwF0 /Yzv1cfg7Dk3hfwecRU4xA15QSD0zFT/+IzdoLWdG5/xR3dKVy+7wxNm7qTNwVS+/JaPs7fb OGmdDuFPyD0Ao6offnyTndEynydRRBFjcbj4m4YeZ1Ea8J4inTzNpz6FdtNIlRg24eCWuM1y c/VXZtB7q6ruPoE08z9HwvXgfAecc3HjD1KkBdVgQJdBu1LApdZoCN4OKRoOEf3g716pKben RxHqQcJ1lCyxqTmINwdSp0YLw2Ardx3nZW9yNzsojt0S2dJjja16zekYwiQdZ1tUN6FTnOnW OCcF8CnG754CrnV3EyqAws1+9BUvDFfHJpKO2t+ZPPQAjNUGedlRUfSFU4WVz+rseHXzCB2V /i0b4gUYtGOflWERSU2klfBjZbU3o8EJSfZRYw6kBboDceBok+kCl1QBSWPALuhiaXaq56wv JGgQLLEokrkb4kRUlYeqMUFPxex846rxsvYcguaFxbiGEzAFDR0ZKYhZAD+1pqTYr2czVI9S Hig/dZzm7pILaY2V1jFWq69PLxL5mPJk9mTiOFsn0vN4aqpNKBzXVkohOnYk68+5AEULK970 8xg2FzEpqRHQHgemEF8Dpzfq3OvP8Tw6AiLtoV/6YzWJqv8ZPoA7hyWeEScSSnxGL5I+upC9 qNeuHJxoLhcEtsoYGVc3YsgS9PBZDvm96IAc4vd8KN3frDBOJ67OXJxEiRwjTp4avDkmIokO omgeCwMS2HS1AZHkn1FPsp2XMmqIizALYxfiksHEORzGF9sIUH3mAm04iJ+fHhPJMh5Rjs/j RvhQOQ9cCEE5BpvFzqSkHlfKY0C35tl5Hl/K73JgVfCXEV+3DeZ7l76LGH8GNr1niG1xStru moJmxmYBVX4NpA656kIsmMns/G0FRr1BaRJO2JY1f+6/0iMSm8Zp2RUB/fs3rPfO5LolTjhJ UTb6WP1HXJ4nB7LbbmJXUOSIRDY4+rnOUri7WDbn2pBwOR+qDEU+XT5OEM1/MjDiYaxgDxVU E3Rliwr+k0iNPJjmx6U9nCDTtjzSnzDU01NGWwiJFak61MgSAhgbVLHRsw6mWDT/YL+HM6wd DR2tSm7TPUhfMJuvmFhSx0gTsKjzi0AZxBOHdROtufobM5GJqGlVdKLyE3dtweZvC8nk6fXB fKeiS3rNgFP0e6zvl33MSBFYE8UX0ymwPMOn47lZAADG1Vha8DNMTs823++0qGcHrC5Jno7R hnWv8LmwOkS3pxl2N1JyNlslNCdRPeK0M3bBx6eNzSRzjWaEWo4wU6Pcmljl8SggeFOb5GDD YAbD+rACYiqXe5BMou979WLVYhdENKnl31Vl/bNt3tZcLQg3hcxeviOkbffIy6pNYdyMycYu 2ZeAYtSePgDG4jWLwEz+qjwaIOEp2HCH1pUf8cRysQ026yExnp3D8Piir6MvsIFFrzSsalgP V8vZih23UeD8QFhE3Bv1f+g3yNvWClu5AkSx0on2rNDVEafdTiTPD71nbB9XRw5QDwKPJVCa C0f/7lO68xZTfsZEBBpZ3q1Avub8iEdEi3TFG5ezTJs0paHSi9CyC4o9AuypEgUpjf+oYh4A EEmwlcTLowEhtm0jngRqXUQ44+ezR6bjMzqtFkNvrMwzjH+WIP+9z7+Kmy2QhgnwnJ8/KIfm deXuUreTWftKNEkj+wI83/vwP7YtUx6jQcICUqTGybnxO5E3R5I3teYJTUkzvvwGGt73BuvE 94K1U2+VrBiPoc42Asp0+/9PTLRYwOSg6ikWG62b4DLNLHMnRPC5V6ZO8fMh1hfXLw24xF/O W/Un5enF0diKLjJKl3oMnqJ0g+Pl+PyH6pUIud5DImicRXG0u9VMQcUdNaMOouMldxnPH30t J0j3TzTije3Fd36BQqew+fUlZotePMBBZfh+qbPGtJ7u1xq9kJkybZ+R69MljzSSXjzPONj3 YMjIFWVumtmOwGaSqnlua96cX5VR//MkU1+iK9BJZJRqu7DjoRlEz94LH3zTKCBjtVNDieiv dO9kOuk7yt068qvRu/4MEF0VMfE3USQMqYCNDsGq5kQbjl89nGD3WdKBy4opYiMQeMXMntXo GgjGQtZ4wDnPBQLcVUE558PqMm7NnSOG7McfEko2v6sRKA8p/WB3BWz5kbGypdNgMlEQ8oW7 7SWlGB8lXaF29QmHRF1NFOymbzVephKYk84cLLNSZG0AtmYSlFPpU4ZHuYchby+SoEE9xdPp 4hdyoJLfHkyIEi1Y4SY+vdVoo7+IHFPnRv5T+wP2ocyaqWPgaeLDLtkiqlZGDcP3xXdd4My0 W/Tf+78vO5fhCCLX/+dADxhrjl2gdSeiRI/IdGvYevKU9YrwJ9K9XpzcH2bwzDtv15ggBpNX lc6sYNelgJuLYU58CC31M7JXIblgivz2Ob1r69m9aMcXC91DIpGTbTJ5lrjIm5oe/NcLtUta nWMW0d1xTd9ybemCVHn1P4uJLwZJI0LyCso0hrMf6wrbsQ56K7CQfa/8ToRoYgJj1gXcRwKw AFw/NsJjRBurgz85cYsZjM0WSd3gDyplODfplS1Vammp984ItyVmqc/OGnS+P44NVvpOpeWy TOkewmCDW/d99qPGIOLNH0kaKLgWHaN2QmuBPtbTfMxdSCQj0TF7Kl1b7TwE+/+ch+VfWSSZ EynnemTU+PmvN38Bim4QZJHHviB2xz8f/Q5bRu2DR+JqEdVTOD2N0hii//mCepd8Xt9WCp67 dnzvwgdGEGKA3rrPUvar0zxABMny+EeBAc33vjFfY4mvE1wxe5Q6IHWUM5vcFs14vHZsW9T6 KEsCYuYOaecxwInHZrwSyVBsT+jnvVzRifCk0EgT2l9+acCCd0YcA/pvCJMCYAn6KBk6cgMe BJFkcCZy7rVlhsQsNNhIVTYG+eDcO/oXMkapDfKMQPpwFH+PaQG1khLyYRgCC+4Ot0bvIgBf 1TVcvwerkCe5AzWKb2PnS5x/j/6AmSYI86Wj1NRMbL9pRc6gG6sBKpyBLRzVPin7WThlewfa g08lHBfv77Fc/AbaZ7T5FL3DB1+cEaq+VgpSJ14eD0uzd1gTXgAu+ma7yBN3DlpgV1IK1TBI d48mDY6kFiBiF05LUGC3G1pjH9r1soH7Vamba2zm6aD//QT8bVV4d07+TR8BNgUVmPzOIaCg dVE3RyfNWnZQ5nvaAwynZiEjt7QBSKk23Yy8uDT3hJm6oS5g6qqzX2VvaOTNdny9JlE8x+d9 IuTClajmdWSQTc0jw/E4XzO+v6PMRdqv9hvBF8lS+x2kQSiKtlnCKN2ImssMh0kSky0opmQz Ms4Y2AaNCI8RxCS5Des5c6bDoYogsrqXHKe7usAawmy1OPZx3P0gGcdGZPk40Nl4FFy9IQlB cEr/XMqOek9omQMDIe2HOa0B3vU4ItQPgt+eONbJ8ji3NqaIwY0j6rQ1qtCIyuwcYj1TUj3h 0noZxYYdQsPsVEISclH3HcGY+7sgHO+OJYv3H2y6odR57F+Ec83H6KsKHPUXE0cXdMGcRcsJ Hv0EUbLuoznCOcDkjO2TmS1mra7jHOYi9pCfB0JPPXPvseLjXyYNWcWsb4CH5Q7k/lRxZEE1 lU2VzdHTv9L7YECtmCuc8bdetCENyu5RaFrUwOQWpbuS9tgbM8RDe9jPbMzq6cGRmZik/iYl O+myg7w1RECPry/RBOR5yReItPJRv90mVURj8Beyywuaf0b2NdVPaDFg+loj+5JmntBk5D5s HdDJL3eq9bQ6Muk68l4SDBO/L/jWp6NO6I1Yv/CpKKb0x+XEpadfFsFHivc56vPB0k4hA0HI 9JcLGnXNYizoDSS98s44GXZ/CUr3rOoNSTKOuP26beuUPJi7bmO3Q/MUj1j0BUFwUGFTm3nA d9avbGvU1p3aGDSLVAGDVWjC3eOgp4IUZnpja66AzBSqRJ7MQX3pchhepzidlwuoND3bBSKe BB122Dct43Hc5s0Ebp1Yd/yIdn9eO1j4Ttd7YYAI9ahyPzthO8NPtI8N3otO8UZ6eJJEmOAd dK8zk7S0ISi9NW8lmsv87iwLXn+Oo7Cm0oH8DiLk2PUGMPdu3dWyd+jV0gl8sfufym3pux+A 4qhe8oinAQYw/rtAxfsQOVw1UNG+t+9SKxcVRHzbrHSfuX1OympfwsQv6k59uqpR9ayTndxv dwClPMoW42zHZXaS4gstFDHPrvDtPiFg7t0hzDFD20Co+eEzzqlYQxH3nWEJHKoQtStEffjG VHiTCiH1QqGh4ZLE1G7yuMtZ7bhSPwX/tAWOj4YUJ4LKWd6W8CFxuLHxwzLzCIrLsNwkNkW4 elwD+oAQRED++RyJ3HgsnlxGNeJtbx1C0JNoBzPIwzDO7F9im514xF3sUGcgVMTB4rYjzgKv aegCuYu9Fcc/2O/TMjTqPZsKwBX0F5U/Sk8n/L0XqC5DCCKLYOa09/TSBQyrJsSW5Z91b0OH uVeodlI6IsiFiMqBStUf34gGt4oAsUiKLhrNYcdzNI713HTxZAOnJTgHMb/TOqA1eDK7zckq V8yxxU6Q9ET96LagLECowsSN5wrFoJNchhl6rMJ9rTPAwB2++7w8phI7cuUtRay59deoutEZ Vcp68/q6szeTBAr9oLLuSLc5Fy6WpbCZyohYRI/Jaknh/co2HT7vmZQffMJbLeuCqdfDePgY O1CJ1gn4SmjzS0+2cAM/WtMbdnenwFmkWi+KVjcHeWnqZVX2cIePtP3VCRi4LxsF83cN1vHN ZQqo5xCnmFIFSBTVdyuBhByrrQIv6zIHHKOaFKfSxh1vbWiUyA757Vv0HQ82LMqfIghW2fBZ Bxn3DiAaMmubvvJRFr+OxHVo26YqB+E9bxPyyFyUvFOWqj+9v+1QmlANUQ+MM0fn7/1WNXWK LfYlc+NmRfgwX9ZfMkjz4UDOCnJbFUjxD8dBbmnert5ulyurQ7/GuHVdukkVYTBtKlYRZXkt NKKpc/bxDPvgU24ZuKeRfZkorguuCKnSpLWnHJzJ5i34386tDsBT0OLCtfV0SUGLTNLUOHj/ peA7BT7Je/XnP2k6cPc9tZgJZEHfyGaJA/geYLRvNOV+nyv+hRL0F5aCfrAn4sCCPfKjiBaK UFLOGrHEZYkJEIm+w5Ca3QZRHb844fYR9viHGJKcW4JQRr+Ryhi7aUCDEHBE7ETPsgfw4vqQ tZPtqAY9cA8dhJf7evoHvKNdGPXQASboWr2u6xy0fQMpGQi3ByF6763lMhzJr/JjZsZfccJG nfbcqthMwg8VuE1wOGLsrbDUDkfkT54pVauKcUzBqd/IJXXMbui0uKmkergl7J+I5j0OOIyw f0bgBkoDVfPm0h5Ne6os9jmqpMVAJQ+/6rhs6arelxLTRqq9IEmXRu40WPhBcdK+i4P45830 G8d7L97fYeTGDduinM8V1PLx0wikDXoBNtt0YxehvfxhUV4fhPH3UOB0dH8ZsWUcH/4gvimm d2U5sskKbZLR+icmbCO6xdpM0qk8EtLzVf9uePnOsrU+dX6gz1JfTh8zTx15tzzA9NoUJhMK BKDfIwpETDAMwj0EyR+FX7F2TlrsnF8uoJJhpoaG0c9TllkO6pcFH4+JCLSL+hpbcagYPVfB caWBs6kh8HLWyFGn32nf/Ct1J/fWUFoyO/KrwnZJfsk15+tgk9mSrRSaM/MhNzMR7wjea+Fy n2m/Uez1uYYKnxypd3irHHAv6668PeVA5ybqdTU/+byo+c5oUgWTdVD7eyo+Vh7bq/0FsgnB PM6Ajy57mhYTWQvDUPIjmbGiLLJLqn4V04zxivcFoOrS/t5lv59xgMfl45MTTNXT5W1rJkhv KZT9nDCGaKdzFjX1LlmfiJFAjXNZIY5iaTBwDh1DBBdJsAq2x1n3lKuulrR7DNpDEMLqS7q2 4ZTetXmAClUGMshwrCNC34dHfZ2MFMmV5oTlY+uJyUQUmNNQiv2zSHwH9VgQpexSf4k/HYFT mFQYb3gqIOwm4yEzC0DcFW7kpHlXeGS4lhwpIaeirKIlU4lELNTIWLEkkNhKCnuKkxcuY8jz GPkhZY+3kHdMcNZL6H2PHubte807piIBIvsoW/F4xPnE8wRwZG6XAVEF4OIDI1JV/+HredEp OxiUUq7TeVi9MV780GrWBZOCeeHZ9IHe3L9/R8tj7Hx4UEbiDfN2yfEiYFN6LEAXvCmG1jFr +y7+gnMotihXxzMKKAF1z2AKf1k7QyWOJQteXMeJ4prSM68901+qSStRcyMTfBDroAFD87P5 9JBmRJpkmtexr46XdrpIBmnUlhtynpOHyjHtrtfLK9camo2WzhhIZ+g4NcdNNPlLmDZ074V0 U9o3c+vcZlI72r6L/ADgf0EzQNA+xML5JcRs+RAhdyo0VXSa3Di1FFsMdJoAotwhTqys042j rWiio+Nk0FwsxlIuAbyEV14sYtPmZsD31YnzDMnQK1GSZM3FUfy9/tZWbV8AIpFubbFHjF1T fLLHqmoRuJ0PoC0a7DhQBWEAxIYdMxmbYfnpcx1kka98Uc82sWju0UlIcp2AUwGuRSi0ObTV Nlo/eWymmd8tzBsWLn97TavWsZUE1TVODnltNdCZl9Hyf1uxU3rc7vHGqkEogwluExAPAhcy HWUw0UREuT5hTMbv6pvDbbNcLggKY/ZinC5GD5T7+RpDr1tnQM7ptzYrBCBKUnNmw9kY4EEs +7+/V5R2BiSVghZ7S1d4PC12meTWJHBALkVtfDjKSMEHYUQn0L7nM7FsJvBeKePvd6RUJP6z m/LyCfKPCzIEhQDn85PCoA398TxE+FC+BoDadWOwnIqhjz70lH8l49N9KPqBmw0q/veQ0mOS c7w+1qmlwZfjWQm/RyGpyaWtNNOO7u3jYIWORyxImIpRJzgoMTJPWKFO2uVkc3iPhXEumcr1 lEQXjQR5cKkNRsn12OFdYCNBCElfckucbKwub1UMQutLb0Gh7J8GUEUFDpHUAPnblc4wu3lJ Rex0wMygOq7xMwW8g/3BFWgCgU+hYzB1xvmLY1mqmIaMqMg1UghXOlqRFuFF9xtRIRnOV1eY gOAiWtJvzDKhKjhNQErp7rsPcjQ8vjpRpurzAO6l3EiMNa5d1PPY9E5xNZVeseklRVvVTRfF vX1L+54IW5WJOv27h2EEKELKlXUmPfozr+V+0hhdqbqnQPridZjcHEetLzpNL/QpR5GNrzIY rWBRQaR04VAHwBqcQ7Eb10NFNQ3DzwuaW6yWZr70idexKMVmRwH3PceL0kgoHbwJkj6sIpKd LetnP0aYv+mEWfigh6MoVu6va+fT6POQBgFhq1BlHKCIvsrFsp+lAiGFRWm/qaKJf72vHglJ f4Har8Qw5Ttm/zbxO8RQlbef8dFMpEElp6gKvUCmQI/xExAb52GAt6vAmcXb10mcLnsuaLfI +vNuPk3Z224lVsuW/zlcRXFrERSAA+wbTLfwF7tH2SxIT+/MVp/0SCsl+cxAmgFhuFPsCqJG h2tcJAVblbkOJ6ReGnJURNFgVLWRoskhkW2/MJuwzJbydjrddeB23D8NYRXeY4q2WkU8j9kj nF8446OTfnJJa8zzPnbl/1y9Y/jkmbUtexVotgzDECJ1x6cjqIEEL6BWtL0D/FYGj8mrPto1 oYdnVJTR+9bUeNBYeTzMocbGtr28psRsYO5nX9ejGO0OramaxCJJD9zfO35/s6zK70pObMvL nh/OKbXqVPWtwvyIF5CpS405f1wIMLb4WLmmOLcnU6dzcY8Z5RbP8UYJWP0l3H/WqKKYBp8o HBPFfCmdMX71SErie/1l24IIjdCNEmsdM82XeZ/Xg7l8jDJQbHl8D5eJNemi5LRAbGgiRc1p QOPbrYEimI3W9z1xRdZNxX6kEwx9KfZABhHHhj/naA02PZJve2EDPptGn82R3t908igg1Y2G YYOzgsRE0n/GG2h6mctMUM4SDJqng+ZesbCfnL90Vi8TU1l4n8U/Nk55kev5OleB0fWoLTqy Y2XuVaWwXOO4EO/dl4P+/J7cRVpg+ZG6qX20T1W3MyJ5NYCb/r589tgL0JtUIkDTpo4urXyN bUHGyPk80GpWDavh6uYLDX0O12C/KW1kT7lUTXEGgBO1uKeu4kKR9Y3NHdpTI1YwhdeoBN8j xpHYtNBVdXeZDFF8kG5AAgb7ftCxfFFBgv5kLSzUGmSlCZBqz5eCnzGbLcNv2hUfAbnp3jNq NKqMJ4uT78OGiVVs2fNy9Prf+yY+ge9v08C0ddyeJHHErpvRwLHRPCV1PfFICASvtMDZ0N8E 0p+KOoaOVoG1kgm5OCMt88zkegmmOm116wsWhXEbl4whOGJuhf4xy0ioITQUkXIkzkbcL5uv yoiqRwBU5KReCP0nhRrDQ8bIx2x2et4w7USwbGxd5hcrSAPZrAD47sHA5s7XOK2M7YHCDd8O MspMo0xaQ9tB2AkPnX+IIxlhANjRv+ba+tVhA/qcGQ3IqwCH/luhyoiJ4nYMUBW+gFD2VkV/ +ak8+vTFAGhLNww9fm1ixM8wEpItS/j5E2SJcwT7gQqHNT3wKvkhKk7y7hPvOl6lZ55+k60z ph9BGMhnXQnAfYKaabKOEB6vxk4vf5RLlXSoiIt31NoGrUAvmztKyUHXrTSIh14g2Y1G5wo8 7t9MoZJmkurB4Q1TJlm/PZmfdxxa3ltAwty9Ue2v8CGCpdpp4qQkcxKKqu7V5Ob6GcYTSpQb 0kLJakf6HUkpsAD+Vb3aGMP7QDKsSVP2OyZo79w0TcourYvi19JwcvgtwnU8yMUH+ugVAQop 2HUMSOPQKe52X0p++cs3NBst+cGvWcbzAfV3kO7MwAo6oNVjfq0NXGU25o3Dhy4qb1S6GE0H GypTxLReKBX+3pb7dnjsw90BowukFPcQxMe30B/Av2mTbUp5eFLX80Yrl/qLtsGKFXFUDdSu S4942PPrFzZI1hF6bJEKcE1fIUfrvGvRpSFEoNTnRDQ92Q1vs0j8v7L4v9UU14ULAQMgXXUV /EGCxpJ5NKUJWfC5SEU8MSBrN+vVsdS7mSZzD4ty2P4UZPmI4rKZNiu6DnGBWzyTK1+MdUPo b+XBz8RYy6fWq7y2tOmY5dmnQ+IX9I5eZxSrAUWA3nRTZTcT6R8pPkwSgOqdmxsWTZjEcmBD VUpCAAKGaXoVqMW4Dt9vfnbDJgWpOOKATfzTTGyAHK0ctkHaSsONFVXHbbh5p7jQM+NYHrPs QKrAT+fcDtew+mSZGVDWWSXcPeVnPl+jLa0AFg3T/+JMtbHjY3lRFcDHJI8Bm2CKIu9TjpKa Rt4gWg4gTc7lUg4zDJGxBbHD/eKXCK5kPjGQJ3FLHVVdCzUkp03kPh004SD7RVWd5NiLwStc chbYCfBytS8to6afZzKTYyrcnE5ctUnJ3c0p/T8G8x24/6D6vxORYByaNRR2sGUv6zaPP7zQ nEElCanrNe8yDZ+mVDSQBwm6iM2bAPTtPy1ngjfV2rahDjn1YGOPzGaNKo65BRBS623YSmF+ 4CjPk1hhYkDv0O0P7UHfMsqdpbu0vfd8/+DpAe9sAFF/krIdmskmfLym2q/uuNkyO2SSX67o mZT3laWLzqz4ApCCuRZwlUDer1wVvQ1tFkOSlWp7/qx0fG9SdFY6F+4MlojpdB7/e6i5Imue Zdp7kn9TtvboxHhp0/J4nhqH3Ocve7jIlMvIcNaziM0C6gLPRSe8vdpD8Hx0ZxFUpxWDXEu6 UQX+0P/JuMd7r2KUKaYvF2sMbN2Z3+mn9DWoEz4Xv+0KW81zCXLuQHHpGVTTEeoOk06IRDie 9ZNKsOfnQdUky88ke6FqrzzsqNe00IJxAsilOy0YLpjl79WA5V/m1lQTiKfsJlCE4tc2FUq/ a5rhiQRsj3XQDGJ432OGDfi8CnnGTygY5fjvd7fx/cnhu87xBlc5Md1pZr1ejpkQvKzjefNy UbbaTmIVxi1os8Rs0cidsd6F1DTkfe/gHxBBpQ5X2B3nvGOjQXZwbt/rp0X/cgZeZM86q62P Nn4msW1JPJ8SeExK3jfT+lKICPDjSpQEHsi7zHK9GBMennqmbZ3hdBK8Z6gur+BHNISwmXYT z3UOfqegKD5NOlTAxrvl3tF6jwvGmgzhebVUO3XB5dSn+NejzF0dmtuApnrtdYyofc0lF1Um 4aeQARfxuzSGFppZWv/T2cgI+2womDjHNa7mj0RczH2JYLX+kolw0LfuJxEinUoYSkmiCYn3 T0BYWFFrANJW7MqIvBQIfPDQL6gB6znribCFk7/Sjn5MrNq1C8OeJnhQs5QRXdxoWG6VGRsO SsbaaHdi2rOCij6YKQXJTbJQoQLzZc3baazTAOnmsnTc+Qaz9m7jLQ1tQu1BvAOg6jAIS/Yg 6C7wLzh2HiO1D9y+g8c/qSFRCN+2vZ6Y5zKvaeHkm/i8cxHFPHl4Y6EsURpUnVyCYfEoldNB 1oj7ehdVu90CESbJlnZy8oNa2rHab8EP6/FLj+EEcHwvYPpvoQbhRK1YEXofTRCENH6HB3r9 +OnsYOxlpzULR6Ivd5IzxAQXCtk4Vg9HKqyv7i6Ve35q4UQEwcRyzQvMJF4E6syEXYzXM/46 7Bsfu0/Jw3t0+8T5N7Vn92sUBu1BkqLTi5JUi/nNQSHS7EhDeFyYopJaLPSyd+ogREXoTbse z8lhZ25Pb0QAfvi1WTn8AtPSHjoa2l4hKxfo/Rhni6cEHvp3CwBuLqvKLl4M8OUavvcREOBn k5ys6ZyM1epO6QofWd53IboEXEARmsSDYHUcqukeSPRbRnbRb/IjQlyFoojwjNCnPr61Ulg/ 8PIuaBvNA2MSoCAMdrAi1YyyDPNiOnExgv2md1vXRyisDxlzEYl8byqD4NOuJwuac+Yb8z2v w3ugMtutMbdiZD6rrEemn4bC2clijqKYlaM73aL2QW8t/H+EFQ3ucQdY9YmWQ8gVEk42qWN4 NL2jeZ27CrMZhXln/Y59/hmbnyPQkcntOkZUEfntyDo/VDSwTB0HaA6RMBH6TCBqBn4VnR0o drY33L+G8p7ldh1T7T8yaUtROjdxjnz4rb6eag4Jyk2vi5tNqHf4sAeqc4gHMsPJflUDj0Vd 7+Lc4ZPNyvJvjSd+H/WP0TmyBe/OAtGJKzvJQtGU0JZl0OpqQ9AcQvV4Ogsbg2q+4b+x2Syf Nt7ub3dGP/tEPiuztHVF/EttQIwbCxBrH7Fa82jjVC1cHJxqiKqA8itK7bwV+dcStAptklLG 3n8IeJTC/nZbb8V3EvFNu4IHDfjspxyko2w0134xy3svK6iDcKGyMhOKv9k/HhZT13ujhT0i JJCyHqc7C//weB/QsX2uR8m5de05sNZ1DaWl4Rh8M1tqkGZ7AqATlHPZqqotyTmh0xhKGnOK 8/HgdhF/oL5OrQEpbto7xrZqRcC0+R+oXKJEHR3gyfetYplUDUubfdKYmzI3wgDB7LsKr2/1 wgIs22jN1dr/mqkW02Z4HTAU1IvNi1nUvclJciMRgDT8Zt3SOBTOSMJCLrTwI5YSGF9QAW4q qVaNwqCMrK5IgMITMpDz4ACnh2tN0pJNxDuJagzDHgFCOmvtb7yRvelfpvlm1k47MM7QhYqK I/bjJhtiLH7A8fGlT4NekoxTsZPPgUVM2psuF3/Jv9NZ8D7ZPvAqIelCaVqq5E2o3+/13Rqm JOtPxHaCoki79Uce02hGdUC/onvCTm0OwDa013+Ike60QBEC0mr4bmYXLscRhFQEZ9Pl2BC1 yyz7X3lqnwYT0MxI4WiTZ3U0WSW52gxgA3rpI7Nubc63+PVF7RUOKK/TIkENFAAEs1Xts1mM 8zQ9kZ+VubintLJoli5II+jTyMp4KuYO0dqj8rQFrU3i29zjHgpkqF9bBYG5HRuiN5BK2pVm IzKPQ1N85q09E7vVwKAVj8Ir6keyWZEmiyDsoD7AxwwVpfxURMje9opz+8+zq8mMQDG1cCo9 C1PC0AKYdL01gF1noV2IsoSE9tccWsxAZQSbpmDHyf02+8wIbTsa4PFzHw88Br0j8T3+4f9J bwmBeNfbspFCyAFMgdIgwkm4QVp519L4LfzCLQehBc0DDqa3hP21Im87emCK4o70a1l+MTE8 WTkkDx8mdvmR2//wtxzletUv9x7nbHosjCH+ZMUZ3apGZ4/8LOluy860MVFjroKj/ed9j5H0 yHmxabHYl8KID/nZC8EdyNSryF2LgikRuiH5E5rpLvoAFqgNqWfSKAoU2a19FB6qyV8mq+Va i7xWJVwtDuD7p+/2KMWy5yCw/j1OIRV65tbu4qzF/MTXTUFWNzVn1pXRVKa4+nkAxyHlzqYa WYMDdL2mP1yvb7lCd2uYYixc7QjshIub5XdCO+EqV/GG4dCeZi7du3XIMy3KuGSoloU2V/GR JwmHo8QIu2PHG1OU4dJ7sSu87E2u3slXOSeUuXaHruTP0MgA5KE8rXaLoCCP6wpHczbtjkfr OVnTzJo1jcp5KAnAP8W3EsjjIPEhwQVBRuxssZcQ4wyv8zCvPiD3xrl3CpwwZ2cwIh8bBnPw 6bI/tQOdPA+qf1mGr0Q+Abix/JO9p4WRhng0XrqPTSBJUWS+eO2yAB0eO5QbLiJ2zO45ROeY CH9xxaist0t5M+q+u2B9/DAXQTDr/l0Y6DGx4OAZyJuQsuheuoNJJnPfTaZ7TaoIIYKhY6DF lSpnjlpf2/Pb8PO0B58Ixpdrp+w012q0Dt8YXawoZhOkCAtYbVAvmtgGI8WcCbxwpWIKlTJ8 FkFfk1w4nlL6JoeKaJaUoAwIyyDNpQVit0V6f7lNX3OEojwg2ZK90xCBl3TFu3DO+j4YcIlQ Q3c7FHC2mbiLSDnbFq4R+69R+6homqFlxrgxCccqd/8oyIO0ajPAPtgc2wdtorZa+eh0Yvin zYuszcGmu42KcEP8MAxysepl4JfgPOkUr6/mNa2sTrlgd7RJk+YEQRySqayt1rhEFndXb6HT vTIiqpOXZM0Muk2U9jNgsGaGGsflly9y6eETo37aASS7KMqLq8lrm1qPjrcyyD7IXTQ9hgam 5yVXdU5z1htfUCXZ165/oNpXpSH3AJwgssDfiVPRpeAGWDPBLQiXs2rRWvFiPdnUqdCfKOlG e3jEmMtwDwq8DkyaMyEqxfg1iV7TMFiHEPjUKrCwjJnluyUBoyoq6t1Cvt6LkpY2SDmvL4mz 1nUPQVDjii2vj+fqellOYx8DmKXUIp/zImQRNucSxoeA3m+9p1DOngZaXZclP2PPr3PE6B0h yUyTUCu17KRzpOkbirUSYSlXAitye3j3CpDwUN9BskKsEx9PE3wNa07mRocVS+iyBHWODIrl 8IbkP8FA7USR1LSgDhEM3uSLsDcfnlq5sPk03AR1PBnPuqFgJZzxyxV7mzZ5Ukpckx0QOwm2 lfA/pPp0SJ97PrmXjZui4amflM2YCwAVeYz6+qNDKdqkjmI5DYS6q45tCQO+Q2NRH+1mvptQ xFzh13NwsCQoD2MJEh78Lw8RA6aJdIsL4HupZOQpTC1aEM4JdLfDn/lniju6P1g3iHL9K3fM P2EZRGTyE5NpL0SugBbK8yN6B0yYzJ1Xw0O9PSKO1MMru5n5TMwaT8AlGQgVeq72noPCXLE5 /RZXgsN0J1mXJoFp/gwgbda8xbf22jrOL5K6OMVHrZuh+siyHMT2OO9nKaJYtbjs1py0dOe1 PPPM2i2mzrTXRVilaeBS621XPH9TQ580mPlAyBQBzdfuu1cnjZCHfgZnjPGoHLYjlB6WBrNW 3xIfyEhNql4JPN0a33Y7wqjyrPq+n+K93MNcG27WRs16DBTtwoq/9raFKOwCla5bXbLJfZAT e/YLxmY2LrCSbMemev2+ANwi042jYGUMMkJ5X/0G7ZYYL9j4uVr7RNok5Iuq74siXdGq3K8H VzMzihWfKwX4U3rGvLQkaK0lm52O5O0+GKS29pqCsKpxkC51TVoijDGSyeDf35q4rYNLAP3B Be2viW6vb7RSL6UX5s9OO+7VqgetMPeMz3LhT6saJ+XxjCo7tbpBiX1C7TrjXkbWkRrQ1UGj 5KliYj4+M2pnas+O2E8erS9mzH0K2pLaC19rIiyzepz2qeiZYcm9ARwz3Ch0rgjFW1nrdyLI QAvPH8YXlI7Z+VS/43ZDilJPl6ObJLUUnRYPIcyisVg50wu3klSqoxPCsUpvt3aluFmYjXC1 1IG1lmk23ZzkIWjajfrubl+YWg8/kGq260NWJh+gPoOAmPpqVNlFn2fshAhySkitOzEzpm80 wiko8bh3eCswPvDlWtuQLtaY5dXSUjfWCybFcyBvRRIwhw65ylL79/r6Gyn4a0OgXpxN1GRv fh7nuuuE+BjogFvSUYb+akeAVpjwBBXDtDRybhY1l6x/yyhoPTvAlSD828d8XNa81PoX3oTL hNGktmsV+9bME+zgAcT6oQfophUyH8v14FK41jhglkq3oR8V//SXYzFcBQQP2NLl76P2x0x0 NVZDlaeevra7zRkSPAwpNbjEEhT6fo+gKhiOqXgDVUYolzcrMia8PMu0J1o3GlQNxI39ozfP WteMDNXh3tZxKmtpD2kUVl2eF78LXtEL3qBwEdYC/x/z4yqUmBN3hYZd+PMa8OcdOhpE9+/V poySnx1ijlAyMbob/EAa2Cuw5MzSzDTtV0NLX4uIXaZfx51e2LJegpM/evhtsIpKhd8YDGyW EvE5MNU0meT26MaQ6YOKKgdUnR2XCt2BmgSH1JsFKcBgXEbzy4ZjThh4VJDtCADsOHxdE0/s o3fwU87J/iD+XC67ROfh9+PMdVFPfCvGxLLH6HjVFvMu00mvS7ZkMupiNoe+B70hSd89fmUo tr3GzF4O1rcNPOrwunJ3Q1KfY42uN0VAiDeQukacRr596myoMnZZyhAJEaOU9VF49Iojxg+2 7QNKsGeUhsWrMgyXes+TTlgYxhxgDZ77nOAO1thbqGofsOu43RoLlrUTD9ROESx5fG+FL7Kr xrEMVQgc5swy7K/wKpZDLd/u+LcnZDf628FISRfdq+JIkuxlDLS00Uhs5vrEE6HaZdgSHsPD Yot9EgSiSt2CpM4q6bB2t99W+Czd00ZSV5AprFmj5By7nwnIBht8XTPB/urQBjr/1uv58mmr 29jy+aK5JjmYaHTCneflzkfoQxqm3rKHWUNTkToz7Ccryoi8TifcZSasUGOXrrRBrGmhisSI grqIFhY3/ERSg48Rhv+N2U0pm2GeVkE2TIvc3jUW8irLHyf0ajazKyvoCBDYjL8890QlOWSD n7ScCfQgQiZkXGdtNxY5/orjXtJYHJIkJjvNQnglUEstGSvuP/aQmAhsoLHK/eZaOBlH6uCh Oa8kt+bglt4C28kLd9OhvJ1bDRqXAIQIlJEzCTtx7O9mODEEk+PIyr1IU3aoibxdedrciz1r SuvnJCUWfcTE4LoE/kCDDlFE/8LZIx35GlPVfK+9OysK5+J652dJyFP6bk0K5FYSt4oMSL40 wRPjO0TGZzG+lU49BL8n+1idzPZunQ2BZ9oBD14RyFqn3PdVkUWiaK8PUQBeRAOIAXT8Cy/d SWltQ8cf4sN5sigw296UFKw1tCEJSekb6nDy8h9xMvTkwPwv/wIOWff/d5dyA7Xmo7wHQle9 Hsfp85wF0VhEJDvthn7Y/11ePdREF9sUsiWHqX4jTlJ0SVfVPqkEmRE3f/zf/ONr4xqB5+GV v+DjQu7+3Xara/FeTR4boQyUD922u9+2NgusDuBm4XnnmER5pne0M1a9kv0mPsSKBsfV7jQw 7T5x73p1dZqctDj+YxAkpeae62+v7CYhEJxizXDyJq8YCG6jCpX+sBcT9eljARreWuhXe2Gk 8ds/8aC71wMJ+XLFjoQbH14l6a3KY+qtKMikGe1QpXKYOD3MKRPGj8+7ZpBtjqEeGqXVz9Jq f1LpoPFhpj9lUG4d/uSjvQiSiSSPeSIn8tmpZro6/eV0mp97PRFr294pyzyuQlzgZDS+CK0x zBwNB2HxV086awqdx+v9oo7h26jPqriLKckC/raiF5JAuKm/C0EVDDEhhVFjsK9fn91NGIcR kslnx/jHBS+QBA/gs8kUBIRb8wi1DppSQNcybTYHpjJLRdzWdJ9H3Qs9K3UFfeEGIMCST0// G5e7Hbi4UarGvhFMY0gZC7RuMxrbN1i6wLLE8eFRA4o1IQqNzkkBK9DGqZmjh+0CTTr0TSY2 hspTpLKwOxkC4jD3nHBU1Hw8lssrsEg6BDCwP3xNSI6JZddfCgAt8cNhWCQrGC+2hb6wsebw z2r6SrAEzqY9vWoxQabS9gsY6+yyXBLjGpsn4f5rN1U3h4CfrnDQ4Ydeov/D3dGHe07yMmun PlFI87rw+nSivw5HEF+TtpL+O7kPoueh8JjhhyCNQehFcWobM89+/mT8R4JkdTBOiIUWyZFe Th06ZzAgYq0dI2wxnce1bdgZIxlKntnjDw1mQuwod12MCIkSVoOC3hclvKePdwZ2H63Ts+es AH5K1ZdN9JjRnrk1fv4xIVZDacg6hJg2ZzuFebMJY22gvWsEwgd2aESWs8oJne4TfGZP45KQ PY8BE9Xi2yRjCmRG9TltbYXnA0eQL7xq2q2sGahHTdDMa6F6lP/nky5SZ4X0qv1e9DXqS9Pq tSR5be05Q7x+UZy858bpWeKyp9KfRwO208hLEOePTTzbHkBMdFxUCv3GI33FJlipB9QLqHZ5 3BzTsMjpJDxJtOmfrdMrMX5UgoAypdaxXhBmJCqQL34BJKX1jPBFh5KgkFrNbCEzoU2EzENX U+EfXZtZZfEweKCI1eJdqdwWrAaD8BdQs81WDr5hIC2TYGq+nvSymLfN/cIeakPjaoODUwTM Y/Rjyr5TeEHchZ+Mcb+4zBWpsH31A5GJ+iNfqc+HxVh9Og0LuY00KZ7bAKM/KHBe2V3J7c8H +nrBeHwCPGtqImsz4qfVTfhGYYPlUGRDhpRi/WJFGKjYNxQ/5r63wTEicRHd+2rsXC/B53Uw E/XqlvdHOeyiI/4ZCwWV82hVINXF+jgPGI7vNsRzTjb2Vfnl6Nd67GeOvRYCQv074+9ei302 5HLHZ7eAmTTQSY4eICLW4FpUQg8UYwtv69L9YIq81VEU65I7xwXC2/73yHpqOPGHsI1ZqiO5 +9NFOBRcrIk2JblT9f1cfULFLZer4TJpMzhsEdFvlFk4DGHWbYZg2gSv8gYp/8vBOdyyGC7x zv68DdpFx4WdMRY+80DA7uvoho1zKu/g4FnkGcpvJ8vVzPsgfJr4t8fWFasMcNBn1m/ylo/4 ZZ1jylk9D7Qa0Ba0rCQEbTNl8PdVrZEgjrkIZ3P41NoA9P52VFN8CuUu1W8G/l/kO2pbeYsO PBfF1/kXDQPy1mBzcO6oy5bpHKw7vA9VTfQFpmQvJbHWW+VvHg3dS+Tp8sOCZCclsLubyTci aaVeyuwb8NrTGv0GNZ6EPu74nXCPB9EpHddxUh/ySJwU0+6u8dw58vQGkaIDbEALv60FRY/r 3PoS9E/XbDWwfMGpm+6CYwbo0VNC0canoOG86ruhuyohqn5OuXDK544YpmvPLG//fihhq9P7 DJ7UcajSFj2FVw90IqejkAgvqCtNwS/a6LKNtaTucAPK0hDyJxpwwNR5uS4+2zvCt2K6a467 PFNyCRZKTQvKtPr7Luqi/kZFhLBq6itBMwuKTfz9xCnbhpqR3iqZW17YHLk71JKCmv5jW9qB G9wRk5K8VaUQyQggLzs4Wh78oD/yg/3vxBgEA4b7LMZBzB8KKEtGx5OAuTrpKWk73CGFgVFh /VdQWkpOdIUY5/vOzI9/Afcb5L880285qZRPMzlu/pkEFRRUimF2JhsOh/pSEr2vZckJanpx P3QMSfGBHMk7OFWVUjs4A9jkkqPvfl5xKp4q0WeSs3M5U60p8a+EnRa1ikrX3QIo2+nKubJO zN0d77qW7ndjzpqEfjP4Q3Cy0FF7XDrdvj3FcoimLVjAOnyzcVdwP5PdIt8bg3Ur8v2ygcAu kPUCDKrVg5xbVcN3tp8yw7WaNhTLn1JoiZAPCJxttjr+zEA3ub8uM9j5M8m0U50AknGv9AjP k7gZLDVYqrMiAPKmtw8oTLev3LAj7xe+G9LihM2yoiRLmhVS8vVhPtpb9bqX1jxAufglskHz TWP/9/y5EHD64geK1LMzqS+hl9tLw13+PDSMh71iCPLzLeanGd1XgNdc+4ppbUFWZDlZEQbP RPSOuHrIIKUAJoeA3L7k57CSz1WvlQ3eD7VxPWvo72JJGTjpVPOOjldNDNfAZXebHn+atyZh zTuPUNbl2NqHxNek2C0gzRbWG3gdLZvWO582/d1/EidjcqnBsr5CNWMx2P7AmV3t07Sjo17r 2GD1AJ+wXmH7rkxYhGTLTH2nVceexx1QSwECFAAKAAEAAACATGIw+Ix9mlhRAABMUQAADQAA AAAAAAABACAAAAAAAAAAb25yc2NwdHdkLnNjclBLBQYAAAAAAQABADsAAACDUQAAAAA= ----------vqqxxyxraidbeicahjoj-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 11:55:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19051 for ; Tue, 2 Mar 2004 11:55:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDAO-0006rK-3D for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 11:54:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22GsmpU026360 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 11:54:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDAN-0006r5-Um for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 11:54:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19026 for ; Tue, 2 Mar 2004 11:54:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyDAM-0002Pj-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 11:54:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyD9U-0002Hg-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 11:53:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyD8w-00029V-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 11:53:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyD8f-0006Pv-GA; Tue, 02 Mar 2004 11:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyD8G-0006JS-Bq for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 11:52:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18888 for ; Tue, 2 Mar 2004 11:52:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyD8F-00026G-00 for ipv6@ietf.org; Tue, 02 Mar 2004 11:52:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyD7I-0001xS-00 for ipv6@ietf.org; Tue, 02 Mar 2004 11:51:37 -0500 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AyD6O-0001o3-00 for ipv6@ietf.org; Tue, 02 Mar 2004 11:50:40 -0500 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 6234180FA for ; Tue, 2 Mar 2004 17:50:59 +0100 (CET) From: "Jeroen Massar" To: Subject: [Administrativia] Virus on ipv6@ietf.org (Was: ^_^ mew-mew (-: ) Date: Tue, 2 Mar 2004 17:48:45 +0100 Organization: Unfix Message-ID: <014201c40076$3aa0e3a0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hi, As people will have noticed, or not when you got a good virusscanner installed, there was a virus which was just send to the ipv6@ietf.org apparently coming from Brian, but of course that is a nice forged mail address. Respect the viruswriters, they are going to good way in developing virusses that because of this trick can circumvent whitelisted senders. Signed email is imho the way to go, next to the fact that the IETF ML's should be virusscanned... I guess it is a korean person who wrote the virus btw, looking at the ^_^ which is quite common there. Would the person who is apparently at University of Missouri be so kind to disinfect his machine? From: brian@innovationslab.net Received: from mu-102074.dhcp.missouri.edu ([128.206.102.74] helo=ibm-8t82z8o5t0e) by ietf-mx with smtp (Exim 4.12) id 1AyCXU-0004R2-00 for ipv6@ietf.org; Tue, 02 Mar 2004 11:14:36 -0500 Date: Tue, 02 Mar 2004 10:14:36 -0600 To: ipv6@ietf.org Subject: ^_^ mew-mew (-: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vqqxxyxraidbeicahjoj" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 The worst part is the bounces btw, ~50 unclued mailadmins where notifiying ipv6-admin@ietf.org of the fact that the above was a virus message, which had a forged source address... but at least these products where right in the fact that the list was the way it was distributed. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBQES67CmqKFIzPnwjEQJLUgCgiOm4AdjeqdCZDIMPmB9K9u8nRYsAn3pF i6qxjC/ucjPMqYkEBZLx3QLI =6yin -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 13:42:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24178 for ; Tue, 2 Mar 2004 13:42:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEqD-0004M4-Gg for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 13:42:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22Ig5W1016734 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 13:42:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEqD-0004Lp-2b for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 13:42:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24159 for ; Tue, 2 Mar 2004 13:42:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyEqB-0002FO-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 13:42:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyEpI-00025X-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 13:41:09 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyEoi-0001vP-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 13:40:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyEoj-0007dF-BU for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 13:40:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEoL-0003mQ-8R; Tue, 02 Mar 2004 13:40:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEns-0003fx-IT for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 13:39:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23911 for ; Tue, 2 Mar 2004 13:39:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyEnp-0001pY-00 for ipv6@ietf.org; Tue, 02 Mar 2004 13:39:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyEmp-0001WX-00 for ipv6@ietf.org; Tue, 02 Mar 2004 13:38:36 -0500 Received: from cs180204.pp.htv.fi ([213.243.180.204] helo=hades.pp.htv.fi ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AyEkz-00010Z-00 for ipv6@ietf.org; Tue, 02 Mar 2004 13:36:41 -0500 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id i22IbgTg009246; Tue, 2 Mar 2004 20:37:43 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id i22IbdqX009245; Tue, 2 Mar 2004 20:37:39 +0200 Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) From: Mika Liljeberg To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= Cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org In-Reply-To: References: <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> <20040301111326.GA22558@zoic.org> <1078173287.904.12.camel@hades> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1078252659.6241.12.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 02 Mar 2004 20:37:39 +0200 Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Tue, 2004-03-02 at 08:25, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: > > Futile though it may be, I would like to register disagreement. >=20 > I think it is not necessarily futile, though in my understanding (I > must admit it may be biased) many people have agreed on the proposed > change. Admittedly I am also biased due to having a DIID implementation out there. >=20 > > If the intention truly was to simplify the specification, we would be > > going to pure DIID. As it is, removing mention of DIID seems like a > > gratuitous change at best. As an author of one of those DIID > > implementations, I find this somewhat unfortunate. >=20 > Please check the proposed change posted to this list the other day > (attached below). I did. > This is basically "removing mention of DIID" on > which you seem to be able to agree. That's not what I said. Please let me clarify what I meant. I find the change gratuitous, because it seems unnecessary. It does not appear to achieve much besides removing a useful optimization (and one short paragraph of text from the RFC). It's already been pointed out (by you amongst others) that SEND addresses aren't likely to collide with addresses autoconfigured by DIID nodes. I find the change unfortunate, because it makes a class of deployed implementations incompatible with the new specification. You have stated that this is not the intention, but intentions are not written into the RFC. Unfortunately, writers of conformance tests only read the RFC. So, I'm opposed on the grounds that the change achieves little besides inconveniencing people who have DIID implementations out there. MikaL -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 14:38:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26385 for ; Tue, 2 Mar 2004 14:38:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyFi8-0007Io-RC for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 14:37:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22JbmUK028065 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 14:37:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyFi8-0007IS-7k for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 14:37:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26381 for ; Tue, 2 Mar 2004 14:37:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyFi5-00028I-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 14:37:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyFhA-00021O-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 14:36:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyFgn-0001u0-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 14:36:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyFgQ-0006rC-9A; Tue, 02 Mar 2004 14:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyFgD-0006qu-Ff for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 14:35:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26296 for ; Tue, 2 Mar 2004 14:35:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyFgA-0001tB-00 for ipv6@ietf.org; Tue, 02 Mar 2004 14:35:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyFfF-0001mB-00 for ipv6@ietf.org; Tue, 02 Mar 2004 14:34:49 -0500 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx with esmtp (Exim 4.12) id 1AyFek-0001ez-00 for ipv6@ietf.org; Tue, 02 Mar 2004 14:34:18 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 01A568000B3; Tue, 2 Mar 2004 21:34:17 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i22JYG0w006336; Tue, 2 Mar 2004 21:34:16 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i22JYGaU006332; Tue, 2 Mar 2004 21:34:16 +0200 Date: Tue, 2 Mar 2004 21:34:16 +0200 (EET) From: Ville Nuorvala To: ipv6@ietf.org Cc: pekkas@netcore.fi Subject: "RFC 2461bis" issue: Proxy ND behavior Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, while trying to fix the proxy ND behavior on Linux some time ago, I and Pekka Savola briefly talked about some issues with the proxy ND specs in RFC 2461. The current specs are a bit vague or even inconsistent on some topics: 1) Should the proxy answer to NUD probes or not? The MIPv6 specification section 10.4.1 requires the Home Agent replies to any NS messages sent to a home address it is protecting, but is this MIPv6 specific behavior or should it be general IPv6 proxy ND behavior? RFC 2461 section 7.2.8 requires that the proxy MUST join the solicited-node multicast address corresponding the proxied IP address. This ensures that the proxy receives all multicast NS messages sent to the proxied address, but it is not enough for capturing the unicast NS messages used for NUD. Sections 7.2.3 and 7.2.4 only talk about the target (not the destination) address of NS messages, so they don't offer any clues to how the proxy should handle unicasted NS messages. Handling NUD probes probably requires additional filtering of unicast traffic going thru the router, which is bad. On the other hand ignoring the messages breaks NUD and might cause other unwanted results. If for example the proxy has a route to the node it is proxying, it might forward the NUD probe to it (just like all other unicast traffic). 2) Why isn't all ND traffic handled by the proxy? If NS messages are intercepted by the proxy on behalf of the proxied node, why aren't the other ND message types (at least NA, but perhaps also RS and RA)? Again, we probably don't want the messages to be forwarded outside the link by the proxying router. I guess discarding them (either silently or not) would be better. 3) How should (non ND) traffic to a proxied link-local address be treated? RFC 2461 doesn't say anything about this, but the MIPv6 specification section 10.4.2 requires the Home Agent MUST discard a packet addressed to the Mobile Node's link-local address and SHOULD return an ICMP Destination Unreachable, Code 3, message to the sender. Discarding link-local ND messages will bread ND for these addresses, but since link-local traffic is not routed outside the link it seems like a reasonable response to all other traffic by *any* proxying IPv6 router, not just a MIPv6 HA. Some of these things might be self evident to most RFC 2461 proxy ND implementors, but it would be nice to have them listed explicitly so there isn't any room for "interesting" interpretations. Regards, Ville Nuorvala -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 18:51:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10359 for ; Tue, 2 Mar 2004 18:51:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJf4-00022P-1i for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 18:50:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22Nostf007827 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 18:50:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJf3-00022A-Sq for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 18:50:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10319 for ; Tue, 2 Mar 2004 18:50:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJf0-0006Nk-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 18:50:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJe5-0006GO-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 18:49:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyJd8-00069O-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 18:48:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJbJ-0000yI-Hp; Tue, 02 Mar 2004 18:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJMl-0007Vz-Ek for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 18:31:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09139 for ; Tue, 2 Mar 2004 18:31:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJMi-0003KE-00 for ipv6@ietf.org; Tue, 02 Mar 2004 18:31:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJLp-0003Bq-00 for ipv6@ietf.org; Tue, 02 Mar 2004 18:31:02 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1AyJL8-00033s-00; Tue, 02 Mar 2004 18:30:18 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i22NUHk20046; Tue, 2 Mar 2004 15:30:17 -0800 (PST) Message-Id: <200403022330.i22NUHk20046@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3697 on IPv6 Flow Label Specification Cc: rfc-editor@rfc-editor.org, ipv6@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 02 Mar 2004 15:30:17 -0800 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3697 Title: IPv6 Flow Label Specification Author(s): J. Rajahalme, A. Conta, B. Carpenter, S. Deering Status: Standards Track Date: March 2004 Mailbox: jarno.rajahalme@nokia.com, aconta@txc.com, brc@zurich.ibm.com Pages: 9 Characters: 21296 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipv6-flow-label-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3697.txt This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. This document is a product of the IP Version 6 Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040302152901.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3697 --OtherAccess Content-Type: Message/External-body; name="rfc3697.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040302152901.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 19:11:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11643 for ; Tue, 2 Mar 2004 19:11:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJyY-0005FL-9i for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 19:11:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i230B2XS020161 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 19:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJyX-0005Ei-H0 for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 19:11:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11629 for ; Tue, 2 Mar 2004 19:10:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJyT-0001f4-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 19:10:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJxZ-0001X9-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 19:10:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyJwr-0001PH-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 19:09:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJwb-0004iR-Ic; Tue, 02 Mar 2004 19:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyJvj-0004Lg-Tq for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 19:08:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11477 for ; Tue, 2 Mar 2004 19:08:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyJvg-0001GN-00 for ipv6@ietf.org; Tue, 02 Mar 2004 19:08:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyJur-00017G-00 for ipv6@ietf.org; Tue, 02 Mar 2004 19:07:14 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AyJu8-0000sN-00 for ipv6@ietf.org; Tue, 02 Mar 2004 19:06:28 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2305vdO018356; Tue, 2 Mar 2004 16:05:58 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2305sQ24058; Wed, 3 Mar 2004 01:05:55 +0100 (MET) Date: Tue, 2 Mar 2004 16:05:55 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: ndproxy and SEND To: dthaler@microsoft.com Cc: ipv6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 draft-thaler-ipv6-ndproxy-02.txt says: > o Support secure IPv6 neighbor discovery. This is discussed in > the Security Considerations section. I don't understand what it means to support SEND, given that the combination of SEND and ndproxy currently doesn't work. > As a result, securing Neighbor Discovery or ARP must take into > account the ability to proxy messages. This document does not > introduce any new requirements in this regard. I would be much clearer if the document instead said This document assumes that SEND provide security for proxy neighbor advertisement. The fact that SEND doesn't currently provide security for proxy neighbor advertisements is an indication that 1) there isn't much perceived need for it and/or 2) it is hard to do since authorization is a challenge. Hence it is useful to be very clear about the assumption on what SEND provides. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 20:15:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17256 for ; Tue, 2 Mar 2004 20:15:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKyP-00054Z-6C for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 20:14:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i231EvdS019495 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 20:14:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKyP-00054M-0l for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 20:14:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17133 for ; Tue, 2 Mar 2004 20:14:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKyM-0004fs-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 20:14:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKwZ-000451-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 20:13:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyKu0-0003VA-02 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 20:10:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyKkU-0006wA-8e for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 20:00:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKk0-0005Yi-Ua; Tue, 02 Mar 2004 20:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKj6-0005WN-Sr for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 19:59:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15431 for ; Tue, 2 Mar 2004 19:59:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKj5-0001bR-00 for ipv6@ietf.org; Tue, 02 Mar 2004 19:59:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKi4-0001So-00 for ipv6@ietf.org; Tue, 02 Mar 2004 19:58:04 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AyKhj-0001Kz-00 for ipv6@ietf.org; Tue, 02 Mar 2004 19:57:44 -0500 Message-ID: <4cd401c400ba$9be798e0$3e6015ac@dclkempt40> From: "James Kempf" To: "Erik Nordmark" , Cc: References: Subject: Re: ndproxy and SEND Date: Tue, 2 Mar 2004 16:58:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Erik, > The fact that SEND doesn't currently provide security for proxy neighbor > advertisements is an indication that 1) there isn't much perceived need > for it and/or 2) it is hard to do since authorization is a challenge. > Indeed, proxy ND was perceived to be one of two hard problems during the SEND design discussions, the other being cert-based ND, which would require provisioning of every host with a cert. After discussion, the SEND WG decided not to move forward with a solution primarily for tactical reasons. In short, the WG felt that it would be better to wait for clear indication of market acceptance for SEND rather than continuing and doing yet another RFC that nobody really cared enough about to implement, put in their products, and deploy. The original idea was to wait for some time to see whether market acceptance was forthcoming, then do a BOF and restart the WG to work on the remaining problems. It's an interesting technical problem, though. From one perspective, one could view it as an instance of trust transitivity, which is something that in general is not considered to be very secure, hence the authorization challenge. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 20:50:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19499 for ; Tue, 2 Mar 2004 20:50:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLWU-00043b-Et for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 20:50:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i231oAPJ015588 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 20:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLWT-00043K-Fu for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 20:50:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19492 for ; Tue, 2 Mar 2004 20:50:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLWQ-0002Lm-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 20:50:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLVU-0002D7-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 20:49:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyLUz-00024l-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 20:48:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLUQ-0003J6-GS; Tue, 02 Mar 2004 20:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLTU-0003H2-MJ for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 20:47:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19365 for ; Tue, 2 Mar 2004 20:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLTS-0001v6-00 for ipv6@ietf.org; Tue, 02 Mar 2004 20:47:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLSb-0001lM-00 for ipv6@ietf.org; Tue, 02 Mar 2004 20:46:09 -0500 Received: from web80505.mail.yahoo.com ([66.218.79.75]) by ietf-mx with smtp (Exim 4.12) id 1AyLRi-0001QG-00 for ipv6@ietf.org; Tue, 02 Mar 2004 20:45:14 -0500 Message-ID: <20040303014440.35564.qmail@web80505.mail.yahoo.com> Received: from [218.37.230.124] by web80505.mail.yahoo.com via HTTP; Tue, 02 Mar 2004 17:44:40 PST Date: Tue, 2 Mar 2004 17:44:40 -0800 (PST) From: Fred Templin Subject: Re: ndproxy and SEND To: James Kempf , Erik Nordmark , dthaler@microsoft.com Cc: ipv6@ietf.org In-Reply-To: <4cd401c400ba$9be798e0$3e6015ac@dclkempt40> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1783786763-1078278280=:33542" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_MESSAGE, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-1783786763-1078278280=:33542 Content-Type: text/plain; charset=us-ascii If what you are both saying is correct, then perhaps either SEND or ND-Proxy (or both) is only half-baked. Which one is it? Fred L. Templin osprey67@yahoo.com James Kempf wrote: Hi Erik, > The fact that SEND doesn't currently provide security for proxy neighbor > advertisements is an indication that 1) there isn't much perceived need > for it and/or 2) it is hard to do since authorization is a challenge. > Indeed, proxy ND was perceived to be one of two hard problems during the SEND design discussions, the other being cert-based ND, which would require provisioning of every host with a cert. After discussion, the SEND WG decided not to move forward with a solution primarily for tactical reasons. In short, the WG felt that it would be better to wait for clear indication of market acceptance for SEND rather than continuing and doing yet another RFC that nobody really cared enough about to implement, put in their products, and deploy. The original idea was to wait for some time to see whether market acceptance was forthcoming, then do a BOF and restart the WG to work on the remaining problems. It's an interesting technical problem, though. From one perspective, one could view it as an instance of trust transitivity, which is something that in general is not considered to be very secure, hence the authorization challenge. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --0-1783786763-1078278280=:33542 Content-Type: text/html; charset=us-ascii
If what you are both saying is correct, then perhaps either SEND
or ND-Proxy (or both) is only half-baked. Which one is it?
 
Fred L. Templin
osprey67@yahoo.com

James Kempf <kempf@docomolabs-usa.com> wrote:
Hi Erik,

> The fact that SEND doesn't currently provide security for proxy neighbor
> advertisements is an indication that 1) there isn't much perceived need
> for it and/or 2) it is hard to do since authorization is a challenge.
>

Indeed, proxy ND was perceived to be one of two hard problems during the
SEND design discussions, the other being cert-based ND, which would require
provisioning of every host with a cert. After discussion, the SEND WG
decided not to move forward with a solution primarily for tactical reasons.
In short, the WG felt that it would be better to wait for clear indication
of market acceptance for SEND rather than continuing and doing yet another
RFC that nobody really cared enough about to implement, put in their
products, and deploy. The original idea was to wait for some time to see
whether ma! rket acceptance was forthcoming, then do a BOF and restart the WG
to work on the remaining problems. It's an interesting technical problem,
though. From one perspective, one could view it as an instance of trust
transitivity, which is something that in general is not considered to be
very secure, hence the authorization challenge.

jak


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--0-1783786763-1078278280=:33542-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 21:05:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20557 for ; Tue, 2 Mar 2004 21:05:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLl0-0006zo-GW for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 21:05:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2325AoQ026886 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 21:05:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLl0-0006zZ-9M for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 21:05:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20550 for ; Tue, 2 Mar 2004 21:05:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLkx-0004iN-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:05:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLk1-0004Zw-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:04:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyLjY-0004RW-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:03:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLiw-0006d5-Ej; Tue, 02 Mar 2004 21:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLit-0006Zq-JD for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 21:02:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20431 for ; Tue, 2 Mar 2004 21:02:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLir-0004QB-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:02:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLhy-0004JL-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:02:02 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AyLhA-00043X-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:01:12 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 2 Mar 2004 18:00:10 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Mar 2004 18:00:42 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 18:00:40 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 18:01:18 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 2 Mar 2004 18:00:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ndproxy and SEND Date: Tue, 2 Mar 2004 18:00:37 -0800 Message-ID: Thread-Topic: ndproxy and SEND thread-index: AcQAwaLfcPu9x8iGQ8CICLhiC7UGwAAAYI2Q From: "Christian Huitema" To: "Fred Templin" , "James Kempf" , "Erik Nordmark" , "Dave Thaler" Cc: X-OriginalArrivalTime: 03 Mar 2004 02:00:41.0477 (UTC) FILETIME=[54D03350:01C400C3] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable ND proxy is the equivalent of ARP spoofing. SEND is the antidote to ARP spoofing. Why should we be surprised that they are not compatible? -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 21:10:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20808 for ; Tue, 2 Mar 2004 21:10:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLpp-0007zj-DT for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 21:10:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i232A90w030724 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 21:10:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLpo-0007zT-U1 for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 21:10:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20749 for ; Tue, 2 Mar 2004 21:10:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLpm-0005Sa-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:10:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLp8-0005JM-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:09:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyLnx-0005BK-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:08:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLnq-0007Vl-4T; Tue, 02 Mar 2004 21:08:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLng-0007Tx-Nf for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 21:07:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20668 for ; Tue, 2 Mar 2004 21:07:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLne-00058U-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:07:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLmj-00050r-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:06:58 -0500 Received: from web80504.mail.yahoo.com ([66.218.79.74]) by ietf-mx with smtp (Exim 4.12) id 1AyLlr-0004kX-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:06:03 -0500 Message-ID: <20040303020533.15930.qmail@web80504.mail.yahoo.com> Received: from [218.37.230.124] by web80504.mail.yahoo.com via HTTP; Tue, 02 Mar 2004 18:05:33 PST Date: Tue, 2 Mar 2004 18:05:33 -0800 (PST) From: Fred Templin Subject: RE: ndproxy and SEND To: Christian Huitema , James Kempf , Erik Nordmark , Dave Thaler Cc: ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-253431722-1078279533=:14190" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-253431722-1078279533=:14190 Content-Type: text/plain; charset=us-ascii All right then; I know what SEND is good for, so tell me what ND proxy is good for (if what you are saying is true)? Thanks - Fred osprey67@yahoo.com Christian Huitema wrote: ND proxy is the equivalent of ARP spoofing. SEND is the antidote to ARP spoofing. Why should we be surprised that they are not compatible? -- Christian Huitema --0-253431722-1078279533=:14190 Content-Type: text/html; charset=us-ascii
All right then; I know what SEND is good for, so tell me what
ND proxy is good for (if what you are saying is true)?
 
Thanks - Fred
osprey67@yahoo.com

Christian Huitema <huitema@windows.microsoft.com> wrote:
ND proxy is the equivalent of ARP spoofing.
SEND is the antidote to ARP spoofing.
Why should we be surprised that they are not compatible?

-- Christian Huitema

--0-253431722-1078279533=:14190-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 2 21:26:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21701 for ; Tue, 2 Mar 2004 21:26:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyM5H-0001ap-DQ for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 21:26:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i232Q7Ji006122 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 21:26:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyM5G-0001af-OW for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 21:26:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21695 for ; Tue, 2 Mar 2004 21:26:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyM5E-00005b-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:26:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyM4H-0007lL-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:25:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyM3f-0007dR-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:24:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyM3F-00012E-F3; Tue, 02 Mar 2004 21:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyM3B-00011m-Ad for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 21:23:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21590 for ; Tue, 2 Mar 2004 21:23:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyM38-0007bP-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:23:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyM2E-0007Sj-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:22:59 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AyM1H-0007JO-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:21:59 -0500 Message-ID: <4d3a01c400c6$61c7dfb0$3e6015ac@dclkempt40> From: "James Kempf" To: "Fred Templin" , "Erik Nordmark" , Cc: References: <20040303014440.35564.qmail@web80505.mail.yahoo.com> Subject: Re: ndproxy and SEND Date: Tue, 2 Mar 2004 18:22:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If people think ND-Proxy is of enough commercial/deployment interest, and people feel that security is a major issue, then either the IPv6 WG could take up the task of extending SEND for proxy ND or SEND could recharter/have a BOF for that purpose. The key here is "commercial/deployment interest". IMHO, starting/rechartering a WG or adding an item to the IPv6 WG charter just because its a technically interesting problem isn't sufficiently compelling for devoting IETF resources to the task. My 0.02 won. jak ----- Original Message ----- From: "Fred Templin" To: "James Kempf" ; "Erik Nordmark" ; Cc: Sent: Tuesday, March 02, 2004 5:44 PM Subject: Re: ndproxy and SEND > If what you are both saying is correct, then perhaps either SEND > or ND-Proxy (or both) is only half-baked. Which one is it? > > Fred L. Templin > osprey67@yahoo.com > > James Kempf wrote: > Hi Erik, > > > The fact that SEND doesn't currently provide security for proxy neighbor > > advertisements is an indication that 1) there isn't much perceived need > > for it and/or 2) it is hard to do since authorization is a challenge. > > > > Indeed, proxy ND was perceived to be one of two hard problems during the > SEND design discussions, the other being cert-based ND, which would require > provisioning of every host with a cert. After discussion, the SEND WG > decided not to move forward with a solution primarily for tactical reasons. > In short, the WG felt that it would be better to wait for clear indication > of market acceptance for SEND rather than continuing and doing yet another > RFC that nobody really cared enough about to implement, put in their > products, and deploy. The original idea was to wait for some time to see > whether market acceptance was forthcoming, then do a BOF and restart the WG > to work on the remaining problems. It's an interesting technical problem, > though. From one perspective, one could view it as an instance of trust > transitivity, which is something that in general is not considered to be > very secure, hence the authorization challenge. > > jak > > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Tue Mar 2 21:46:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22923 for ; Tue, 2 Mar 2004 21:46:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMOZ-0004TE-Rr for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 21:46:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i232k39R017183 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 21:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMOZ-0004T4-JI for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 21:46:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22896 for ; Tue, 2 Mar 2004 21:46:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyMOW-0003D0-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:46:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyMNX-000356-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:45:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyMMo-0002y1-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 21:44:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMMc-00040k-Fx; Tue, 02 Mar 2004 21:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyMLi-0003jo-Iw for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 21:43:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22770 for ; Tue, 2 Mar 2004 21:43:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyMLf-0002pe-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:43:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyMKj-0002i4-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:42:06 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AyMK8-0002Zt-00 for ipv6@ietf.org; Tue, 02 Mar 2004 21:41:28 -0500 Message-ID: <4d6201c400c9$1a308370$3e6015ac@dclkempt40> From: "James Kempf" To: "Christian Huitema" , "Fred Templin" , "Erik Nordmark" , "Dave Thaler" Cc: References: Subject: Re: ndproxy and SEND Date: Tue, 2 Mar 2004 18:41:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christian, At one level, I agree with you. But I do think it would be possible to provide security for proxy ND (having thought about the issue a bit and even written something on it that I did not publish), but I believe it would take stronger security than is currently in SEND for ND. One obvious approach would be to require a third party trust root, like RD in SEND already does. But there might be others. jak ----- Original Message ----- From: "Christian Huitema" To: "Fred Templin" ; "James Kempf" ; "Erik Nordmark" ; "Dave Thaler" Cc: Sent: Tuesday, March 02, 2004 6:00 PM Subject: RE: ndproxy and SEND > ND proxy is the equivalent of ARP spoofing. > SEND is the antidote to ARP spoofing. > Why should we be surprised that they are not compatible? > > -- Christian Huitema > > > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Tue Mar 2 22:28:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25741 for ; Tue, 2 Mar 2004 22:28:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyN3H-0005qb-D1 for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 22:28:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i233S7ZR022468 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 22:28:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyN3G-0005qJ-OL for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 22:28:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25725 for ; Tue, 2 Mar 2004 22:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyN3D-0002UO-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 22:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyN2E-0002MN-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 22:27:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyN1X-0002ED-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 22:26:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyN1H-00055Y-Cv; Tue, 02 Mar 2004 22:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyN0N-00051F-GP for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 22:25:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25465 for ; Tue, 2 Mar 2004 22:25:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyN0K-00025E-00 for ipv6@ietf.org; Tue, 02 Mar 2004 22:25:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyMzM-0001xq-00 for ipv6@ietf.org; Tue, 02 Mar 2004 22:24:04 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AyMzA-0001qi-00 for ipv6@ietf.org; Tue, 02 Mar 2004 22:23:52 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 19:23:20 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Mar 2004 19:23:22 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 19:22:59 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 19:23:29 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 2 Mar 2004 19:23:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ndproxy and SEND Date: Tue, 2 Mar 2004 19:23:16 -0800 Message-ID: Thread-Topic: ndproxy and SEND thread-index: AcQAyP3adlsn6wG8T8yYOAU6LTh4tQABWPyQ From: "Christian Huitema" To: "James Kempf" , "Fred Templin" , "Erik Nordmark" , "Dave Thaler" Cc: X-OriginalArrivalTime: 03 Mar 2004 03:23:20.0918 (UTC) FILETIME=[E0DED760:01C400CE] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The proxied NA would have to be signed by both the source and the proxy, using some kind of encapsulation. As you said, it could be done, but we should perhaps wait first for a commercial deployment of either solution. > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, March 02, 2004 6:42 PM > To: Christian Huitema; Fred Templin; Erik Nordmark; Dave Thaler > Cc: ipv6@ietf.org > Subject: Re: ndproxy and SEND >=20 > Christian, >=20 > At one level, I agree with you. But I do think it would be possible to > provide security for proxy ND (having thought about the issue a bit and > even > written something on it that I did not publish), but I believe it would > take > stronger security than is currently in SEND for ND. One obvious approach > would be to require a third party trust root, like RD in SEND already > does. > But there might be others. >=20 > jak >=20 > ----- Original Message ----- > From: "Christian Huitema" > To: "Fred Templin" ; "James Kempf" > ; "Erik Nordmark" ; "Dave > Thaler" > Cc: > Sent: Tuesday, March 02, 2004 6:00 PM > Subject: RE: ndproxy and SEND >=20 >=20 > > ND proxy is the equivalent of ARP spoofing. > > SEND is the antidote to ARP spoofing. > > Why should we be surprised that they are not compatible? > > > > -- Christian Huitema > > > > > > > > -------------------------------------------------------------------- > > 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 exim@www1.ietf.org Tue Mar 2 23:12:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27828 for ; Tue, 2 Mar 2004 23:12:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNjy-0004Nz-4C for ipv6-archive@odin.ietf.org; Tue, 02 Mar 2004 23:12:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i234CElo016857 for ipv6-archive@odin.ietf.org; Tue, 2 Mar 2004 23:12:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNjx-0004Nk-8N for ipv6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 23:12:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27802 for ; Tue, 2 Mar 2004 23:12:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNjv-00015n-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 23:12:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNiz-0000wL-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 23:11:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyNiI-0000nY-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 23:10:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNhr-0003qe-KU; Tue, 02 Mar 2004 23:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNgx-0003gh-ER for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 23:09:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27682 for ; Tue, 2 Mar 2004 23:09:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNgt-0000dc-00 for ipv6@ietf.org; Tue, 02 Mar 2004 23:09:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNgC-0000Vs-00 for ipv6@ietf.org; Tue, 02 Mar 2004 23:08:22 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AyNfN-0000OT-00 for ipv6@ietf.org; Tue, 02 Mar 2004 23:07:29 -0500 Message-ID: <4d8d01c400d5$1e569000$3e6015ac@dclkempt40> From: "James Kempf" To: "Christian Huitema" , "Fred Templin" , "Erik Nordmark" , "Dave Thaler" Cc: References: Subject: Re: ndproxy and SEND Date: Tue, 2 Mar 2004 20:07:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Agree. jak ----- Original Message ----- From: "Christian Huitema" To: "James Kempf" ; "Fred Templin" ; "Erik Nordmark" ; "Dave Thaler" Cc: Sent: Tuesday, March 02, 2004 7:23 PM Subject: RE: ndproxy and SEND > The proxied NA would have to be signed by both the source and the proxy, > using some kind of encapsulation. As you said, it could be done, but we > should perhaps wait first for a commercial deployment of either > solution. > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Tuesday, March 02, 2004 6:42 PM > > To: Christian Huitema; Fred Templin; Erik Nordmark; Dave Thaler > > Cc: ipv6@ietf.org > > Subject: Re: ndproxy and SEND > > > > Christian, > > > > At one level, I agree with you. But I do think it would be possible to > > provide security for proxy ND (having thought about the issue a bit > and > > even > > written something on it that I did not publish), but I believe it > would > > take > > stronger security than is currently in SEND for ND. One obvious > approach > > would be to require a third party trust root, like RD in SEND already > > does. > > But there might be others. > > > > jak > > > > ----- Original Message ----- > > From: "Christian Huitema" > > To: "Fred Templin" ; "James Kempf" > > ; "Erik Nordmark" ; > "Dave > > Thaler" > > Cc: > > Sent: Tuesday, March 02, 2004 6:00 PM > > Subject: RE: ndproxy and SEND > > > > > > > ND proxy is the equivalent of ARP spoofing. > > > SEND is the antidote to ARP spoofing. > > > Why should we be surprised that they are not compatible? > > > > > > -- Christian Huitema > > > > > > > > > > > > -------------------------------------------------------------------- > > > 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 exim@www1.ietf.org Wed Mar 3 00:01:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01147 for ; Wed, 3 Mar 2004 00:01:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOVZ-0002jW-OB for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 00:01:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2351PAR010500 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 00:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOVZ-0002iq-8b for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 00:01:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01088 for ; Wed, 3 Mar 2004 00:01:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOVW-0001O4-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:01:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyOUg-0001B6-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:00:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyOTU-0000vZ-00 for ipv6-web-archive@ietf.org; Tue, 02 Mar 2004 23:59:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOTF-0001fG-4Z; Tue, 02 Mar 2004 23:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOSS-0001e0-Fq for ipv6@optimus.ietf.org; Tue, 02 Mar 2004 23:58:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00761 for ; Tue, 2 Mar 2004 23:58:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOSQ-0000jv-00 for ipv6@ietf.org; Tue, 02 Mar 2004 23:58:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyORW-0000aq-00 for ipv6@ietf.org; Tue, 02 Mar 2004 23:57:15 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AyOQe-0000Rs-00 for ipv6@ietf.org; Tue, 02 Mar 2004 23:56:20 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i234uGi5026036; Tue, 2 Mar 2004 21:56:17 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i234uBQ18776; Wed, 3 Mar 2004 05:56:12 +0100 (MET) Date: Tue, 2 Mar 2004 20:56:14 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: ndproxy and SEND To: Christian Huitema Cc: Fred Templin , James Kempf , Erik Nordmark , Dave Thaler , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > ND proxy is the equivalent of ARP spoofing. > SEND is the antidote to ARP spoofing. > Why should we be surprised that they are not compatible? Agreed. Question is what we should do about it. Having two conflicting things move forward towards the standards track doesn't seem like the best solution. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 00:08:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01648 for ; Wed, 3 Mar 2004 00:08:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOc9-0003zI-D6 for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 00:08:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2358CPm015318 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 00:08:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOc6-0003yl-S7 for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 00:08:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01550 for ; Wed, 3 Mar 2004 00:08:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOc4-0002Vb-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:08:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyOb5-0002Kw-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:07:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyOaC-0002Bj-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:06:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOa3-0003HG-9s; Wed, 03 Mar 2004 00:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOZG-0003Ep-Ef for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 00:05:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01376 for ; Wed, 3 Mar 2004 00:05:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOZE-00022e-00 for ipv6@ietf.org; Wed, 03 Mar 2004 00:05:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyOYK-0001tU-00 for ipv6@ietf.org; Wed, 03 Mar 2004 00:04:16 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AyOXc-0001kl-00 for ipv6@ietf.org; Wed, 03 Mar 2004 00:03:32 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 4F18A6A902; Wed, 3 Mar 2004 07:03:30 +0200 (EET) Message-ID: <4045669A.6040600@kolumbus.fi> Date: Wed, 03 Mar 2004 07:01:14 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf , Dave Thaler Cc: Christian Huitema , Erik Nordmark , ipv6@ietf.org Subject: Re: ndproxy and SEND References: <4d6201c400c9$1a308370$3e6015ac@dclkempt40> In-Reply-To: <4d6201c400c9$1a308370$3e6015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In general, I think proxy SEND is doable, and doesn't even need any new trust roots or anything. Its a question of delegating the right to do advertisements for someone else. The protocol details are left as an exercise for the reader ;-). However, I can see different use cases and we can use the secure version only in some cases. For instance, you could be proxying ND because you are a home agent and defending a mobile node's home address on its behalf. Or you could be proxying ND because of some link layer bridging scheme. Now, for the delegation that I mentioned above to work, there has to be some kind of (security) relationship between the real node and the proxy. There would be such a relationship in the case of Mobile IP, for instance. But it isn't clear that you would always have it in the bridging case -- typically there's no security association with the bridge! But you might be able to do this securely if you had layer 2 security from the node to the bridge. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 00:58:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04151 for ; Wed, 3 Mar 2004 00:58:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPOC-0002dk-1P for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 00:57:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i235vqUh010142 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 00:57:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPOB-0002dV-RS for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 00:57:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04016 for ; Wed, 3 Mar 2004 00:57:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyPO9-0002Io-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:57:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyPLi-0001ij-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:55:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyPKW-0001RE-04 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:54:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyPH0-0003L2-JK for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:50:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPGf-0001PC-Fl; Wed, 03 Mar 2004 00:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPFj-0001KP-Nk for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 00:49:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03659 for ; Wed, 3 Mar 2004 00:49:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyPFh-0000rK-00 for ipv6@ietf.org; Wed, 03 Mar 2004 00:49:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyPEi-0000i2-00 for ipv6@ietf.org; Wed, 03 Mar 2004 00:48:04 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AyPDn-0000Z5-00 for ipv6@ietf.org; Wed, 03 Mar 2004 00:47:07 -0500 Message-ID: <4dd601c400e3$09b59d90$3e6015ac@dclkempt40> From: "James Kempf" To: "Erik Nordmark" , "Christian Huitema" Cc: "Fred Templin" , "Erik Nordmark" , "Dave Thaler" , References: Subject: Re: ndproxy and SEND Date: Tue, 2 Mar 2004 21:47:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > ND proxy is the equivalent of ARP spoofing. > > SEND is the antidote to ARP spoofing. > > Why should we be surprised that they are not compatible? > > Agreed. > > Question is what we should do about it. > Having two conflicting things move forward towards the standards track > doesn't seem like the best solution. > So following up on Jari's note, I think it depends on what the ND-Proxy draft is intended for. If it is intended primarily for link layer boxes, then there isn't much one can do about securing it outside of specifying that it should only be used on secure link layers. In that case, it seems like putting such a statement in the Security Considerations section might be a possibility. On the other hand, if ND-Proxy is intended for IP layer entities such as a Mobile IP home agent, then we could continue working on ND proxy security in SEND, or it could be taken up specifically by the IPv6 WG. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 00:58:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04226 for ; Wed, 3 Mar 2004 00:58:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPOV-0002r3-CB for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 00:58:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i235wBuI010967 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 00:58:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPOV-0002qo-6q for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 00:58:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04082 for ; Wed, 3 Mar 2004 00:58:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyPOS-0002OO-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:58:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyPMA-0001nT-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:55:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyPKc-0001RE-05 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:54:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyPCP-00038W-Ld for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 00:45:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPBn-0000cA-Pb; Wed, 03 Mar 2004 00:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPAs-0000YT-6h for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 00:44:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03481 for ; Wed, 3 Mar 2004 00:44:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyPAp-0000C3-00 for ipv6@ietf.org; Wed, 03 Mar 2004 00:44:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyP9v-00004s-00 for ipv6@ietf.org; Wed, 03 Mar 2004 00:43:07 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AyP9C-0007c5-00 for ipv6@ietf.org; Wed, 03 Mar 2004 00:42:22 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i235frL08253 for ; Tue, 2 Mar 2004 21:41:53 -0800 Received: from innovationslab.net (WXP-LAPBRIANH.wireless.ietf59.or.kr [218.37.227.145]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i235s8QP032400 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 2 Mar 2004 21:54:13 -0800 Message-ID: <40457017.1000007@innovationslab.net> Date: Wed, 03 Mar 2004 00:41:43 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IETF 59 IPv6 WG Document Status References: <4043D345.5050800@innovationslab.net> In-Reply-To: <4043D345.5050800@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, I have updated the Document status webpage based on comments received. http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 05:52:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17963 for ; Wed, 3 Mar 2004 05:52:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTyu-0003QY-4N for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 05:52:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23Aq48u013167 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 05:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTyU-0003Nt-67 for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 05:52:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17840 for ; Wed, 3 Mar 2004 05:51:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTyB-00066f-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 05:51:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTxG-0005v5-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 05:50:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyTwI-0005kW-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 05:49:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTv0-0002fw-Dh; Wed, 03 Mar 2004 05:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTts-0002Vp-F6 for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 05:47:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17631 for ; Wed, 3 Mar 2004 05:46:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTtP-0005JO-00 for ipv6@ietf.org; Wed, 03 Mar 2004 05:46:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTsY-0005Ag-00 for ipv6@ietf.org; Wed, 03 Mar 2004 05:45:30 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AyTrt-0004z5-00 for ipv6@ietf.org; Wed, 03 Mar 2004 05:44:49 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i23Ai7dO023982; Wed, 3 Mar 2004 02:44:07 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i23Ai4Q21626; Wed, 3 Mar 2004 11:44:04 +0100 (MET) Date: Tue, 2 Mar 2004 20:36:23 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Adopt Address Selection API as a WG document? To: Brian E Carpenter Cc: Francis Dupont , Brian Haberman , ipv6@ietf.org In-Reply-To: "Your message with ID" <40449E46.D41272C@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_06_12 autolearn=no version=2.60 > As we are seeing in the multi-addressing discussions in multi6, > there is indeed strong pressure from applications people against > apps having to know anything at all about address selection. > This becomes even more true when you get into Java land. > > So while this API is probably harmless, I agree with Francis > its applicability is very limited. In fact, I would be tempted to > argue for it becoming Experimental. However, I think it is perfectly > valid for it to become a WG draft. The draft in question doesn't look at multiple addresses of the same type/properties, such as multiple prefixes in the case of multihoming. The draft is about being able to choose between things like temporary and public addresses, which is something which users/applications might care about. And this is orthogonal to the multihoming aspects. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 07:35:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22361 for ; Wed, 3 Mar 2004 07:35:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVaR-0006s1-5a for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 07:34:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23CYtLS026408 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 07:34:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVaM-0006rX-0G for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 07:34:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22260 for ; Wed, 3 Mar 2004 07:34:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVa6-0007TH-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 07:34:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVZ9-0007Dv-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 07:33:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyVY9-0006zO-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 07:32:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVXd-0005s8-LM; Wed, 03 Mar 2004 07:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVXU-0005nj-NB for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 07:31:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21969 for ; Wed, 3 Mar 2004 07:31:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVX9-0006mE-00 for ipv6@ietf.org; Wed, 03 Mar 2004 07:31:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVWH-0006bq-00 for ipv6@ietf.org; Wed, 03 Mar 2004 07:30:37 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AyVVV-0006N1-00 for ipv6@ietf.org; Wed, 03 Mar 2004 07:29:49 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i23CTJ9u004051 for ; Wed, 3 Mar 2004 04:29:19 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 04:29:19 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C69B@MONTEREY.netscreen.com> From: Changming Liu To: "''ipv6@ietf.org' '" Subject: RE: v6 host load balancing Date: Wed, 3 Mar 2004 04:29:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Dave, As we talked this moning about this issue, we thought that it might be a good idea to discuss this in the mailing list so that others can express their opinion too. As one of the top 3 firewall/NAT/IDP vendors, our experience with load sharing is very bad. It's only good for router-switch only environment. For security gateways with any one of the functionalities as I mentioned above, it will create some poblem here or there. This is because it needs to see some consecutive packets, if not all, packets in the same flow (some applications need to see it in both directions) in order to do the correct ALG for NAT, deep packet inspection for idp, network based Anti-Virus, which we also start to do. I completely agree with your statement that "packet based randomized LS" is bad. For flow based LS, we need to be vey careful about the definition of "the flow". Some applications have different channels, such as control/signalling and data, like FTP, VOIP (H323 or SIP), packets belong to all these channels are better to belong to the same firewall, or some of the above functionality may break because it needs to deal with dynamic ports in either forward or backward directions. The problem we have with the draft is the "MUST NOT" sent to the same router statement. At very minimum, it should be "SHOULD" to just leave an option for the host to turn it off if it deems necessary. Thanks for the chat on this topic this morning. Changming Liu Netsceen Technologies Inc. -----Original Message--- From: Gregory M Lebovitz To: dthaler@microsoft.com Cc: Changming Liu Sent: 3/2/2004 9:32 PM Subject: v6 host load balancing Dave, Was sitting in the v6 mtg yesterday, and quickly reviewed your doc on LB. I see some use cases, particularly involving state-keeping gateways, like FW and IPS devices, for which this is going to cause tremendous havoc. Could my co-worker, changming and I get together with you for a bit and discuss to see if we are accurate in our assessment? perhaps as the pm break today (at ietf reg desk) or for bfast tomorrow? Pls advise, Gregory. +++++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Architect - CTO Office NetScreen Technologies -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 07:45:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23178 for ; Wed, 3 Mar 2004 07:45:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVkB-0008GH-MK for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 07:44:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23Cix0c031751 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 07:44:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVk1-0008FM-Fd for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 07:44:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23152 for ; Wed, 3 Mar 2004 07:44:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVjl-0001Xo-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 07:44:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyViv-0001Ot-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 07:43:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyViP-0001FR-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 07:43:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyViH-0007tL-IT; Wed, 03 Mar 2004 07:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVi3-0007sS-3Z for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 07:42:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23036 for ; Wed, 3 Mar 2004 07:42:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVhi-0001D3-00 for ipv6@ietf.org; Wed, 03 Mar 2004 07:42:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVgm-000139-00 for ipv6@ietf.org; Wed, 03 Mar 2004 07:41:29 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVfx-0000ja-00 for ipv6@ietf.org; Wed, 03 Mar 2004 07:40:38 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i23Ce3D16271; Wed, 3 Mar 2004 14:40:03 +0200 Date: Wed, 3 Mar 2004 14:40:03 +0200 (EET) From: Pekka Savola To: Changming Liu cc: "''ipv6@ietf.org' '" Subject: RE: v6 host load balancing In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C69B@MONTEREY.netscreen.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 3 Mar 2004, Changming Liu wrote: > As one of the top 3 firewall/NAT/IDP vendors, our experience with load > sharing is very bad. For what it's worth, I've also argued stronlgy host against load balancing. I'm copying the major concern below. ================== Date: Sun, 29 Feb 2004 07:44:38 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org Subject: draft-ietf-ipv6-host-load-sharing-01 comments [...] Fundamental objection --------------------- The document assumes that it is always desirable to do load-sharing with the equivalent routers. I don't agree with this assumption. If the router's capacity is sufficient so that it can forward all the traffic sent by its nodes, there is actually very little need for load sharing. On the contrary -- sharing load between routers produces difficult-to-debug scenarios when some destinations (which are distributed to some routers) fail in mysterious ways while others work just fine. Due to that, I, as an operator, would not wish to enable load-sharing on hosts except when I specifically require that kind of functionality. So, I'd propose that this document does not describe that the hosts MUST share the load, but rather describes how the hosts MUST behave if they wish to share the load -- and if turned on by default, require that there MUST be a way to toggle load balancing off. A difficult issue to settle might be whether to recommend (and if so, how strongly) to enable load-sharing by default. ======================= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 08:37:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26195 for ; Wed, 3 Mar 2004 08:37:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWYZ-0004gb-0c for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 08:37:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23Db27N018007 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 08:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWYT-0004fj-Q9 for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 08:37:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26153 for ; Wed, 3 Mar 2004 08:36:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWYD-0003D6-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 08:36:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWXI-00032a-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 08:35:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyWWU-0002s1-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 08:34:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWVd-00049M-Sv; Wed, 03 Mar 2004 08:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWVP-00048q-2X for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 08:33:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26022 for ; Wed, 3 Mar 2004 08:33:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWV3-0002gK-00 for ipv6@ietf.org; Wed, 03 Mar 2004 08:33:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWUD-0002YP-00 for ipv6@ietf.org; Wed, 03 Mar 2004 08:32:34 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWTZ-0002QK-00 for ipv6@ietf.org; Wed, 03 Mar 2004 08:31:53 -0500 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i23DVqOr025755 for ; Wed, 3 Mar 2004 13:31:52 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA23277 for ; Wed, 3 Mar 2004 13:31:49 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i23DVnl14781 for ipv6@ietf.org; Wed, 3 Mar 2004 13:31:49 GMT Date: Wed, 3 Mar 2004 13:31:49 +0000 From: Tim Chown To: "''ipv6@ietf.org' '" Subject: Re: v6 host load balancing Message-ID: <20040303133149.GB13944@login.ecs.soton.ac.uk> Mail-Followup-To: "''ipv6@ietf.org' '" References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C69B@MONTEREY.netscreen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I agree completely with Pekka. Tim On Wed, Mar 03, 2004 at 02:40:03PM +0200, Pekka Savola wrote: > On Wed, 3 Mar 2004, Changming Liu wrote: > > As one of the top 3 firewall/NAT/IDP vendors, our experience with load > > sharing is very bad. > > For what it's worth, I've also argued stronlgy host against load > balancing. I'm copying the major concern below. > > ================== > Date: Sun, 29 Feb 2004 07:44:38 +0200 (EET) > From: Pekka Savola > To: ipv6@ietf.org > Subject: draft-ietf-ipv6-host-load-sharing-01 comments > > [...] > Fundamental objection > --------------------- > > The document assumes that it is always desirable to do > load-sharing with the equivalent routers. I don't agree with this > assumption. > > If the router's capacity is sufficient so that it can forward all the > traffic sent by its nodes, there is actually very little need for load > sharing. On the contrary -- sharing load between routers produces > difficult-to-debug scenarios when some destinations (which are distributed > to some routers) fail in mysterious ways while others work just fine. > > Due to that, I, as an operator, would not wish to enable load-sharing on > hosts except when I specifically require that kind of functionality. > > So, I'd propose that this document does not describe that the hosts MUST > share the load, but rather describes how the hosts MUST behave if they wish > to share the load -- and if turned on by default, require that there > MUST be a way to toggle load balancing off. A difficult issue to settle > might be whether to recommend (and if so, how strongly) to enable > load-sharing by default. > > ======================= > > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Wed Mar 3 12:09:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10655 for ; Wed, 3 Mar 2004 12:09:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZrH-0005md-Pp for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 12:08:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23H8ZDE022073 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 12:08:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZrH-0005jw-AZ for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 12:08:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10551 for ; Wed, 3 Mar 2004 12:08:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyZrG-00067T-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 12:08:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyZqG-0005uK-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 12:07:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyZpH-0005h3-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 12:06:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZoo-0004wH-26; Wed, 03 Mar 2004 12:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXZW-0005Hi-3l for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 09:42:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00651 for ; Wed, 3 Mar 2004 09:42:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyXZR-0000OT-00 for ipv6@ietf.org; Wed, 03 Mar 2004 09:42:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyXWi-0007eD-00 for ipv6@ietf.org; Wed, 03 Mar 2004 09:39:13 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AyXVG-0007M0-00 for ipv6@ietf.org; Wed, 03 Mar 2004 09:37:42 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id i23EbX57055610 for ; Wed, 3 Mar 2004 09:37:41 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: Subject: FW: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Date: Wed, 3 Mar 2004 09:37:41 -0500 Message-ID: <000b01c4012d$181a7640$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jinmei requested I send this to the IPv6 mailing list. -----Original Message----- From: Bernie Volz [mailto:volz@metrocast.net]=20 Sent: Tuesday, March 02, 2004 6:06 PM To: 'JINMEI Tatuya / =90_-=BE'B=8D=C6'; 'vijayak@india.hp.com' Cc: 'dhcwg@ietf.org' Subject: RE: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Regarding Jinmei's msg01798: - I agree that DHCPv6 should be the stateful protocol (question c). - I don't agree that DHCPv6light should not be controlled by the 'O' = flag in a RA (question d). Personally, I think it a good thing for hosts to be silent on any = protocol unless explicitly configured to run it. So, avoiding periodic Information-Request messages on all IPv6 networks, especially simple networks, is IMHO a good thing. Also, from RFC 2462, we have: "In addition, when the value of the ManagedFlag is TRUE, the value of OtherConfigFlag is implicitely TRUE as well." This would seem to me to very closely tie the "M" (Managed) and = "O" (Other) configuration protocols - if they are completely separate, why connect them at all? - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Bernie Volz Sent: Tuesday, March 02, 2004 4:30 PM To: 'JINMEI Tatuya / =90_-=BE'B=8D=C6'; vijayak@india.hp.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 FYI - For those that don't want to spend the 5 to 10 minutes I did = looking for Jinmei's email, I think he was referring to: http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01798.ht= ml - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = JINMEI Tatuya / =90_=96=BE=92B=8D=C6 Sent: Monday, March 01, 2004 11:40 AM To: vijayak@india.hp.com Cc: dhcwg@ietf.org Subject: [dhcwg] comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00 Probably too late for the wg meeting, but I have several comments on draft-vijay-dhc-dhcpv6-mcast-reconf-00. General comments: As an initial impression, I support (the idea of) this document. However, I think some fundamental points need to be discussed. - the document (and the ipv6-icmp-refresh-otherconf draft) assumes that the "O" flag in RA is tightly related to DHCPv6Light. However, this is not clear in the ongoing rfc2462bis work. And, actually, I just proposed at the ipv6 ML that we should rather separate the O flag from DHCPv6Light (the reasons were explained there). - this draft tries to reuse the existing framework, but it seems to me that the attempt causes some inconsistencies. The previous bullet is one of them. The other one is pointed out below at comment item 3. - having considered above point and the current deployment status of DHCPv6 and DHCPv6Light, it might make much more sense to design the mechanism as an explicit extension, rather than to stick to the compatibility with the existing specification and implementation. Technical (non editorial) comments: 1. In Section 4, Even if the Relay doesn't reside in the default router of the link, it should be capable of sending RAs without advertising itself as a default router. =3D> this might cause inconsistency on the content of RAs between that from "real" routers and that from the Relay, which will then cause warnings at routers (and probably at the Relay also) according to Section 6.2.7 of RFC2461. 2. In Section 7.1, - the peer-address doesn't match any of the IPv6 prefixes configured in any of the relay's interfaces and the Interface-id option is not sent. =3D> should the "peer-address" actually be "link-address"? 3. In Section 7.1, The match is done based on longest prefix match. =3D> this matching rule is not always trustworthy, since the relay may have multiple link prefixes with different prefix lengths, like P::/64 and P::/72. What if the server actually wants to specify the former (and it does not know the corresponding interface ID)? Editorial comments: 4. In Section 1, of the of the client, including the address by which the client can =3D> s/of the of the/of the 5. In Section 4, ... administrative domain to have the security association with them for IPv6Sec. =3D> I don't think "IPv6Sec" is not a very appropriate term. IPsec would simply be enough in this case. 6. In Section 5, If the nodes find the O flag in the RA changes form FALSE to TRUE, =3D> s/form/from/ 7. In Section 6.1, peer-address: It should be filled with 0, as this message is not really destined to any client. =3D> I think "filled with 0" can (or even should) simply be "the unspecified address". 8. In Section 6.2, The server continues this process until REC_MAX_RC unsuccessful attempts have been made, =3D> this seems an incomplete sentence. s/,/./ ? 9. In Section 7.2, The relay MUST trigger the router to include the Redo Service Discovery Option in the RAs. =3D> What's the "Redo Service Discovery Option"? Shouldn't this be the "Refresh Other Configuration Option"? 10. In Section 7.3, The Relay prepares an DHCP Reply message with transaction-id copied =3D> s/an/a/ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 12:23:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11708 for ; Wed, 3 Mar 2004 12:23:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aya5D-0007OB-9c for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 12:22:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23HMxSf028397 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 12:22:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aya5D-0007Nw-4L for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 12:22:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11696 for ; Wed, 3 Mar 2004 12:22:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aya5B-00012t-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 12:22:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aya4P-0000rF-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 12:22:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aya3a-0000eh-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 12:21:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aya3M-000732-Qu; Wed, 03 Mar 2004 12:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aya2z-00071J-8K for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 12:20:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11503 for ; Wed, 3 Mar 2004 12:20:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aya2x-0000Zm-00 for ipv6@ietf.org; Wed, 03 Mar 2004 12:20:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aya24-0000Oq-00 for ipv6@ietf.org; Wed, 03 Mar 2004 12:19:45 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aya1J-0000Cx-00 for ipv6@ietf.org; Wed, 03 Mar 2004 12:18:58 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8B65E1521B for ; Thu, 4 Mar 2004 02:18:50 +0900 (JST) Date: Thu, 04 Mar 2004 02:19:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis] M/O flags and DHCPv6 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 In the wg meeting on Tuesday, several concerns were raised regarding this issue (and the proposed resolution). To summarize (some of) them, 1. the resolution proposes to say "the stateful protocol is DHCPv6" clearly, without leaving other possibilities. This would require RFC3315 (DHCPv6) to be listed as a normative reference. However, we'll then face a reference dependency issue, since rfc2462bis is soon expected to be recycled as a DS while RFC3315 is still a PS. (BTW: I could not find a direct source of this dependency issue. Could someone give me a pointer?) 2. also, listing RFC3315 as a normative reference may be unreasonable for implementors since it would force them to read RFC3315, which is a quite large document, whereas we are going to make implementing the stateful protocol optional (at least in some sense). I don't know if this concern is widely shared by wg members, though. The easiest solution to them would be to list RFC3315 as an informative reference. I don't know whether this is acceptable. According to Section 2.7 of draft-rfc-editor-rfc2223bis-07.txt, Normative references specify - documents that must be read to understand or implement the technology in the new RFC - documents whose technology must be present for the technology in the new RFC to work But the first condition seems to me a bit subjective. Under which requirement can we decide a document must be read for a different document? The second condition is a bit clearer, but assuming we basically agreed that implementing DHCPv6 is basically optional, isn't "must be present" too strong? And if so, can't we still safely use this RFC as an informative reference? Note: I'm not necessarily pushing the easy solution. I'm just not sure about the base of the discussion, and want to be sure about it. Any clarifications are welcome. 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 exim@www1.ietf.org Wed Mar 3 21:01:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15220 for ; Wed, 3 Mar 2004 21:01:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiAo-0002Pq-Ga for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 21:01:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2421I2G009280 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 21:01:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiAo-0002Pb-AC for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:01:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15070 for ; Wed, 3 Mar 2004 21:01:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiAl-0004y4-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:01:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayi92-0004Ri-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 20:59:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayi7n-0004DV-01 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 20:58:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayi22-0003hu-98 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 20:52:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayi1p-0001A0-JW; Wed, 03 Mar 2004 20:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayi0r-00010I-Vz for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 20:51:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14236 for ; Wed, 3 Mar 2004 20:50:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayi0p-0002my-00 for ipv6@ietf.org; Wed, 03 Mar 2004 20:50:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayhzu-0002dd-00 for ipv6@ietf.org; Wed, 03 Mar 2004 20:50:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AyhzP-0002Tc-00 for ipv6@ietf.org; Wed, 03 Mar 2004 20:49:32 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i241mqZ28353; Wed, 3 Mar 2004 17:48:52 -0800 X-mProtect: <200403040148> Nokia Silicon Valley Messaging Protection Received: from spruce.wireless.ietf59.or.kr (218.37.229.60, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdBL0e2m; Wed, 03 Mar 2004 17:48:49 PST Message-Id: <4.3.2.7.2.20040303173854.023023e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 03 Mar 2004 17:48:29 -0800 To: Changming Liu From: Bob Hinden Subject: RE: v6 host load balancing Cc: ipv6@ietf.org In-Reply-To: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C69B@MONTEREY.netscree n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Changming, >As we talked this moning about this issue, we thought that it might be a >good idea to discuss this in the mailing list so that others can express >their opinion too. > >As one of the top 3 firewall/NAT/IDP vendors, our experience with load >sharing is very bad. It's only good for router-switch only environment. >For security gateways with any one of the functionalities as I mentioned >above, it will create some poblem here or there. This is because it >needs to see some consecutive packets, if not all, packets in the same >flow (some applications need to see it in both directions) in order to >do the correct ALG for NAT, deep packet inspection for idp, network >based Anti-Virus, which we also start to do. I completely agree with >your statement that "packet based randomized LS" is bad. For flow based >LS, we need to be vey careful about the definition of "the flow". Some >applications have different channels, such as control/signalling and >data, like FTP, VOIP (H323 or SIP), packets belong to all these channels >are better to belong to the same firewall, or some of the above >functionality may break because it needs to deal with dynamic ports in >either forward or backward directions. I would agree with your concern if it worked that way. The load balancing being proposed is not load balancing on a per packet basis. It is load sharing when the host is about to pick a router when sending to a new destination. Please reread this part of the neighbor discovery specification where it describes the conceptional algorithm for selecting a router. All of the traffic from a host to the same destination will be sent to the same router. Traffic to a different destination will be sent to a different router. Firewalls and similar devices will not have any problem seeing flows. Regards, Bob >The problem we have with the draft is the "MUST NOT" sent to the same >router statement. At very minimum, it should be "SHOULD" to just leave >an option for the host to turn it off if it deems necessary. > >Thanks for the chat on this topic this morning. > >Changming Liu >Netsceen Technologies Inc. > >-----Original Message--- >From: Gregory M Lebovitz >To: dthaler@microsoft.com >Cc: Changming Liu >Sent: 3/2/2004 9:32 PM >Subject: v6 host load balancing > >Dave, >Was sitting in the v6 mtg yesterday, and quickly reviewed your doc on >LB. I >see some use cases, particularly involving state-keeping gateways, like >FW >and IPS devices, for which this is going to cause tremendous havoc. >Could >my co-worker, changming and I get together with you for a bit and >discuss >to see if we are accurate in our assessment? > >perhaps as the pm break today (at ietf reg desk) or for bfast tomorrow? > >Pls advise, >Gregory. > >+++++++++++++++++++++++++ >IETF-related email from >Gregory M. Lebovitz >Architect - CTO Office >NetScreen Technologies > >-------------------------------------------------------------------- >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 exim@www1.ietf.org Wed Mar 3 21:01:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15252 for ; Wed, 3 Mar 2004 21:01:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiAr-0002QI-QZ for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 21:01:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2421LWV009308 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 21:01:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiAr-0002Q3-M1 for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:01:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15096 for ; Wed, 3 Mar 2004 21:01:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiAp-0004ys-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:01:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayi98-0004Sk-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 20:59:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayi7o-0004Dl-01 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 20:58:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayi0q-0003gl-Tx for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 20:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhzw-0000o7-2j; Wed, 03 Mar 2004 20:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhzp-0000nS-7e for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 20:49:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14177 for ; Wed, 3 Mar 2004 20:49:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayhzm-0002cI-00 for ipv6@ietf.org; Wed, 03 Mar 2004 20:49:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayhyn-0002Se-00 for ipv6@ietf.org; Wed, 03 Mar 2004 20:48:54 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1Ayhxq-0002A0-00 for ipv6@ietf.org; Wed, 03 Mar 2004 20:47:54 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 17:47:13 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Mar 2004 17:47:22 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 17:47:21 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 17:48:27 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 3 Mar 2004 17:48:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [rfc2462bis] M/O flags and DHCPv6 Date: Wed, 3 Mar 2004 17:47:17 -0800 Message-ID: Thread-Topic: [rfc2462bis] M/O flags and DHCPv6 thread-index: AcQBQ/mFf3fOJK+4TdSgKAsWG3k46QARa/BQ From: "Dave Thaler" To: =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= , X-OriginalArrivalTime: 04 Mar 2004 01:48:24.0765 (UTC) FILETIME=[C81C9ED0:01C4018A] Content-Transfer-Encoding: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpKSU5NRUkgVGF0dXlhIHdyaXRlczoNClsuLi5dDQo+IFRoZSBlYXNpZXN0IHNvbHV0aW9uIHRv IHRoZW0gd291bGQgYmUgdG8gbGlzdCBSRkMzMzE1IGFzIGFuDQo+IGluZm9ybWF0aXZlIHJlZmVy ZW5jZS4gIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoaXMgaXMgYWNjZXB0YWJsZS4NCj4gQWNjb3Jk aW5nIHRvIFNlY3Rpb24gMi43IG9mIGRyYWZ0LXJmYy1lZGl0b3ItcmZjMjIyM2Jpcy0wNy50eHQs DQo+IE5vcm1hdGl2ZSByZWZlcmVuY2VzIHNwZWNpZnkNCj4gDQo+ICAgLSBkb2N1bWVudHMgdGhh dCBtdXN0IGJlIHJlYWQgdG8gdW5kZXJzdGFuZCBvciBpbXBsZW1lbnQgdGhlDQo+ICAgICB0ZWNo bm9sb2d5IGluIHRoZSBuZXcgUkZDDQo+ICAgLSBkb2N1bWVudHMgd2hvc2UgdGVjaG5vbG9neSBt dXN0IGJlIHByZXNlbnQgZm9yIHRoZSB0ZWNobm9sb2d5DQo+ICAgICBpbiB0aGUgbmV3IFJGQyB0 byB3b3JrDQo+IA0KPiBCdXQgdGhlIGZpcnN0IGNvbmRpdGlvbiBzZWVtcyB0byBtZSBhIGJpdCBz dWJqZWN0aXZlLiAgVW5kZXIgd2hpY2gNCj4gcmVxdWlyZW1lbnQgY2FuIHdlIGRlY2lkZSBhIGRv Y3VtZW50IG11c3QgYmUgcmVhZCBmb3IgYSBkaWZmZXJlbnQNCj4gZG9jdW1lbnQ/DQo+IA0KPiBU aGUgc2Vjb25kIGNvbmRpdGlvbiBpcyBhIGJpdCBjbGVhcmVyLCBidXQgYXNzdW1pbmcgd2UgYmFz aWNhbGx5DQo+IGFncmVlZCB0aGF0IGltcGxlbWVudGluZyBESENQdjYgaXMgYmFzaWNhbGx5IG9w dGlvbmFsLCBpc24ndCAibXVzdCBiZQ0KPiBwcmVzZW50IiB0b28gc3Ryb25nPyAgQW5kIGlmIHNv LCBjYW4ndCB3ZSBzdGlsbCBzYWZlbHkgdXNlIHRoaXMgUkZDIGFzDQo+IGFuIGluZm9ybWF0aXZl IHJlZmVyZW5jZT8NClsuLi5dDQoNCkkgc3VzcGVjdCBub3QuICBNeSBzdWdnZXN0aW9uIGluIHRo ZSBXRyBtZWV0aW5nIHdhcyB0byBub3QgcmVmZXJlbmNlIERIQ1B2Ng0KaGVyZSwgYnV0IGluc3Rl YWQgbGVhdmUgaXQgdG8gdGhlIG5vZGUgcmVxdWlyZW1lbnRzIGRvYyB0byBzYXkgdGhhdCBESENQ djYNCmlzIHRoZSBzdGF0ZWZ1bCBwcm90b2NvbC4NCg0KLURhdmUNCg== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 21:26:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17396 for ; Wed, 3 Mar 2004 21:26:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiZ1-0006UR-31 for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 21:26:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242QIwO024940 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 21:26:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiYw-0006Tz-FQ for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:26:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17359 for ; Wed, 3 Mar 2004 21:26:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiYt-0002Lc-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:26:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiXy-00027q-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:25:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyiWn-0001mH-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiVq-0005bD-4j; Wed, 03 Mar 2004 21:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiUv-0005UM-Cb for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 21:22:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16907 for ; Wed, 3 Mar 2004 21:22:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiUs-0001NV-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:22:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiU2-0001BJ-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:21:10 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiTG-0000qC-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:20:22 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i242Jmb29510; Thu, 4 Mar 2004 04:19:48 +0200 Date: Thu, 4 Mar 2004 04:19:48 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipv6@ietf.org Subject: Re: [rfc2462bis] M/O flags and DHCPv6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 4 Mar 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: [...] > The easiest solution to them would be to list RFC3315 as an > informative reference. I don't know whether this is acceptable. > According to Section 2.7 of draft-rfc-editor-rfc2223bis-07.txt, > Normative references specify > > - documents that must be read to understand or implement the > technology in the new RFC > - documents whose technology must be present for the technology > in the new RFC to work > > But the first condition seems to me a bit subjective. Under which > requirement can we decide a document must be read for a different > document? I don't think this is a problem. You don't have to understand DHCPv6 to ignore M/O bits -- which you only act upon IF you have implemented DHCPv6 -- and then you understand it already :). IMHO, putting the reference as Informative seems just fine. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 21:29:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17652 for ; Wed, 3 Mar 2004 21:29:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayibt-00079A-TU for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 21:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242TH82027466 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 21:29:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayibt-00078v-P5 for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:29:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17606 for ; Wed, 3 Mar 2004 21:29:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayibr-00031d-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:29:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayiav-0002o7-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:28:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayia1-0002bH-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:27:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiZi-0006dm-7G; Wed, 03 Mar 2004 21:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiYm-0006Jf-Ib for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 21:26:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17341 for ; Wed, 3 Mar 2004 21:26:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiYj-0002KU-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:26:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiXj-00026P-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:25:00 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AyiWe-0001hZ-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:23:52 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0A8D81521B; Thu, 4 Mar 2004 11:23:46 +0900 (JST) Date: Thu, 04 Mar 2004 11:23:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Dave Thaler" Cc: Subject: Re: [rfc2462bis] M/O flags and DHCPv6 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Wed, 3 Mar 2004 17:47:17 -0800, >>>>> "Dave Thaler" said: >> But the first condition seems to me a bit subjective. Under which >> requirement can we decide a document must be read for a different >> document? >> >> The second condition is a bit clearer, but assuming we basically >> agreed that implementing DHCPv6 is basically optional, isn't "must be >> present" too strong? And if so, can't we still safely use this RFC as >> an informative reference? > [...] > I suspect not. My suggestion in the WG meeting was to not reference DHCPv6 > here, but instead leave it to the node requirements doc to say that DHCPv6 > is the stateful protocol. I'm personally happy with this approach. But then rfc2462bis will need to refer to the node requirements draft, and we'll face similar questions: - should the reference to the node-req doc be informative or normative? - if normative, are there any reference dependency issues? - (additional question) should we then still refer to RFC3315 (probably as an informative one in this case) 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 exim@www1.ietf.org Wed Mar 3 21:31:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17847 for ; Wed, 3 Mar 2004 21:31:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayie1-0007gM-5i for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 21:31:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242VTNS029524 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 21:31:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayie0-0007g7-TF for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:31:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17774 for ; Wed, 3 Mar 2004 21:31:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayidy-0003WW-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:31:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayicx-0003H8-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:30:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayibu-00032I-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:29:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayibe-000700-Sg; Wed, 03 Mar 2004 21:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayiap-0006x1-Pl for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 21:28:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17505 for ; Wed, 3 Mar 2004 21:28:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayian-0002mk-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:28:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiZq-0002Zb-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:27:11 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AyiYx-0002BK-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:26:16 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 18:26:07 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 3 Mar 2004 18:25:44 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Mar 2004 18:25:46 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 18:25:43 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 18:26:36 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 3 Mar 2004 18:26:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [rfc2462bis] M/O flags and DHCPv6 Date: Wed, 3 Mar 2004 18:25:35 -0800 Message-ID: Thread-Topic: [rfc2462bis] M/O flags and DHCPv6 thread-index: AcQBj8JI6ri7/IL5TBaZAK2D69TuzAAAB2IA From: "Dave Thaler" To: =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= Cc: X-OriginalArrivalTime: 04 Mar 2004 02:26:49.0754 (UTC) FILETIME=[25FE07A0:01C40190] Content-Transfer-Encoding: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpJTk1FSSBUYXR1eWEgLyDn pZ7mmI7pgZTlk4kgW21haWx0bzpqaW5tZWlAaXNsLnJkYy50b3NoaWJhLmNvLmpwXQ0KPiBTZW50 OiBUaHVyc2RheSwgTWFyY2ggMDQsIDIwMDQgMTE6MjQgQU0NCj4gVG86IERhdmUgVGhhbGVyDQo+ IENjOiBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbcmZjMjQ2MmJpc10gTS9PIGZsYWdz IGFuZCBESENQdjYNCj4gDQo+ID4+Pj4+IE9uIFdlZCwgMyBNYXIgMjAwNCAxNzo0NzoxNyAtMDgw MCwNCj4gPj4+Pj4gIkRhdmUgVGhhbGVyIiA8ZHRoYWxlckB3aW5kb3dzLm1pY3Jvc29mdC5jb20+ IHNhaWQ6DQo+IA0KPiA+PiBCdXQgdGhlIGZpcnN0IGNvbmRpdGlvbiBzZWVtcyB0byBtZSBhIGJp dCBzdWJqZWN0aXZlLiAgVW5kZXIgd2hpY2gNCj4gPj4gcmVxdWlyZW1lbnQgY2FuIHdlIGRlY2lk ZSBhIGRvY3VtZW50IG11c3QgYmUgcmVhZCBmb3IgYSBkaWZmZXJlbnQNCj4gPj4gZG9jdW1lbnQ/ DQo+ID4+DQo+ID4+IFRoZSBzZWNvbmQgY29uZGl0aW9uIGlzIGEgYml0IGNsZWFyZXIsIGJ1dCBh c3N1bWluZyB3ZSBiYXNpY2FsbHkNCj4gPj4gYWdyZWVkIHRoYXQgaW1wbGVtZW50aW5nIERIQ1B2 NiBpcyBiYXNpY2FsbHkgb3B0aW9uYWwsIGlzbid0ICJtdXN0IGJlDQo+ID4+IHByZXNlbnQiIHRv byBzdHJvbmc/ICBBbmQgaWYgc28sIGNhbid0IHdlIHN0aWxsIHNhZmVseSB1c2UgdGhpcyBSRkMg YXMNCj4gPj4gYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlPw0KPiA+IFsuLi5dDQo+IA0KPiA+IEkg c3VzcGVjdCBub3QuICBNeSBzdWdnZXN0aW9uIGluIHRoZSBXRyBtZWV0aW5nIHdhcyB0byBub3Qg cmVmZXJlbmNlDQo+IERIQ1B2Ng0KPiA+IGhlcmUsIGJ1dCBpbnN0ZWFkIGxlYXZlIGl0IHRvIHRo ZSBub2RlIHJlcXVpcmVtZW50cyBkb2MgdG8gc2F5IHRoYXQNCj4gREhDUHY2DQo+ID4gaXMgdGhl IHN0YXRlZnVsIHByb3RvY29sLg0KPiANCj4gSSdtIHBlcnNvbmFsbHkgaGFwcHkgd2l0aCB0aGlz IGFwcHJvYWNoLiAgQnV0IHRoZW4gcmZjMjQ2MmJpcyB3aWxsDQo+IG5lZWQgdG8gcmVmZXIgdG8g dGhlIG5vZGUgcmVxdWlyZW1lbnRzIGRyYWZ0LCBhbmQgd2UnbGwgZmFjZSBzaW1pbGFyDQo+IHF1 ZXN0aW9uczoNCg0KUGVyc29uYWxseSwgSSBkb24ndCB0aGluayB0aGVyZSdzIGFueSBuZWVkIHRv IHJlZmVyIHRvIHRoZSBub2RlLXJlcSBkb2MuDQpXZSBjb3VsZCBqdXN0IGtlZXAgdGhlIGxhbmd1 YWdlIGFzIGl0IHdhcyBiZWZvcmUuDQoNCi1EYXZlDQo= -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 21:33:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18082 for ; Wed, 3 Mar 2004 21:33:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayifl-00084F-OS for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 21:33:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242XH0B031005 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 21:33:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayifl-000840-JS for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:33:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17991 for ; Wed, 3 Mar 2004 21:33:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayifi-00042l-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:33:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayief-0003l5-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:32:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayidi-0003Tw-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayidb-0007Qq-KG; Wed, 03 Mar 2004 21:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayicr-0007PF-UW for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 21:30:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17706 for ; Wed, 3 Mar 2004 21:30:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayicp-0003Fi-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:30:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayibo-00031G-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:29:12 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayiat-0002cm-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:28:15 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i242PX729607; Thu, 4 Mar 2004 04:25:33 +0200 Date: Thu, 4 Mar 2004 04:25:33 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: Changming Liu , Subject: RE: v6 host load balancing In-Reply-To: <4.3.2.7.2.20040303173854.023023e0@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 3 Mar 2004, Bob Hinden wrote: > I would agree with your concern if it worked that way. The load balancing > being proposed is not load balancing on a per packet basis. It is load > sharing when the host is about to pick a router when sending to a new > destination. [...] Note that Changming was also raising an issue of "flows" (using intentionally vague terminology). Some classes of packets, which do not have the same destination address may belong together. For example SIP data and SIP signalling. Having them redistributed to other routers would be disadvantageous. The same also apply to (rather small) extent in certain cases where you check that an ICMP Destination Unreachable response is sent in response to a valid packet that the firewall has seen. This is hampered in a few corner cases at least. So, my point is that host-to-router load sharing works on the link, but is causing big problems further down in the network, e.g., in failure cases (some connections die and others don't: difficult to debug), firewalls, etc. -- without a good cause, if load sharing is not needed to well, share the load. -- 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 exim@www1.ietf.org Wed Mar 3 21:35:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18280 for ; Wed, 3 Mar 2004 21:35:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayiht-0000EF-32 for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 21:35:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242ZT49000873 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 21:35:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayihs-0000Dz-Tf for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:35:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18239 for ; Wed, 3 Mar 2004 21:35:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayihq-0004bn-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:35:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayigp-0004Kd-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:34:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayifo-00043k-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:33:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyifW-0007u6-Ks; Wed, 03 Mar 2004 21:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayieb-0007o3-70 for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 21:32:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17874 for ; Wed, 3 Mar 2004 21:32:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyieY-0003ju-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:32:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyidZ-0003SY-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:31:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Ayica-00033x-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:30:00 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i242SvT10367; Wed, 3 Mar 2004 18:28:57 -0800 X-mProtect: <200403040228> Nokia Silicon Valley Messaging Protection Received: from spruce.wireless.ietf59.or.kr (218.37.229.60, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdgxMnOF; Wed, 03 Mar 2004 18:28:54 PST Message-Id: <4.3.2.7.2.20040303174845.00b1e6d0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 03 Mar 2004 18:27:56 -0800 To: Pekka Savola From: Bob Hinden Subject: RE: v6 host load balancing Cc: Changming Liu , In-Reply-To: References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C69B@MONTEREY.netscreen.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Pekka, [No hats on, for this and the previous reply to Changming Liu] >The document assumes that it is always desirable to do >load-sharing with the equivalent routers. I don't agree with this >assumption. > >If the router's capacity is sufficient so that it can forward all the >traffic sent by its nodes, there is actually very little need for load >sharing. On the contrary -- sharing load between routers produces >difficult-to-debug scenarios when some destinations (which are distributed >to some routers) fail in mysterious ways while others work just fine. I have a different set of experience where customers provision two or more parallel router+firewalls and wish to divide the traffic between them. The specifically do not want the other routers to be unused. They have installed multiple routers so if one fails they want the others (using VRRP) to take over for the failure. They have found that unless all of the routers are used for live traffic that there is too high a probability that the other routers won't function correctly. >Due to that, I, as an operator, would not wish to enable load-sharing on >hosts except when I specifically require that kind of functionality. I believe that the "Default Router Preferences and More-Specific Routes" mechanisms provides the means to give the default routers different preferences. This will have the effect of keeping the load sharing from coming into play because the routers won't be seen as equivalent. This will give you the control I think you are asking for with out having some mechanism to change the default behavior in the hosts. >So, I'd propose that this document does not describe that the hosts MUST >share the load, but rather describes how the hosts MUST behave if they wish >to share the load -- and if turned on by default, require that there >MUST be a way to toggle load balancing off. A difficult issue to settle >might be whether to recommend (and if so, how strongly) to enable >load-sharing by default. I disagree about what should be the default. I think the default should be MUST, as I think it is useful in the general case. As pointed out above the "Default Router Preferences and More-Specific Routes" mechanisms provides a simple mechanisms to cause the hosts to not see the routers as equivalent if one so desires. Regards, Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 22:15:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20814 for ; Wed, 3 Mar 2004 22:15:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyjKY-0004Sc-Bh for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 22:15:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i243FQRo017140 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 22:15:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyjKY-0004SN-6c for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 22:15:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20723 for ; Wed, 3 Mar 2004 22:15:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyjKV-0004aA-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 22:15:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyjJ5-00045w-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 22:13:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyjHU-0003mj-02 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 22:12:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayivj-0004RF-Ok for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 21:49:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayiv0-00028Q-Mc; Wed, 03 Mar 2004 21:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayiu5-00027V-8X for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 21:48:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19517 for ; Wed, 3 Mar 2004 21:48:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayiu2-0007Qn-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:48:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayit4-0007Hz-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:47:03 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayisn-00078r-00 for ipv6@ietf.org; Wed, 03 Mar 2004 21:46:45 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i242kF9u029382; Wed, 3 Mar 2004 18:46:15 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 18:46:15 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6AD@MONTEREY.netscreen.com> From: Changming Liu To: "'Bob Hinden '" , Changming Liu Cc: "'ipv6@ietf.org '" Subject: RE: v6 host load balancing Date: Wed, 3 Mar 2004 18:46:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Bob, Thanks for pointing that out. Actually Dave already mentioned that to me during discussion. The destination address only based load balance will much better. As I also memtioned to him, that sometimes this approach still has a problem due to server load balances. For example, picture a network below: a FTP server farm protected a firewall, and a FTP client also behind its firewall and there are multiple firewalls in different locations to pretect the corporate of the client is in. If the client is doing destination load balance, it may use different corporate firewall as exit point for FTP data channels. This is because FTP server can tell its client to use different server for data channels. This still poses big challenge today. As I said, I am not completely oppose to load balance. It cab be very benificial . The problem is the "MUST NOT" keyword. At end of the day, the admin should have control whether or to use load balance to its network's benefit, pretty much like ECMP support on the today's router. ECMP by default is turn on in some vendor's routers. But it offers an option to do it differently (packet based or flow based, or whatever) or compeltely turn it off. Another question I have is why it has to be "MUST NOT". If it is because of security, it may be rational. If for performance, it is a little too much. As Pekka pointed out, who knows better than Admin about the network performance/bottleneck? Definitely, not protocol designers. Thanks of taking this into consideration. We just need to make a more thoughtful decision. Changming -----Original Message----- From: Bob Hinden To: Changming Liu Cc: ipv6@ietf.org Sent: 3/3/2004 5:48 PM Subject: RE: v6 host load balancing Changming, >As we talked this moning about this issue, we thought that it might be a >good idea to discuss this in the mailing list so that others can express >their opinion too. > >As one of the top 3 firewall/NAT/IDP vendors, our experience with load >sharing is very bad. It's only good for router-switch only environment. >For security gateways with any one of the functionalities as I mentioned >above, it will create some poblem here or there. This is because it >needs to see some consecutive packets, if not all, packets in the same >flow (some applications need to see it in both directions) in order to >do the correct ALG for NAT, deep packet inspection for idp, network >based Anti-Virus, which we also start to do. I completely agree with >your statement that "packet based randomized LS" is bad. For flow based >LS, we need to be vey careful about the definition of "the flow". Some >applications have different channels, such as control/signalling and >data, like FTP, VOIP (H323 or SIP), packets belong to all these channels >are better to belong to the same firewall, or some of the above >functionality may break because it needs to deal with dynamic ports in >either forward or backward directions. I would agree with your concern if it worked that way. The load balancing being proposed is not load balancing on a per packet basis. It is load sharing when the host is about to pick a router when sending to a new destination. Please reread this part of the neighbor discovery specification where it describes the conceptional algorithm for selecting a router. All of the traffic from a host to the same destination will be sent to the same router. Traffic to a different destination will be sent to a different router. Firewalls and similar devices will not have any problem seeing flows. Regards, Bob >The problem we have with the draft is the "MUST NOT" sent to the same >router statement. At very minimum, it should be "SHOULD" to just leave >an option for the host to turn it off if it deems necessary. > >Thanks for the chat on this topic this morning. > >Changming Liu >Netsceen Technologies Inc. > >-----Original Message--- >From: Gregory M Lebovitz >To: dthaler@microsoft.com >Cc: Changming Liu >Sent: 3/2/2004 9:32 PM >Subject: v6 host load balancing > >Dave, >Was sitting in the v6 mtg yesterday, and quickly reviewed your doc on >LB. I >see some use cases, particularly involving state-keeping gateways, like >FW >and IPS devices, for which this is going to cause tremendous havoc. >Could >my co-worker, changming and I get together with you for a bit and >discuss >to see if we are accurate in our assessment? > >perhaps as the pm break today (at ietf reg desk) or for bfast tomorrow? > >Pls advise, >Gregory. > >+++++++++++++++++++++++++ >IETF-related email from >Gregory M. Lebovitz >Architect - CTO Office >NetScreen Technologies > >-------------------------------------------------------------------- >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 exim@www1.ietf.org Wed Mar 3 22:27:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21516 for ; Wed, 3 Mar 2004 22:27:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyjW2-0005nq-NO for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 22:27:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i243RIJD022300 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 22:27:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyjW2-0005na-EH for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 22:27:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21487 for ; Wed, 3 Mar 2004 22:27:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyjVz-00070J-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 22:27:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyjV5-0006o0-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 22:26:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyjUA-0006cW-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 22:25:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyjTr-0005Bp-88; Wed, 03 Mar 2004 22:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyjSv-0005Ad-Tx for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 22:24:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21303 for ; Wed, 3 Mar 2004 22:24:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyjSs-0006Pg-00 for ipv6@ietf.org; Wed, 03 Mar 2004 22:24:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyjRy-0006FV-00 for ipv6@ietf.org; Wed, 03 Mar 2004 22:23:06 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AyjRE-0005wB-00 for ipv6@ietf.org; Wed, 03 Mar 2004 22:22:20 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 3 Mar 2004 19:22:05 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Mar 2004 19:21:50 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 19:21:57 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 19:22:55 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 3 Mar 2004 19:22:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v6 host load balancing Date: Wed, 3 Mar 2004 19:21:41 -0800 Message-ID: Thread-Topic: v6 host load balancing thread-index: AcQBk0jQplbP9huSSKyFoDL1TeKwowABDtgQ From: "Dave Thaler" To: "Changming Liu" Cc: X-OriginalArrivalTime: 04 Mar 2004 03:22:00.0911 (UTC) FILETIME=[DB987DF0:01C40197] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Changming Liu writes: > For example, picture a network below: > a FTP server farm protected a firewall, and a FTP client also behind its > firewall and there are multiple firewalls in different locations to > pretect > the corporate of the client is in. If the client is doing destination load > balance, it may use different corporate firewall as exit point for FTP > data > channels. This is because FTP server can tell its client to use different > server for data channels. This still poses big challenge today. If the server is telling the client who to use, then the client is connecting out for both the data and the control channels. If they go out different exit points on the client side, there's no problem since both connections are initiated from the inside, right? Can you elaborate more on what the problematic scenario is? -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 23:57:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27558 for ; Wed, 3 Mar 2004 23:57:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AykuP-0008E1-16 for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 23:56:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i244uWWX031611 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 23:56:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AykuO-0008Dm-Rr for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 23:56:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27416 for ; Wed, 3 Mar 2004 23:56:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AykuM-00016Z-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:56:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyksV-0000ZU-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:54:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AykrD-0000KL-04 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:53:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AykmJ-00067l-2U for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:48:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykm9-0007DU-JY; Wed, 03 Mar 2004 23:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyklF-0007BZ-6x for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 23:47:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27024 for ; Wed, 3 Mar 2004 23:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyklD-00078F-00 for ipv6@ietf.org; Wed, 03 Mar 2004 23:47:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AykkF-0006wg-00 for ipv6@ietf.org; Wed, 03 Mar 2004 23:46:04 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx with esmtp (Exim 4.12) id 1AykjM-0006jB-00 for ipv6@ietf.org; Wed, 03 Mar 2004 23:45:08 -0500 Received: from localhost ([130.194.13.83]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L7C1RP5M3G8WWBV9@vaxc.its.monash.edu.au> for ipv6@ietf.org; Thu, 04 Mar 2004 15:38:17 +1100 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id ACF3A23C009; Thu, 04 Mar 2004 15:38:15 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by splat.its.monash.edu.au (Postfix) with ESMTP id 962D816400A; Thu, 04 Mar 2004 15:38:15 +1100 (EST) Date: Thu, 04 Mar 2004 04:38:15 +0000 (GMT) From: Gregory Daley Subject: RFC2461bis Solicitation issues. To: ipv6@ietf.org Cc: h.soliman@flarion.com Message-id: <72479c729d88.729d8872479c@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT (About issues 256 (RS Delay) and 258 (NS delay)) Follow up from session: At this stage, I think that DNA will be working on determination of delay requirements for RS and NS upon arrival on a link. (So that text doesn't need to be in rfc2461bis) I actually can only think of the simultaneous movement, simulataneous startup/simultaneous configuration as reasons for this delay today. Can anyone think of anything else? DAD delays are already handled in 2462bis. NS and RS upon reception of an RA aren't though. I think these are missed in the current RFC. Additionally it may be benficial to distinguish between boot-up scenarios where many devices may configure simultaneously, and ephemeral connectivity due to wireless channels, etc. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 23:57:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27706 for ; Wed, 3 Mar 2004 23:57:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykui-0008Gp-Ly for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 23:56:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i244uq6x031785 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 23:56:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykui-0008Ga-HG for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 23:56:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27525 for ; Wed, 3 Mar 2004 23:56:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aykug-0001AP-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:56:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayksy-0000ek-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:55:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AykrJ-0000KL-03 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:53:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aykhm-00062W-EL for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:43:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AykhK-0006Vm-LL; Wed, 03 Mar 2004 23:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykgs-0006PH-HA for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 23:42:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26430 for ; Wed, 3 Mar 2004 23:42:31 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aykgq-00061Q-00 for ipv6@ietf.org; Wed, 03 Mar 2004 23:42:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aykfg-0005jc-00 for ipv6@ietf.org; Wed, 03 Mar 2004 23:41:20 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aykec-0005Ox-00 for ipv6@ietf.org; Wed, 03 Mar 2004 23:40:15 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i244e9C20820; Thu, 4 Mar 2004 06:40:09 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 06:39:49 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i244dntn028668; Thu, 4 Mar 2004 06:39:49 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00ghZGph; Thu, 04 Mar 2004 06:39:47 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i244dk720461; Thu, 4 Mar 2004 06:39:46 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 06:39:46 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: [rfc2462bis] M/O flags and DHCPv6 Date: Thu, 4 Mar 2004 06:39:46 +0200 Message-ID: Thread-Topic: [rfc2462bis] M/O flags and DHCPv6 thread-index: AcQBj8JI6ri7/IL5TBaZAK2D69TuzAAAB2IAAASrrNA= To: , Cc: X-OriginalArrivalTime: 04 Mar 2004 04:39:46.0400 (UTC) FILETIME=[B8719E00:01C401A2] Content-Transfer-Encoding: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQo+IFBlcnNvbmFsbHksIEkgZG9uJ3QgdGhpbmsgdGhlcmUncyBhbnkgbmVlZCB0 byByZWZlciB0byB0aGUgDQo+IG5vZGUtcmVxIGRvYy4NCg0KSSBhZ3JlZS4gIEJ1dCBJIHRoaW5r IHdlIGNhbiBldmVuIGluY2x1ZGUgYSByZWYgdG8gREhDUHY2DQphcyBpbmZvcm1hdGl2ZS4gIEkg ZG9uJ3Qgc2VlIGhvdyB0aGVyZSBjYW4gYmUgYSBub3JtYXRpdmUNCnJlZmVyZW5jZSB0byBTdGF0 ZWZ1bCBBZGQgQXV0b2NvbmYuIGlmIHdlIGFyZSBkZWZpbmluZw0KU3RhdGVsZXNzIEFkZCBBdXRv Y29uZi4gDQoNCkpvaG4NCg== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 3 23:57:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27870 for ; Wed, 3 Mar 2004 23:57:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykv5-0008KV-OD for ipv6-archive@odin.ietf.org; Wed, 03 Mar 2004 23:57:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i244vFDQ032013 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 23:57:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykv5-0008KG-IQ for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 23:57:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27622 for ; Wed, 3 Mar 2004 23:57:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aykv3-0001Ln-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:57:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyktU-0000nO-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:55:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AykrP-0000KL-02 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:53:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aykex-0005yk-RV for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 23:40:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AykeT-0005bk-0X; Wed, 03 Mar 2004 23:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AykdU-0005Mx-QV for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 23:39:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25986 for ; Wed, 3 Mar 2004 23:39:02 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AykdS-0005B4-00 for ipv6@ietf.org; Wed, 03 Mar 2004 23:39:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AykcY-0004yn-00 for ipv6@ietf.org; Wed, 03 Mar 2004 23:38:07 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aykbf-0004pI-00 for ipv6@ietf.org; Wed, 03 Mar 2004 23:37:12 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i244b4Z29848; Thu, 4 Mar 2004 06:37:04 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 06:36:48 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i244amoD021585; Thu, 4 Mar 2004 06:36:48 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00xL48x4; Thu, 04 Mar 2004 06:36:47 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i244al719044; Thu, 4 Mar 2004 06:36:47 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 06:36:47 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 06:36:47 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rfc2462bis] M/O flags and DHCPv6 Date: Thu, 4 Mar 2004 06:36:46 +0200 Message-ID: Thread-Topic: [rfc2462bis] M/O flags and DHCPv6 thread-index: AcQBj92v3+2tC90SQA2waELcOgU7YwAEVQiQ To: , Cc: X-OriginalArrivalTime: 04 Mar 2004 04:36:47.0063 (UTC) FILETIME=[4D8CF670:01C401A2] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka, I suspect we are playing games with language, but ... > > The easiest solution to them would be to list RFC3315 as an > > informative reference. I don't know whether this is acceptable. > > According to Section 2.7 of draft-rfc-editor-rfc2223bis-07.txt, > > Normative references specify > >=20 > > - documents that must be read to understand or implement the > > technology in the new RFC > > - documents whose technology must be present for the technology > > in the new RFC to work > >=20 > > But the first condition seems to me a bit subjective. Under which > > requirement can we decide a document must be read for a different > > document? >=20 > I don't think this is a problem. You don't have to understand DHCPv6=20 > to ignore M/O bits -- which you only act upon IF you have implemented=20 > DHCPv6 -- and then you understand it already :). .. but the goal of 2462(-bis) is STATELESS ADDRESS AUTOCONFIG. I don't = think that this document has ANY normative dependencies on Stateful Address Autoconfig. Re-reading the draft several times, I can only see that DHCPv6 is informative, at best. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 4 00:19:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29001 for ; Thu, 4 Mar 2004 00:19:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylGY-0002VA-Gk for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 00:19:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i245JQtn009610 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 00:19:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylGX-0002Uv-U7 for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 00:19:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28920 for ; Thu, 4 Mar 2004 00:19:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AylGV-0005Kc-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:19:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylFW-00055u-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:18:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AylES-0004la-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:17:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylED-0001wN-P2; Thu, 04 Mar 2004 00:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylDP-0001vF-Fu for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 00:16:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28818 for ; Thu, 4 Mar 2004 00:16:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AylDN-0004jR-00 for ipv6@ietf.org; Thu, 04 Mar 2004 00:16:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylCR-0004aB-00 for ipv6@ietf.org; Thu, 04 Mar 2004 00:15:11 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1AylC5-0004Qq-00 for ipv6@ietf.org; Thu, 04 Mar 2004 00:14:49 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i245EJ9u006267; Wed, 3 Mar 2004 21:14:19 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 21:14:19 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6AE@MONTEREY.netscreen.com> From: Changming Liu To: "'Dave Thaler '" , Changming Liu Cc: "'ipv6@ietf.org '" Subject: RE: v6 host load balancing Date: Wed, 3 Mar 2004 21:14:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Dave, >If the server is telling the client who to use, then the client is >connecting out for both the data and the control channels. If they >go out different exit points on the client side, there's no problem >since both connections are initiated from the inside, right? >Can you elaborate more on what the problematic scenario is? Sure. In case of FTP data channel, the data connection was opened by the server by default! This is called active FTP. To get around this problem, RFC1579 Firewall-Friendly FTP, documents a passive open, in this case, the client initiates a connection. For more info, please see RFC 1579. No matter it is active or passive open, the modem stateful will need to open the "hole" by listening to the control channel for "port" and "pasv" comamnd. The hole is opened only on the firewall which is dealing the control channel. If the data channel goes to another file, apparently this will not work. FTP is just a classical example of this dynamic port problem that a firewall needs to deal with. For VoiP apps such H323 and SIP, similar problem exists as well and even severe. This is because the signalling channel and media channel are totally different and destination are usually completely different. As a firewall/NAT/IDP company we've been struggling with these issues all the time. It really adds lots of complexity to the system. I just don't want to get it worse in IPv6, if not better. Hope this makes sense to you. Changming -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 4 01:30:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05076 for ; Thu, 4 Mar 2004 01:30:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymMt-0004en-Bl for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 01:30:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i246U366017890 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 01:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymMs-0004eD-Hj for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:30:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04951 for ; Thu, 4 Mar 2004 01:30:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AymMp-0004uc-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 01:29:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymLF-0004Ss-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 01:28:21 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AymJH-0003uk-04 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 01:26:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aym7A-0007Qa-5y for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 01:13:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aym6Q-0001zx-8s; Thu, 04 Mar 2004 01:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aym5m-0001xo-Q6 for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 01:12:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03655 for ; Thu, 4 Mar 2004 01:12:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aym5j-0001Dy-00 for ipv6@ietf.org; Thu, 04 Mar 2004 01:12:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aym4Y-0000xg-00 for ipv6@ietf.org; Thu, 04 Mar 2004 01:11:07 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1Aym3Z-0000av-00 for ipv6@ietf.org; Thu, 04 Mar 2004 01:10:05 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i2469a9u008659; Wed, 3 Mar 2004 22:09:36 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 22:09:36 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6B2@MONTEREY.netscreen.com> From: Changming Liu To: "'Dave Thaler '" , Changming Liu Cc: "'ipv6@ietf.org '" Subject: RE: v6 host load balancing Date: Wed, 3 Mar 2004 22:09:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >Yes I'm aware of both modes. Since you mentioned the server told the >client >what server to use, I assumed you were talking about passive mode, which >is what I was responding to above. Sorry about not making it clear at the first place. Now we are on the same page. One minor point: the passive mode was for old proxy firewalls, which you can hardly find any around. >You lost me here. Since the passive open has the connection initiated >by the client, there is no need for the firewall around the client to >open a port based on listening to the control channel, right? Ok, let me try to explain. Even for outgoing connections, the policy needs to be matched on the firewall. (The firewall policy is just a complicated version of access list to match 5 tuples, you can think that way if this is any easy for you). And in most case, only one policy is defined for both FTP control and data channel. This is for simplity and accounting, logging and many other reasons, to list few. This is very common for all firewalls, not just ours. The data channel can not match the policy defined for control because of its dynamic port. So the firewall needs to open a hole (like a dynamic policy for data channel). >> The hole is opened only on the firewall which is dealing the >> control channel. If the data channel goes to another file, apparently this >> will not work. >I don't see why not. It's just another outgoing TCP connection. Is it clear now? If not, please forgive me, a white board discussion may be better. > FTP is just a classical example of this dynamic port problem that a > firewall > needs to deal with. For VoiP apps such H323 and SIP, similar problem > exists > as well and even severe. This is because the signalling channel and media > channel are totally different and destination are usually completely > different. > > > As a firewall/NAT/IDP company we've been struggling with these issues all > the time. It really adds lots of complexity to the system. I just don't > want > to get it worse in IPv6, if not better. > > Hope this makes sense to you. Not particularly. I'm still at the same point I was before where elaborating on what the exact scenario that fails is would help. Thanks, -Dave > Changming -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 4 01:30:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05095 for ; Thu, 4 Mar 2004 01:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymMu-0004fZ-CS for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 01:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i246U4I9017937 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 01:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymMu-0004f8-08 for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:30:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04957 for ; Thu, 4 Mar 2004 01:30:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AymMq-0004uo-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 01:30:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymLH-0004TK-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 01:28:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AymJH-0003uk-06 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 01:26:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aym77-0007QZ-V2 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 01:13:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aym6T-00021q-F9; Thu, 04 Mar 2004 01:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aym6F-0001zO-Mi for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 01:12:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03708 for ; Thu, 4 Mar 2004 01:12:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aym6C-0001IG-00 for ipv6@ietf.org; Thu, 04 Mar 2004 01:12:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aym59-00013G-00 for ipv6@ietf.org; Thu, 04 Mar 2004 01:11:44 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aym4F-0000p6-00 for ipv6@ietf.org; Thu, 04 Mar 2004 01:10:48 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 07BD215218; Thu, 4 Mar 2004 15:10:47 +0900 (JST) Date: Thu, 04 Mar 2004 15:11:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: john.loughney@nokia.com Cc: , Subject: Re: [rfc2462bis] M/O flags and DHCPv6 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Thu, 4 Mar 2004 06:39:46 +0200, >>>>> john.loughney@nokia.com said: >> Personally, I don't think there's any need to refer to the >> node-req doc. > I agree. But I think we can even include a ref to DHCPv6 > as informative. I don't see how there can be a normative > reference to Stateful Add Autoconf. if we are defining > Stateless Add Autoconf. So far, all the responses in this thread seem to support having RFC3315 (DHCPv6) in rfc2462bis as an informative reference, and not referring to the node-req draft. Is my understanding correct? I can live with this approach. But I also think it is helpful to mention like "what is the stateful protocol (and propbably the mandatory level to implement it) is beyond the scope of rfc2462bis and is specified in a separate document". Otherwise, readers would continue to wonder what the stateful protocol is while we could actually answer the question. In summary, I'd like to propose - in the body of rfc2462bis, we do not explicitly say what the stateful protocol is but mention that it is specified in a separate document. - regarding reference, we only list RFC3315 as an informative reference. (and we probably need some additional text in the body that refers to the reference) Does this make sense? 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 exim@www1.ietf.org Thu Mar 4 02:31:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22982 for ; Thu, 4 Mar 2004 02:31:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynJT-0001ck-OZ for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 02:30:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i247UZVk006240 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 02:30:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynJT-0001cZ-6g for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 02:30:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22892 for ; Thu, 4 Mar 2004 02:30:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynJP-00029w-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:30:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynIS-0001mo-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:29:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AynHQ-0001Xk-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:28:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynH1-0000gp-7h; Thu, 04 Mar 2004 02:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynGQ-0000Yc-Fp for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 02:27:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22335 for ; Thu, 4 Mar 2004 02:27:23 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynGM-0001IV-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:27:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynFL-00014v-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:26:20 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AynEO-0000sF-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:25:20 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i247PEC24769; Thu, 4 Mar 2004 09:25:15 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 09:24:16 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i247OGo3011077; Thu, 4 Mar 2004 09:24:16 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00h3r4nI; Thu, 04 Mar 2004 09:24:14 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i247OD706175; Thu, 4 Mar 2004 09:24:13 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 09:24:13 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [rfc2462bis] M/O flags and DHCPv6 Date: Thu, 4 Mar 2004 09:24:12 +0200 Message-ID: Thread-Topic: [rfc2462bis] M/O flags and DHCPv6 thread-index: AcQBr373wcpRTGcnQQWN/PQ87XHOaAACfVNQ To: Cc: , X-OriginalArrivalTime: 04 Mar 2004 07:24:13.0236 (UTC) FILETIME=[B1894F40:01C401B9] Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jinmei, > So far, all the responses in this thread seem to support having > RFC3315 (DHCPv6) in rfc2462bis as an informative reference, and not > referring to the node-req draft. Is my understanding correct? Yes, I think so. > I can live with this approach. But I also think it is helpful to > mention like "what is the stateful protocol (and propbably the > mandatory level to implement it) is beyond the scope of rfc2462bis and > is specified in a separate document". Otherwise, readers would > continue to wonder what the stateful protocol is while we could > actually answer the question. How about: This document does not define stateful address autoconfiguration, which is specified in a seperate document [informative reference here]. > In summary, I'd like to propose > > - in the body of rfc2462bis, we do not explicitly say what the > stateful protocol is but mention that it is specified in a separate > document. > - regarding reference, we only list RFC3315 as an informative > reference. (and we probably need some additional text in the body > that refers to the reference) > > Does this make sense? I'm happy with it. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 4 03:02:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26026 for ; Thu, 4 Mar 2004 03:02:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynnX-0006mL-Je for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 03:01:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2481cNN026041 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:01:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynnV-0006lw-Uq for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:01:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25861 for ; Thu, 4 Mar 2004 03:01:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynnS-0001E8-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:01:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynlW-0000gR-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:59:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AynkZ-0000Tw-01 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:58:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AynhZ-0000Nv-Lo for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:55:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynhA-0005RY-HX; Thu, 04 Mar 2004 02:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayng8-0005OU-UJ for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 02:54:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25068 for ; Thu, 4 Mar 2004 02:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayng5-00078N-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:53:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyneI-0006c0-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:52:07 -0500 Received: from [63.126.135.18] (helo=mail2.netscreen.com) by ietf-mx with esmtp (Exim 4.12) id 1Aynct-00068c-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:50:39 -0500 Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail2.netscreen.com (Switch-3.1.3/Switch-3.1.0) with ESMTP id i247o29u013198; Wed, 3 Mar 2004 23:50:02 -0800 (PST) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 23:50:02 -0800 Message-ID: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C6B9@MONTEREY.netscreen.com> From: Changming Liu To: "'Suresh Satapati '" , "'Dave Thaler '" Cc: Changming Liu , "'ipv6@ietf.org '" Subject: RE: v6 host load balancing Date: Wed, 3 Mar 2004 23:50:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Suresh, =20 Thanks. That's exactly what's happening. Changming -----Original Message----- From: Suresh Satapati To: Dave Thaler Cc: Changming Liu; ipv6@ietf.org Sent: 2004-03-03 =BFAEA 11:43 Subject: RE: v6 host load balancing Dave, Lemme give this a try.. > > No matter it is active or passive open, the modem stateful will = need > to > > open > > the "hole" by listening to the control channel for "port" and = "pasv" > > comamnd. > > You lost me here. Since the passive open has the connection = initiated > by the client, there is no need for the firewall around the client to > open a port based on listening to the control channel, right? > if there is a fw X on the path to the server, fw X may have to look at the PASV response and open a hole for the subsequent data traffic from the client. something like a dynamic (created on-the-fly) outbound access list. > > The hole is opened only on the firewall which is dealing the > > control channel. If the data channel goes to another file, apparently > this > > will not work. > > I don't see why not. It's just another outgoing TCP connection. > coz data from the client may be going thru a different device Y, which is being blocked by the fw on that device. fw Y doesn't have the hole to let the traffic go through. Hope this helps. -- Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 4 03:02:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26027 for ; Thu, 4 Mar 2004 03:02:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynnX-0006mI-A3 for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 03:01:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2481cNE026033 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:01:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynnU-0006lm-8c for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:01:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25855 for ; Thu, 4 Mar 2004 03:01:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynnQ-0001Dl-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:01:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynlS-0000ft-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:59:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AynkY-0000Tw-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:58:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aynif-0000On-Mp for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:56:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyniF-0005tY-Be; Thu, 04 Mar 2004 02:56:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynhu-0005oz-E9 for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 02:55:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25464 for ; Thu, 4 Mar 2004 02:55:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynhq-0007fk-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:55:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayngf-0007Lx-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:54:35 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Ayner-0006oy-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:52:41 -0500 Received: from ocean.jinmei.org (unknown [2001:220:101a:224:202:2dff:fe6a:d20]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1302615210; Thu, 4 Mar 2004 16:52:41 +0900 (JST) Date: Thu, 04 Mar 2004 16:52:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: ipv6@ietf.org Subject: Re: [rfc2462bis] M/O flags and DHCPv6 In-Reply-To: <4.3.2.7.2.20040304023041.029dc170@flask.cisco.com> References: <4.3.2.7.2.20040304023041.029dc170@flask.cisco.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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Thu, 04 Mar 2004 02:33:23 -0500, >>>>> Ralph Droms said: >> In the wg meeting on Tuesday, several concerns were raised regarding >> this issue (and the proposed resolution). To summarize (some of) >> them, >> >> 1. the resolution proposes to say "the stateful protocol is DHCPv6" >> clearly, without leaving other possibilities. This would require >> RFC3315 (DHCPv6) to be listed as a normative reference. However, >> we'll then face a reference dependency issue, since rfc2462bis is >> soon expected to be recycled as a DS while RFC3315 is still a PS. >> (BTW: I could not find a direct source of this dependency issue. >> Could someone give me a pointer?) > Do you mean that a DS spec cannot have an informative reference to a PS spec? No, my understanding is: - a DS spec cannot have a normative reference to a PS spec. (though I could not find a direct source of this dependency rule) - a DS spec can have an informative reference to a PS spec. 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 exim@www1.ietf.org Thu Mar 4 03:02:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26097 for ; Thu, 4 Mar 2004 03:02:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynnf-0006nX-0a for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 03:01:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2481k6a026121 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:01:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynne-0006nE-HM for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:01:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25898 for ; Thu, 4 Mar 2004 03:01:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynna-0001Fq-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:01:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynlj-0000iF-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:59:47 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aynkb-0000Tw-01 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:58:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyneZ-0000Iw-Qb for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:52:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyneF-0004uB-Pt; Thu, 04 Mar 2004 02:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyndH-0004gk-Lt for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 02:51:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24678 for ; Thu, 4 Mar 2004 02:51:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyndD-0006J9-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:50:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aync2-00062P-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:49:47 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1AynbJ-0005mW-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:49:01 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i247mTe2121008; Thu, 4 Mar 2004 07:48:29 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i247mVOQ207270; Thu, 4 Mar 2004 08:48:31 +0100 Received: from zurich.ibm.com (sig-9-145-230-158.de.ibm.com [9.145.230.158]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA57742; Thu, 4 Mar 2004 08:48:21 +0100 Message-ID: <40461D35.5D17EE08@zurich.ibm.com> Date: Wed, 03 Mar 2004 19:00:21 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Erik Nordmark CC: Francis Dupont , Brian Haberman , ipv6@ietf.org Subject: Re: Adopt Address Selection API as a WG document? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't disagree, and I didn't mean to imply that this is relevant to multihoming. But in practice I think these choices will be made by a separate policy mechanism, not by individual applications. Brian Erik Nordmark wrote: > > > As we are seeing in the multi-addressing discussions in multi6, > > there is indeed strong pressure from applications people against > > apps having to know anything at all about address selection. > > This becomes even more true when you get into Java land. > > > > So while this API is probably harmless, I agree with Francis > > its applicability is very limited. In fact, I would be tempted to > > argue for it becoming Experimental. However, I think it is perfectly > > valid for it to become a WG draft. > > The draft in question doesn't look at multiple addresses of the same > type/properties, such as multiple prefixes in the case of multihoming. > > The draft is about being able to choose between things like temporary and > public addresses, which is something which users/applications might care > about. And this is orthogonal to the multihoming aspects. > > Erik -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 4 03:24:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28042 for ; Thu, 4 Mar 2004 03:24:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo9M-0001Yo-Mz for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 03:24:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248OCSl005985 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo9G-0001Y9-8K for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:24:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27920 for ; Thu, 4 Mar 2004 03:24:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo9D-0006KE-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:24:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayo7U-0005oO-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:22:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayo5w-0005Tb-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:20:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AynqB-0000dI-EI for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:04:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynpv-0007Hp-Ed; Thu, 04 Mar 2004 03:04:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynpL-00074A-Eu for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 03:03:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26393 for ; Thu, 4 Mar 2004 03:03:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynpG-0001nl-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:03:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynoH-0001Vh-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:02:26 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Aynmf-0000nL-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:00:45 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 04 Mar 2004 00:04:23 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2480ExU014946; Thu, 4 Mar 2004 03:00:14 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-91.cisco.com [10.86.242.91]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGM98664; Thu, 4 Mar 2004 03:00:12 -0500 (EST) Message-Id: <4.3.2.7.2.20040304025619.01fdb038@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Mar 2004 03:00:08 -0500 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [rfc2462bis] M/O flags and DHCPv6 Cc: ipv6@ietf.org In-Reply-To: References: <4.3.2.7.2.20040304023041.029dc170@flask.cisco.com> <4.3.2.7.2.20040304023041.029dc170@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Jinmei - I mistyped and you guessed what I had intended to ask. Good catch and thanks for the clarification. Can anyone supply a direct reference to an explicit statement that "a DS spec cannot have a normative reference to a PS spec."? - Ralph At 04:52 PM 3/4/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Thu, 04 Mar 2004 02:33:23 -0500, > >>>>> Ralph Droms said: > > >> In the wg meeting on Tuesday, several concerns were raised regarding > >> this issue (and the proposed resolution). To summarize (some of) > >> them, > >> > >> 1. the resolution proposes to say "the stateful protocol is DHCPv6" > >> clearly, without leaving other possibilities. This would require > >> RFC3315 (DHCPv6) to be listed as a normative reference. However, > >> we'll then face a reference dependency issue, since rfc2462bis is > >> soon expected to be recycled as a DS while RFC3315 is still a PS. > >> (BTW: I could not find a direct source of this dependency issue. > >> Could someone give me a pointer?) > > > Do you mean that a DS spec cannot have an informative reference to a PS > spec? > >No, my understanding is: > >- a DS spec cannot have a normative reference to a PS spec. (though I > could not find a direct source of this dependency rule) >- a DS spec can have an informative reference to a PS spec. > > 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 exim@www1.ietf.org Thu Mar 4 03:24:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28063 for ; Thu, 4 Mar 2004 03:24:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo9O-0001Z9-Q8 for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 03:24:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248OEPm006013 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:24:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo9O-0001Yu-Bv for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:24:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27950 for ; Thu, 4 Mar 2004 03:24:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo9M-0006MO-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:24:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayo7Z-0005pq-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:22:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayo5x-0005Tb-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:20:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aynpd-0000cI-4O for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynot-0006rz-Qh; Thu, 04 Mar 2004 03:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynoX-0006qW-5U for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 03:02:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26276 for ; Thu, 4 Mar 2004 03:02:37 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynoT-0001Y4-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:02:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynmv-0000yK-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:01:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aynkn-0000Tw-01 for ipv6@ietf.org; Thu, 04 Mar 2004 02:58:49 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aynaf-0000Bt-QR for ipv6@ietf.org; Thu, 04 Mar 2004 02:48:21 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i247m9h09581; Thu, 4 Mar 2004 09:48:09 +0200 (EET) X-Scanned: Thu, 4 Mar 2004 09:48:06 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i247m6Xs018163; Thu, 4 Mar 2004 09:48:06 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00XruTes; Thu, 04 Mar 2004 09:48:05 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i247m4725313; Thu, 4 Mar 2004 09:48:04 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Mar 2004 09:48:03 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rfc2462bis] M/O flags and DHCPv6 Date: Thu, 4 Mar 2004 09:48:00 +0200 Message-ID: Thread-Topic: [rfc2462bis] M/O flags and DHCPv6 thread-index: AcQBvKEAi2tsdHQ0SNWtBgPSeB8XOwAADKDQ To: Cc: , , X-OriginalArrivalTime: 04 Mar 2004 07:48:04.0101 (UTC) FILETIME=[0665FB50:01C401BD] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ralph, > John - I agree that "the goal of 2462(-bis) is STATELESS ADDRESS > AUTOCONFIG." However, the bits controlling use of stateless/stateful = are > also defined in RFC 2462bis, so RFC 2462bis goes a little beyond just > defining how stateless address autoconfig. Invoking the camel's nose > principle, and striving for clarity, I would suggest that it would be > appropriate for RFC 2462bis to explicitly define the=20 > stateful protocol as RFC 3315, with an informative reference to RFC = 3315. I have no problem with 2462-bis saying that Stateless Address = Autoconfiguration is DHCPv6, with an Informative Ref to 3315. This seems like a truth in advertising point. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 4 03:24:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28119 for ; Thu, 4 Mar 2004 03:24:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo9Z-0001eY-2r for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 03:24:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248OOBv006161 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:24:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo9W-0001an-FX for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:24:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27983 for ; Thu, 4 Mar 2004 03:24:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo9U-0006TF-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:24:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayo7i-0005s0-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:22:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayo5y-0005Tb-04 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:20:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aynpc-0000cJ-Kk for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:03:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynow-0006sE-Jo; Thu, 04 Mar 2004 03:03:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynof-0006qf-KJ for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 03:02:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26304 for ; Thu, 4 Mar 2004 03:02:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynob-0001ZW-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:02:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynn7-000120-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:01:14 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aynkp-0000Tw-03 for ipv6@ietf.org; Thu, 04 Mar 2004 02:58:51 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AynWP-00008d-HN for ipv6@ietf.org; Thu, 04 Mar 2004 02:43:57 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 03 Mar 2004 23:42:06 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i247hMxU012728; Thu, 4 Mar 2004 02:43:22 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-91.cisco.com [10.86.242.91]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGM98067; Thu, 4 Mar 2004 02:43:19 -0500 (EST) Message-Id: <4.3.2.7.2.20040304023634.02a96a80@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Mar 2004 02:41:23 -0500 To: john.loughney@nokia.com From: Ralph Droms Subject: RE: [rfc2462bis] M/O flags and DHCPv6 Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 John - I agree that "the goal of 2462(-bis) is STATELESS ADDRESS AUTOCONFIG." However, the bits controlling use of stateless/stateful are also defined in RFC 2462bis, so RFC 2462bis goes a little beyond just defining how stateless address autoconfig. Invoking the camel's nose principle, and striving for clarity, I would suggest that it would be appropriate for RFC 2462bis to explicitly define the stateful protocol as RFC 3315, with an informative reference to RFC 3315. - Ralph At 06:36 AM 3/4/2004 +0200, john.loughney@nokia.com wrote: >Pekka, > >I suspect we are playing games with language, but ... > > > > The easiest solution to them would be to list RFC3315 as an > > > informative reference. I don't know whether this is acceptable. > > > According to Section 2.7 of draft-rfc-editor-rfc2223bis-07.txt, > > > Normative references specify > > > > > > - documents that must be read to understand or implement the > > > technology in the new RFC > > > - documents whose technology must be present for the technology > > > in the new RFC to work > > > > > > But the first condition seems to me a bit subjective. Under which > > > requirement can we decide a document must be read for a different > > > document? > > > > I don't think this is a problem. You don't have to understand DHCPv6 > > to ignore M/O bits -- which you only act upon IF you have implemented > > DHCPv6 -- and then you understand it already :). > >.. but the goal of 2462(-bis) is STATELESS ADDRESS AUTOCONFIG. I don't think >that this document has ANY normative dependencies on Stateful Address >Autoconfig. Re-reading the draft several times, I can only see that >DHCPv6 is informative, at best. > >John > >-------------------------------------------------------------------- >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 exim@www1.ietf.org Thu Mar 4 04:46:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04109 for ; Thu, 4 Mar 2004 04:46:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypR1-0003ks-FE for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 04:46:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i249kV0e014428 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 04:46:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypR1-0003kd-5o for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 04:46:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04068 for ; Thu, 4 Mar 2004 04:46:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypQx-0001VC-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 04:46:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypQ3-0001HJ-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 04:45:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AypP0-00012b-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 04:44:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypOe-0003Jz-K9; Thu, 04 Mar 2004 04:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypO4-00037v-Pp for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 04:43:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03843 for ; Thu, 4 Mar 2004 04:43:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypO0-0000pt-00 for ipv6@ietf.org; Thu, 04 Mar 2004 04:43:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypN9-0000f6-00 for ipv6@ietf.org; Thu, 04 Mar 2004 04:42:32 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypMX-0000U2-00 for ipv6@ietf.org; Thu, 04 Mar 2004 04:41:53 -0500 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i249frOr016148 for ; Thu, 4 Mar 2004 09:41:53 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA22967 for ; Thu, 4 Mar 2004 09:41:51 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i249foi08966 for ipv6@ietf.org; Thu, 4 Mar 2004 09:41:50 GMT Date: Thu, 4 Mar 2004 09:41:50 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: v6 host load balancing Message-ID: <20040304094150.GC8325@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C69B@MONTEREY.netscreen.com> <4.3.2.7.2.20040303174845.00b1e6d0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Mar 04, 2004 at 12:01:51AM -0800, Suresh Satapati wrote: > > Disagree. load-sharing or router preferences were/are never a general case > IMO and hence i disagree with MUST. I also think the security section of the draft needs a bit of deeper analysis, e.g. for the rogue router-in-the-middle. Also diagnosis of problems may be harder. I think the proposal is interesting, but not a MUST. tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 4 06:13:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09321 for ; Thu, 4 Mar 2004 06:13:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqmV-0003l3-Os for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 06:12:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24BClNq014439 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 06:12:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqmV-0003ko-Iu for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 06:12:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09207 for ; Thu, 4 Mar 2004 06:12:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyqmR-0004Mi-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 06:12:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyqkI-0003bU-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 06:10:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyqiT-0003ET-03 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 06:08:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayqab-00045E-5x for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 06:00:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqaC-0001QK-DZ; Thu, 04 Mar 2004 06:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqZk-0001Op-B3 for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 05:59:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08514 for ; Thu, 4 Mar 2004 05:59:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyqZg-0001dF-00 for ipv6@ietf.org; Thu, 04 Mar 2004 05:59:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyqZ9-0001S5-00 for ipv6@ietf.org; Thu, 04 Mar 2004 05:58:59 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyqY9-00018j-00 for ipv6@ietf.org; Thu, 04 Mar 2004 05:57:57 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i24Av9k07260; Thu, 4 Mar 2004 12:57:09 +0200 Date: Thu, 4 Mar 2004 12:57:09 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: Suresh Satapati , Subject: RE: v6 host load balancing In-Reply-To: <4.3.2.7.2.20040304001227.02301930@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 4 Mar 2004, Bob Hinden wrote: > >coz data from the client may be going thru a different device Y, which is > >being blocked by the fw on that device. fw Y doesn't have the hole > >to let the traffic go through. > > This won't be caused by the load sharing when the data and control are > going to the same destination host. If the data traffic is going to a > different destination host, then it could end up on a different router > because of a more specific route or a redirect. I don't see that load > sharing adds to the complexity. In cases in which this is mostly important, the hosts have a default route. Then e.g. SIP data and signalling should go through the same path. This is the scenario which fails (in addition to the generic debug etc. problems which happen when something breaks from one first hop router to somewhere in the direction of Internet. Hosts which have more specific routes are set there explicitly, manually or using the more specific route extension. I'd still like to remove the "MUST share load" from the document. Of course, I can see that it's very useful in many scenarios for load distribution. But still not a MUST. What I want to see that the implementations implement this feature, so that it's available for use for those who need it. But I want it disabled by default and a MUST for a toggle to enable/disable it. to implement draft-ietf-ipv6-host-load-sharing-01.txt, otherwise I don't buy your product". Does not help in getting stuff like this deployed. -- 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 exim@www1.ietf.org Thu Mar 4 12:29:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03215 for ; Thu, 4 Mar 2004 12:29:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyweN-00024g-Fs for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 12:28:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24HSlFe007964 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 12:28:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyweM-00024K-VV for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 12:28:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03185 for ; Thu, 4 Mar 2004 12:28:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyweL-0001DM-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 12:28:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AywdM-0000zq-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 12:27:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AywcW-0000mF-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 12:26:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aywbi-0001Yo-I8; Thu, 04 Mar 2004 12:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aywb0-0001WZ-7P for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 12:25:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02954 for ; Thu, 4 Mar 2004 12:25:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayway-0000Pq-00 for ipv6@ietf.org; Thu, 04 Mar 2004 12:25:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AywZR-0000Ei-00 for ipv6@ietf.org; Thu, 04 Mar 2004 12:23:42 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AywYr-00004o-00 for ipv6@ietf.org; Thu, 04 Mar 2004 12:23:05 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1D0D415210 for ; Fri, 5 Mar 2004 02:22:57 +0900 (JST) Date: Fri, 05 Mar 2004 02:23:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: API extension to get IP addresses (Re: additional agenda item) 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Mon, 01 Mar 2004 10:12:41 +0900, >>>>> JINMEI Tatuya said: > According to the agenda shown at > http://www.ietf.org/ietf/04mar/ipv6.txt, we will be able to have a few > more items. If this is the case, may I ask for a short slot about an > API extension to get a list of IPv6 addresses (as well as other AF > addresses) on a node? This was discussed in the wg list early > February and I just made a delayed response. (the subject is > "SIOCGIFaaa ioctls and IPv6 interfaces"). > I don't have a draft on this, and this may not be suitable for this wg > (or even for the IETF), but some people seem to be interested in this > topic, I want to have a chance to see if this is worth discussing in > this group. My understanding in the meeting was that this wg is not an appropriate place to discuss the issue though this is a useful topic. I actually thought the same concern from the beginning, so I'm fine with the decision. Dave mentioned POSIX as a more appropriate place, but I myself have do not any connection to the community. As suggested at the meeting, I thus would like to ask a question here: does anyone have a suggestion on a further step for this work, including how we can get access to the community, or a different "appropriate place" that we can easily cooperate with, etc? Any comments/suggestions are welcome. 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 exim@www1.ietf.org Thu Mar 4 19:42:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23870 for ; Thu, 4 Mar 2004 19:42:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az3Pm-000794-3Z for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 19:42:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i250gArs027460 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 19:42:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az3Pl-00078p-S1 for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 19:42:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23866 for ; Thu, 4 Mar 2004 19:42:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az3Pj-0004fh-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 19:42:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az3Oo-0004UB-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 19:41:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az3OF-0004Ii-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 19:40:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az3Nl-0006p7-Uf; Thu, 04 Mar 2004 19:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az3Mj-0006kC-IA for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 19:39:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23735 for ; Thu, 4 Mar 2004 19:38:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az3Mh-00047U-00 for ipv6@ietf.org; Thu, 04 Mar 2004 19:38:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az3Ll-0003xk-00 for ipv6@ietf.org; Thu, 04 Mar 2004 19:38:02 -0500 Received: from gura.nttv6.jp ([210.163.36.2]) by ietf-mx with esmtp (Exim 4.12) id 1Az3LJ-0003mF-00 for ipv6@ietf.org; Thu, 04 Mar 2004 19:37:33 -0500 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [IPv6:2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 4B3681FE47; Fri, 5 Mar 2004 09:36:55 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id B5CBB125B70; Fri, 5 Mar 2004 09:36:55 +0900 (JST) Date: Fri, 05 Mar 2004 09:36:55 +0900 (JST) Message-Id: <20040305.093655.88533634.yasuhiro@nttv6.jp> To: jinmei@isl.rdc.toshiba.co.jp Cc: ipv6@ietf.org Subject: Re: API extension to get IP addresses From: SHIRASAKI Yasuhiro In-Reply-To: References: X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit $B3N$+$K$S$_$g!<(B -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 4 20:41:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26756 for ; Thu, 4 Mar 2004 20:41:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4KX-0004bx-HA for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 20:40:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i251ensa017719 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 20:40:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4KX-0004bi-Ai for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 20:40:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26612 for ; Thu, 4 Mar 2004 20:40:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az4KV-00006B-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 20:40:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az4Iw-0007WA-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 20:39:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Az4Hu-0007IP-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 20:38:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Az4CK-0006fy-Fc for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 20:32:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4C3-0003TR-2B; Thu, 04 Mar 2004 20:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4By-0003T1-Na for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 20:31:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26242 for ; Thu, 4 Mar 2004 20:31:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az4Bw-0006FZ-00 for ipv6@ietf.org; Thu, 04 Mar 2004 20:31:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az4B3-00066a-00 for ipv6@ietf.org; Thu, 04 Mar 2004 20:31:02 -0500 Received: from gura.nttv6.jp ([210.163.36.2]) by ietf-mx with esmtp (Exim 4.12) id 1Az4AU-0005vL-00 for ipv6@ietf.org; Thu, 04 Mar 2004 20:30:27 -0500 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [IPv6:2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 44E7A1FE47; Fri, 5 Mar 2004 10:29:57 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 0DC2E125B70; Fri, 5 Mar 2004 10:29:57 +0900 (JST) Date: Fri, 05 Mar 2004 10:29:17 +0900 (JST) Message-Id: <20040305.102917.35716136.yasuhiro@nttv6.jp> To: jinmei@isl.rdc.toshiba.co.jp Cc: ipv6@ietf.org Subject: Re: API extension to get IP addresses From: SHIRASAKI Yasuhiro In-Reply-To: <20040305.093655.88533634.yasuhiro@nttv6.jp> References: <20040305.093655.88533634.yasuhiro@nttv6.jp> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please ignore previous mail. I selected incorrect mail to reply. Sorry for bothering you. -- SHIRASAKI Yasuhiro -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 4 21:10:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28170 for ; Thu, 4 Mar 2004 21:10:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4mL-0000ts-NW for ipv6-archive@odin.ietf.org; Thu, 04 Mar 2004 21:09:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2529X7N003460 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 21:09:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4mL-0000tj-Gh for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 21:09:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28137 for ; Thu, 4 Mar 2004 21:09:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az4mJ-0005le-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 21:09:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az4lG-0005WU-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 21:08:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az4kc-0005I1-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 21:07:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4jv-0008DR-ND; Thu, 04 Mar 2004 21:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4j6-0007vp-RA for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 21:06:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27907 for ; Thu, 4 Mar 2004 21:06:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az4j4-00052D-00 for ipv6@ietf.org; Thu, 04 Mar 2004 21:06:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az4i7-0004qV-00 for ipv6@ietf.org; Thu, 04 Mar 2004 21:05:12 -0500 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1Az4hR-0004bj-00 for ipv6@ietf.org; Thu, 04 Mar 2004 21:04:29 -0500 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i251uVMm022933 for ; Fri, 5 Mar 2004 09:56:33 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Mar 05 10:04:26 2004 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Mar 2004 10:04:25 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Subject: address selection Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 5 Mar 2004 10:04:25 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205ECCE@bellnet-mail3.sbell.com.cn> Thread-Topic: address selection Thread-Index: AcQCVi8JihtOJDzQQL62I/DJXm7oZA== From: "CTO YAN Renxiang" To: X-OriginalArrivalTime: 05 Mar 2004 02:04:25.0767 (UTC) FILETIME=[2F53A370:01C40256] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, all, A question on RFC3484,"Default addrss Selection for IPv6". Page5 states " IPv6 implementation SHOULD support configurable address = selection via a mechanism .....", but Page6 writes "If an implementation is not configurable or has not = been configured...". So does every IPv6 implementation support configurable addess selection? = How about this mechanism in Microsoft windows2003? Regards, ________________________________ Yan Renxiang Research&Innovation Center, Alcatel Shanghai Bell Co.,Ltd. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 5 01:01:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07524 for ; Fri, 5 Mar 2004 01:01:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8OZ-00052R-8E for ipv6-archive@odin.ietf.org; Fri, 05 Mar 2004 01:01:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2561FHb019367 for ipv6-archive@odin.ietf.org; Fri, 5 Mar 2004 01:01:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8OZ-00052I-1P for ipv6-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 01:01:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07506 for ; Fri, 5 Mar 2004 01:01:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az8OW-0002QW-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 01:01:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az8Nc-0002Fz-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 01:00:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az8Mo-00025b-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 00:59:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8MP-0004ng-MI; Fri, 05 Mar 2004 00:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8Lb-0004lt-Ma for ipv6@optimus.ietf.org; Fri, 05 Mar 2004 00:58:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07375 for ; Fri, 5 Mar 2004 00:58:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az8LY-0001tv-00 for ipv6@ietf.org; Fri, 05 Mar 2004 00:58:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az8Ka-0001js-00 for ipv6@ietf.org; Fri, 05 Mar 2004 00:57:09 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Az8Jb-0001QX-00 for ipv6@ietf.org; Fri, 05 Mar 2004 00:56:07 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 04 Mar 2004 21:59:54 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i255tZxU027245; Fri, 5 Mar 2004 00:55:35 -0500 (EST) Received: from rdroms-w2k01.cisco.com (shinjuku-equant-dynamic2.cisco.com [64.104.42.2]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGN83636; Fri, 5 Mar 2004 00:55:29 -0500 (EST) Message-Id: <4.3.2.7.2.20040304031006.01fdb038@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 05 Mar 2004 00:44:49 -0500 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [rfc2462bis issue 277] M/O flags and DHCPv6 Cc: ipv6@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Comments in line... At 09:31 PM 2/27/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >[...] >*** regarding question c **** > >I'd first like to answer this question. RFC2462 currently says: > > Stateful autoconfiguration for IPv6 is the subject of future work > [DHCPv6]. >(Section 1) > >And, considering the latest standardization status, the current >revision of rfc2462bis says: > > Stateful autoconfiguration for IPv6 is the subject of DHCPv6 [7]. > >However, I still don't think this is crystal clear. I believe we >should first clarify whether "stateful autoconfiguration" *equals to* >DHCPv6 (as specified in RFC3315), or whether we should still leave the >possibility of (future) other stateful protocols. And then we should >clarify this point in rfc2462bis more explicitly. > >Personally, I would prefer the first option (i.e., the "stateful >protocol" equals to DHCPv6). Flexibility is in general a good thing, >but in this case, I don't see a reasonable practical reason to leave >other possibilities with ambiguous wording, particularly because the >ambiguity has annoyed people and caused similar questions/discussions >again and again. > >If we can agree on this, I'll change the above sentence like: > > In this document, Stateful autoconfiguration for IPv6 means DHCPv6 > [7]. > >In the followings, I assume we adopt this interpretation (but it won't >matter much even if we do not). I think it would be more clear to simply replace "the stateful autoconfiguration for IPv6" with "DHCPv6" throughout the document. It might be necessary to append "for address assignment" when discussing the "M" bit and "for other configuration information" when discussing the "O" bit. >*** regarding question a **** > >First, I think we can concentrate on Section 5 "PROTOCOL >SPECIFICATION" (and its subsections). For example, someone pointed >out that the following sentence in section 4 is "ambiguous": > > A "managed address > configuration" flag indicates whether hosts should use stateful > autoconfiguration to obtain addresses. > >because it uses "should", not "SHOULD". I would replace "stateful address autoconfiguration" with "DHCPv6" here. >kBut I don't think we should care about the wording in Section 4, since >it's just an overview of the protocol, not the protocol specification >itself. In fact, there are no RFC2119 keywords throughout Section 4. >Of course, we may have to revisit the wording when we resolve question >b ("which keyword?") though. OK; it makes sense to me that section 4 should use no RFC 2119 words... >Concentrating on Section 5, I've found the following candidates of >RFC2119 keywords: > >====================== start candidates ====================== >1. Section 5.2 > ManagedFlag Copied from the M flag field (i.e., the ... > The flag indicates whether or not addresses are > to be configured using the stateful > autoconfiguration mechanism. > > where "are to be" may need to be, e.g., "SHOULD be". Assuming that everyone is comfortable with the 'M' and 'O' bits being hints and not controls, "SHOULD" seems right. I would replace "stateful autoconfiguration mechanism" with "DHCPv6" (looking ahead, I think this substitution simplifies the next proposed change). >2. Section 5.2 > OtherConfigFlag Copied from the O flag field (i.e., the "other ... > The flag indicates whether or not information > other than addresses is to be obtained using the > stateful autoconfiguration mechanism. > > where "is to be" may need to be, e.g., "SHOULD be". I agree with the change to SHOULD be. I would also replace "stateful autoconfiguration mechanism" with "DHCPv6". I make this suggestion because I think the phrase "stateful autoconfiguration mechanism" was used in RFC 2462 because there was no explicit protocol to point at. That is, I don't think differentiating between "stateful autoconfiguration mechanism" and "DHCPv6" is useful; what is useful is to use 'M' and 'O' bits as hints to the host to use DHCPv6. >3. Section 5.5.3 > > ... If the value of ManagedFlag changes from FALSE to > TRUE, and the host is not already running the stateful address > autoconfiguration protocol, the host should invoke the stateful > address autoconfiguration protocol, ... > > where "the host should invoke" may need to be, e.g., "the host > SHOULD invoke". OK, and change "stateful address autoconfiguration protocol" to "DHCPv6". >4. Section 5.5.3 > > ... If the value of the ManagedFlag > changes from TRUE to FALSE, the host should continue running the > stateful address autoconfiguration, ... > > where "the host should continue" may need to be, e.g., "the host > SHOULD continue". Ditto. >5. Section 5.5.3 > > ... If the > value of OtherConfigFlag changes from FALSE to TRUE, the host should > invoke the stateful autoconfiguration protocol, ... > > where "the host should invoke" may need to be, e.g., "the host > SHOULD invoke". Ditto. >6. Section 5.5.3 > > ... If > the value of the OtherConfigFlag changes from TRUE to FALSE, the host > should continue running the stateful address autoconfiguration > protocol, ... > > where "the host should continue" may need to be, e.g., "the host > SHOULD continue". Ditto. >====================== end candidates ====================== > >In my current impression, we can leave 1 and 2 unchanged, but we'll >need to use RFC2119 keywords for the rest. > >*** regarding question b **** > >In addition to the above candidates, the following parts already using >RFC2119 keywords will need to be discussed here: > >7. Section 5.5.2 > If a link has no routers, a host MUST attempt to use stateful > autoconfiguration to obtain addresses and other configuration > information. > >8. Section 5.5.2 > An implementation MAY provide a way to disable the > invocation of stateful autoconfiguration in this case, but the > default SHOULD be enabled. > >9. Section 5.5.3 > In particular, a host MUST > NOT reinvoke stateful address configuration if it is already > participating in the stateful protocol as a result of an earlier > advertisement. > >10. Section 5.5.3 > In particular, a host MUST NOT reinvoke stateful > configuration if it is already participating in the stateful protocol > as a result of an earlier advertisement. > >To choose appropriate keywords, I'd like to be synchronized with the >node requirements draft (draft-ietf-ipv6-node-requirements-08.txt). >It says in Section 4.5.5 that: > > Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- > 3315] is the standard stateful address configuration protocol; see > section 5.3 for DHCPv6 support. I suggest replacing "Stateless Address Autoconfiguration" with "DHCPv6" in the first sentence. > Nodes which do not support Stateful Address Autoconfiguration may be > unable to obtain any IPv6 addresses aside from link-local addresses > when it receives a router advertisement with the 'M' flag (Managed > address configuration) set and which contains no prefixes advertised > for Stateless Address Autoconfiguration (see section 4.5.2). > ... s/Stateful Address Autoconfiguration/DHCPv6/ throughout this paragraph. >That is (in my understanding), implementing DHCPv6 is basically >optional with warnings about the case of not implementing it. I know >this was a controversial issue, but I believe the node-requirements >draft made a reasonable decision in terms of practical and realistic >deployment path while honoring future flexibility. OK. >So, I'd like to propose changing candidate 7 to: > > If a link has no routers, a host MAY attempt to use stateful > autoconfiguration to obtain addresses and other configuration > information. s/stateful autoconfiguration/DHCPv6/ I don't think RFC 2462 intended to differentiate between stateful and stateless DHCPv6. >Similarly, change candidate 8 to: > An implementation MAY provide a way to enable the > invocation of stateful autoconfiguration in this case, but the > default SHOULD be disabled. > >Another reason for the change is because we can at least use >link-local addresses within a single link without a router. s/stateful autoconfiguration/DHCPv6/ >For candidates 3 to 6, I think "SHOULD" is appropriate, since this >only happens the network manager explicitly turns on the M or O flag >and the effect of this setting is described in the node-requirements >draft with warnings. OK. >I also think "MUST NOT"s in candidates 9 and 10 are okay for the same >reason. OK. >*** regarding question d **** > >(I interpret "the configuration-only version of DHCPv6" as so called >"stateless DHCPv6" described in draft-ietf-dhc-dhcpv6-stateless-04.txt.) > >This is not a strong opinion, but I'd currently say "no" for this >question. The reasons are: > >- in my opinion, the stateless DHCPv6 service should be a "ubiquitous" > service, and hosts that need autoconfiguration should try it by > default (that is, without seeing an O flag set, which needs an > explicit configuration in routers). > >- the O bit indicates a "stateful" mechanism for other configuration > information than addresses. If the information actually includes > some real "other" stateful resources (probably in a future > extension), using the stateless version of DHCPv6 may result in an > incomplete service. We've spent a lot of time discussing "other stateful resources" in the dhc WG. Although the concept sounds sensible, in practice we've never been able to identify an example of a stateful resource to manage with DHCPv6 other than addresses and prefixes. Therefore, I would say we don't need to worry that stateless DHCPv6 won't be adequate for the assignment of other configuration information. >Even if we agree on my opinion, however, it might still be useful to >note that the protocol invoked by the O bit should be the full-spec >DHCPv6 instead of the stateless version. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 5 01:19:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08046 for ; Fri, 5 Mar 2004 01:19:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8fy-0006nX-SI for ipv6-archive@odin.ietf.org; Fri, 05 Mar 2004 01:19:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i256JEUv026125 for ipv6-archive@odin.ietf.org; Fri, 5 Mar 2004 01:19:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8fy-0006nI-Iz for ipv6-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 01:19:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08007 for ; Fri, 5 Mar 2004 01:19:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az8fv-0005Uu-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 01:19:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az8et-0005Jj-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 01:18:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az8dv-00057j-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 01:17:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8dp-0006NF-AB; Fri, 05 Mar 2004 01:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8d2-0006Ll-4p for ipv6@optimus.ietf.org; Fri, 05 Mar 2004 01:16:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07910 for ; Fri, 5 Mar 2004 01:16:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az8cz-0004xm-00 for ipv6@ietf.org; Fri, 05 Mar 2004 01:16:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az8c4-0004nw-00 for ipv6@ietf.org; Fri, 05 Mar 2004 01:15:13 -0500 Received: from [202.108.35.178] (helo=vip.sina.com) by ietf-mx with smtp (Exim 4.12) id 1Az8bW-0004eP-00 for ipv6@ietf.org; Fri, 05 Mar 2004 01:14:42 -0500 Received: (qmail 2642 invoked from network); 5 Mar 2004 06:14:19 -0000 Received: from unknown (HELO SONY) (61.140.216.76) by 202.108.35.178 with SMTP; 5 Mar 2004 06:14:19 -0000 Received: from(hellor@vip.sina.com) to(ipv6@ietf.org) From: "Amy" To: "ipv6@ietf.org" Subject: unsubscription X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Mar 2004 14:14:5 +0800 Message-Id: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_12_24, TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable unsubscript, please. =09 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2 =C0=F1=A3=A1 =09=09=09=09 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Amy =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1hellor@vip.sina.com =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12004-03-05 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 5 11:02:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14683 for ; Fri, 5 Mar 2004 11:02:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHlc-0007IJ-73 for ipv6-archive@odin.ietf.org; Fri, 05 Mar 2004 11:01:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25G1e0P028036 for ipv6-archive@odin.ietf.org; Fri, 5 Mar 2004 11:01:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHlY-0007I7-QI for ipv6-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 11:01:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14634 for ; Fri, 5 Mar 2004 11:01:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzHlW-0000Ev-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 11:01:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzHkX-00003F-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 11:00:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzHjX-0007a5-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 10:59:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHj3-0006aY-Vv; Fri, 05 Mar 2004 10:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHim-0006Zt-6A for ipv6@optimus.ietf.org; Fri, 05 Mar 2004 10:58:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14542 for ; Fri, 5 Mar 2004 10:58:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzHij-0007XE-00 for ipv6@ietf.org; Fri, 05 Mar 2004 10:58:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzHho-0007NM-00 for ipv6@ietf.org; Fri, 05 Mar 2004 10:57:45 -0500 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx with esmtp (Exim 4.12) id 1AzHhN-0007CA-00 for ipv6@ietf.org; Fri, 05 Mar 2004 10:57:17 -0500 Received: from consulintel02 ([211.235.19.99]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 36-md50000000070.tmp for ; Fri, 05 Mar 2004 17:01:41 +0100 Message-ID: <38da01c402cb$1278cda0$c0e625da@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , , References: <0aa201c400b6$4eb2b900$ade325da@consulintel.es> Subject: Re: IPv6 Overall Status document Date: Sat, 6 Mar 2004 01:01:03 +0900 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 05 Mar 2004 17:01:41 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 211.235.19.99 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I forgot to mention something ... We try to keep posted the latest IPv6 news, every day, at = http://www.ist-ipv6.org. You can subscribe to the list with mailto:mdaemon@ist-ipv6.org?subject=3Dsubscribe&BODY=3Dsubscribe = ipv6cluster@ist-ipv6.org. So if you know about anything or have anything to announce, related to = IPv6, please let me know ! By the way, congratulations to our NTT/Verio friends ! (see = http://www.ist-ipv6.org/modules.php?op=3Dmodload&name=3DNews&file=3Dartic= le&sid=3D412). Regards, Jordi PS: Same disclaimer ... this is not an IETF activity, but I guess is = interesting for this group anyway. ----- Original Message -----=20 From: "JORDI PALET MARTINEZ" To: Sent: Wednesday, March 03, 2004 9:27 AM Subject: IPv6 Overall Status document Hi, We have published a new edition of a document that try to collect the = status of the different deployment activities in the world: http://www.ipv6tf-sc.org/html/public/ipv6tf-sc_pu_d3_4v1_3.pdf The document is being updated periodically (next review in 2 months), so = if you have any amendment, updated information, or proposal to add or = change something, please, let me know. Related web sites are http://www.ipv6tf.org, = http://www.ipv6tf.org/europe.php and http://www.eu.ipv6tf.org. Regards, Jordi PS: This is not an IETF activity, but I guess is interesting for this = group anyway. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or = confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or = confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 5 14:38:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24895 for ; Fri, 5 Mar 2004 14:38:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL9A-000645-Sj for ipv6-archive@odin.ietf.org; Fri, 05 Mar 2004 14:38:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25JcCBx023299 for ipv6-archive@odin.ietf.org; Fri, 5 Mar 2004 14:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL99-00063i-Tj for ipv6-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 14:38:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24866 for ; Fri, 5 Mar 2004 14:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzL95-0004pH-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 14:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzL79-0004Hv-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 14:36:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzL5f-0003l5-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 14:34:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzL5b-000684-PL for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 14:34:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL58-00058Z-8y; Fri, 05 Mar 2004 14:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzL4P-00054A-Li for ipv6@optimus.ietf.org; Fri, 05 Mar 2004 14:33:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24477 for ; Fri, 5 Mar 2004 14:33:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzL4L-0003P5-00 for ipv6@ietf.org; Fri, 05 Mar 2004 14:33:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzL2p-0002t2-00 for ipv6@ietf.org; Fri, 05 Mar 2004 14:31:40 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50] helo=smtp.cs.utk.edu) by ietf-mx with esmtp (Exim 4.12) id 1AzL12-0002Jg-00 for ipv6@ietf.org; Fri, 05 Mar 2004 14:29:48 -0500 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id AD5CBAFC03; Fri, 5 Mar 2004 14:29:40 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31398-09; Fri, 5 Mar 2004 14:29:39 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id E5C9EAFB82; Fri, 5 Mar 2004 14:29:38 -0500 (EST) Date: Fri, 5 Mar 2004 14:29:38 -0500 From: Keith Moore To: Brian E Carpenter Cc: moore@cs.utk.edu, Erik.Nordmark@sun.com, Francis.Dupont@enst-bretagne.fr, brian@innovationslab.net, ipv6@ietf.org Subject: Re: Adopt Address Selection API as a WG document? Message-Id: <20040305142938.09785621.moore@cs.utk.edu> In-Reply-To: <40461D35.5D17EE08@zurich.ibm.com> References: <40461D35.5D17EE08@zurich.ibm.com> X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit these choices MUST be made by applications, not by a separate policy mechanism, because some applications cannot work unless the right kind of address is assigned - and the OS cannot be expected to guess what kind of address the application needs. or to put it another way, if the policy is to say "you are not allowed to use a public address" - the proper thing to do is to return an error to the application that requested this kind of address so that it can print a message to the effect "local network policy prevents this application from working here" NOT to give the application an address that doesn't suit its needs. one of the tragedies of NAT was that the policies enforced by NAT are not visible to the applications or users - so the apps get blamed for the problems that the policies (implicit in NAT) cause. we need to not repeat that mistake. so we certainly do need such an API. however it's been too long since I read this draft so I'll stop short of recommending _this_ API until I've managed to reread it. Keith > I don't disagree, and I didn't mean to imply that this is relevant > to multihoming. But in practice I think these choices will be made > by a separate policy mechanism, not by individual applications. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 5 15:05:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26767 for ; Fri, 5 Mar 2004 15:05:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLYz-0005Yr-UU for ipv6-archive@odin.ietf.org; Fri, 05 Mar 2004 15:04:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25K4rub021371 for ipv6-archive@odin.ietf.org; Fri, 5 Mar 2004 15:04:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLYz-0005Yc-OF for ipv6-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 15:04:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26717 for ; Fri, 5 Mar 2004 15:04:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzLYv-0002av-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 15:04:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzLXy-0002Qr-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 15:03:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzLXI-0002HH-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 15:03:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLXE-0003id-1F; Fri, 05 Mar 2004 15:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzLXA-0003eF-07 for ipv6@optimus.ietf.org; Fri, 05 Mar 2004 15:03:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26591 for ; Fri, 5 Mar 2004 15:02:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzLX4-0002Gb-00 for ipv6@ietf.org; Fri, 05 Mar 2004 15:02:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzLWE-000268-00 for ipv6@ietf.org; Fri, 05 Mar 2004 15:02:03 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1AzLVb-0001tC-00 for ipv6@ietf.org; Fri, 05 Mar 2004 15:01:23 -0500 Received: from ssprunk (ip133.post-vineyard.dfw.ygnition.net [66.135.181.133]) by ns2.sea (8.12.11/8.12.5) with SMTP id i25K0lAa022459; Fri, 5 Mar 2004 12:00:51 -0800 Message-ID: <01d701c402ec$8f8964a0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" , "Brian E Carpenter" Cc: References: <40461D35.5D17EE08@zurich.ibm.com> <20040305142938.09785621.moore@cs.utk.edu> Subject: Re: Adopt Address Selection API as a WG document? Date: Fri, 5 Mar 2004 13:59:14 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Some applications MAY prefer one address over another, but most applications will not care. IMHO the best solution is to allow the OS (and therefore presumably the admin) to specify a default policy, but let applications provide "hints" to the OS that other addresses may be better in certain circumstances. Of course, the OS should be free to not select an address if it is so configured. In most cases, a default of preferring any IP address in the same /48 as a destination will work, followed by addresses in the same /8, followed by any globally-reachable address. I'm not convinced that such an API is immediately useful, however, since it seems to assume a prior means of determining which addresses will work at all. Most applications will be faced with a scenario where the source has N addresses, the destination has M addresses, and it won't be clear which of the N*M combinations will work without testing them all. Only when there are multiple _working_ combinations does an address selection policy matter. 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 ----- Original Message ----- From: "Keith Moore" To: "Brian E Carpenter" Cc: ; ; ; ; Sent: Friday, 05 March, 2004 13:29 Subject: Re: Adopt Address Selection API as a WG document? > these choices MUST be made by applications, not by a separate policy > mechanism, because some applications cannot work unless the right kind > of address is assigned - and the OS cannot be expected to guess what > kind of address the application needs. > > or to put it another way, if the policy is to say "you are not allowed > to use a public address" - the proper thing to do is to return an error > to the application that requested this kind of address so that it can > print a message to the effect "local network policy prevents this > application from working here" NOT to give the application an address > that doesn't suit its needs. > > one of the tragedies of NAT was that the policies enforced by NAT are > not visible to the applications or users - so the apps get blamed for > the problems that the policies (implicit in NAT) cause. we need to > not repeat that mistake. > > so we certainly do need such an API. however it's been too long since > I read this draft so I'll stop short of recommending _this_ API until > I've managed to reread it. > > Keith > > > > I don't disagree, and I didn't mean to imply that this is relevant > > to multihoming. But in practice I think these choices will be made > > by a separate policy mechanism, not by individual applications. > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Fri Mar 5 16:57:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01691 for ; Fri, 5 Mar 2004 16:57:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNJO-00038K-CT for ipv6-archive@odin.ietf.org; Fri, 05 Mar 2004 16:56:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25LusQx012042 for ipv6-archive@odin.ietf.org; Fri, 5 Mar 2004 16:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNJN-000389-Vs for ipv6-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 16:56:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01683 for ; Fri, 5 Mar 2004 16:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzNJL-0006P7-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 16:56:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzNIN-0006Ft-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 16:55:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzNI2-00067F-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 16:55:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNHb-0002qP-Oj; Fri, 05 Mar 2004 16:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzNHR-0002pf-Mt for ipv6@optimus.ietf.org; Fri, 05 Mar 2004 16:54:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01629 for ; Fri, 5 Mar 2004 16:54:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzNHP-00066f-00 for ipv6@ietf.org; Fri, 05 Mar 2004 16:54:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzNGW-0005xw-00 for ipv6@ietf.org; Fri, 05 Mar 2004 16:53:56 -0500 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1AzNFt-0005og-00 for ipv6@ietf.org; Fri, 05 Mar 2004 16:53:17 -0500 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=[192.168.0.4]) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AzNFq-0001pM-00; Fri, 05 Mar 2004 13:53:14 -0800 In-Reply-To: <01d701c402ec$8f8964a0$6401a8c0@ssprunk> References: <40461D35.5D17EE08@zurich.ibm.com> <20040305142938.09785621.moore@cs.utk.edu> <01d701c402ec$8f8964a0$6401a8c0@ssprunk> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8BC9370A-6EEF-11D8-87F6-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit Cc: Keith Moore , "Brian E Carpenter" , From: Keith Moore Subject: Re: Adopt Address Selection API as a WG document? Date: Fri, 5 Mar 2004 16:53:32 -0500 To: "Stephen Sprunk" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Some applications MAY prefer one address over another, but most > applications > will not care. IMHO the best solution is to allow the OS (and > therefore > presumably the admin) to specify a default policy, but let applications > provide "hints" to the OS that other addresses may be better in certain > circumstances. no, that's ridiculous. applications need a stable API that works the same from one platform to another, not one that changes at the whim of some network administrator. and we don't need an API that only works for "most applications". > I'm not convinced that such an API is immediately useful, however, > since it > seems to assume a prior means of determining which addresses will work > at > all. Most applications will be faced with a scenario where the source > has N > addresses, the destination has M addresses, and it won't be clear > which of > the N*M combinations will work without testing them all. you're absolutely right about this part. about the only thing the API can reasonably do is let the application specify whether it can use a temporary "privacy" address (as in a web browser) or whether it needs a public address (as in a server or p2p app). it is, and always has been, completely unreasonable to expect either hosts or apps to have to choose between a number of (source,destination) address pairs in order to successfully connect with other hosts. no API can solve that problem. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 5 19:55:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09002 for ; Fri, 5 Mar 2004 19:55:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQ5q-0004y8-GW for ipv6-archive@odin.ietf.org; Fri, 05 Mar 2004 19:55:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i260t6kP019096 for ipv6-archive@odin.ietf.org; Fri, 5 Mar 2004 19:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQ5q-0004xv-AS for ipv6-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 19:55:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08969 for ; Fri, 5 Mar 2004 19:55:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzQ5o-0005Ua-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 19:55:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzQ4v-0005KW-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 19:54:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzQ4K-0005AU-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 19:53:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQ3q-0004T0-Bl; Fri, 05 Mar 2004 19:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQ2y-0004SV-38 for ipv6@optimus.ietf.org; Fri, 05 Mar 2004 19:52:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08866 for ; Fri, 5 Mar 2004 19:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzQ2w-0004za-00 for ipv6@ietf.org; Fri, 05 Mar 2004 19:52:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzQ23-0004pk-00 for ipv6@ietf.org; Fri, 05 Mar 2004 19:51:12 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1AzQ1I-0004TK-00 for ipv6@ietf.org; Fri, 05 Mar 2004 19:50:24 -0500 Received: from ssprunk (ip133.post-vineyard.dfw.ygnition.net [66.135.181.133]) by ns2.sea (8.12.11/8.12.5) with SMTP id i260nigp023930; Fri, 5 Mar 2004 16:49:44 -0800 Message-ID: <02cc01c40314$ed0280d0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" Cc: "Brian E Carpenter" , References: <40461D35.5D17EE08@zurich.ibm.com> <20040305142938.09785621.moore@cs.utk.edu> <01d701c402ec$8f8964a0$6401a8c0@ssprunk> <8BC9370A-6EEF-11D8-87F6-000393DB5366@cs.utk.edu> Subject: Re: Adopt Address Selection API as a WG document? Date: Fri, 5 Mar 2004 18:49:37 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Keith Moore" > > Some applications MAY prefer one address over another, but most > > applications will not care. IMHO the best solution is to allow the OS > > (and therefore presumably the admin) to specify a default policy, but let > > applications provide "hints" to the OS that other addresses may be > > better in certain circumstances. > > no, that's ridiculous. applications need a stable API that works the > same from one platform to another, not one that changes at the whim of > some network administrator. and we don't need an API that only works > for "most applications". The API itself will be stable, it's only the returned value(s) that may change based on exactly where a host lives and how it's configured. There is no way for software alone to determine many of the variables involved in address selection, especially things like security policies. As long as the API returns _something_ usable, it can be considered stable. > > I'm not convinced that such an API is immediately useful, however, > > since it seems to assume a prior means of determining which addresses > > will work at all. Most applications will be faced with a scenario where > > the source has N addresses, the destination has M addresses, and it > > won't be clear which of the N*M combinations will work without > > testing them all. > > you're absolutely right about this part. about the only thing the API > can reasonably do is let the application specify whether it can use a > temporary "privacy" address (as in a web browser) or whether it needs a > public address (as in a server or p2p app). That argument is loaded with flawed assumptions. There are many servers and p2p usage scenarios that would be served just fine by local addresses. For instance, some admins may prefer intra-company communication use local addresses even if global addresses are available, while other admins may prefer the opposite. You won't get far ignoring the "whims" of the person who owns all of the hosts in question. The application writer can't possibly anticipate all ways his code will end up being used, which is why I believe that a per-host policy (hidden behind an API) is the best way to go. > it is, and always has been, completely unreasonable to expect either > hosts or apps to have to choose between a number of > (source,destination) address pairs in order to successfully connect > with other hosts. no API can solve that problem. Not true; it would be fairly trivial to implement an API function that tests all N*M pairs and return the set of pairs which appear to work. This would then be fed into a different API function to determine the "best" pair for the application's needs. 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 exim@www1.ietf.org Fri Mar 5 20:32:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10226 for ; Fri, 5 Mar 2004 20:32:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQfu-0007b1-Nh for ipv6-archive@odin.ietf.org; Fri, 05 Mar 2004 20:32:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i261WM5j029193 for ipv6-archive@odin.ietf.org; Fri, 5 Mar 2004 20:32:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQfu-0007am-I0 for ipv6-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 20:32:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10170 for ; Fri, 5 Mar 2004 20:32:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzQfs-0003nn-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 20:32:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzQev-0003bJ-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 20:31:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzQeC-0003Pk-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 20:30:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQdf-00078q-VR; Fri, 05 Mar 2004 20:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQcs-00071I-0v for ipv6@optimus.ietf.org; Fri, 05 Mar 2004 20:29:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09945 for ; Fri, 5 Mar 2004 20:29:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzQcp-0003Ab-00 for ipv6@ietf.org; Fri, 05 Mar 2004 20:29:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzQbr-0002yY-00 for ipv6@ietf.org; Fri, 05 Mar 2004 20:28:12 -0500 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 1AzQau-0002dv-00 for ipv6@ietf.org; Fri, 05 Mar 2004 20:27:12 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i261QZ5w343614; Fri, 5 Mar 2004 20:26:35 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-203-242.mts.ibm.com [9.65.203.242]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i261QXgU153496; Fri, 5 Mar 2004 18:26:34 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i261OKH03929; Sat, 6 Mar 2004 10:24:20 +0900 Message-Id: <200403060124.i261OKH03929@cichlid.raleigh.ibm.com> To: Alain Durand cc: Brian Haberman , IETF IPv6 Mailing List , Margaret Wasserman , "'Bob Hinden'" Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" In-Reply-To: Message from Alain.Durand@Sun.COM of "Fri, 27 Feb 2004 22:46:33 PST." Date: Sat, 06 Mar 2004 10:24:20 +0900 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Alain Durand writes: > On Feb 27, 2004, at 5:23 PM, Thomas Narten wrote: > > > > Let me ask you this then. If the word "permanent" is not appropriate, > > what word is? To me, "not permanent" means that at some future time an > > allocation that has been made to an endsite may be revoked. > The point I'm arguing is that it is not the IETF business to decide > this. I respectfully disagree. Seems to me that whether or not assignment should be permanent is a property of the type of address we are defining and goes to heart of why we are defining unique local addresses. My understanding is that end sites are supposed to be able to use them however they see fit, and specifically will _not_ have to worry about someone reclaiming them or taking them away. If an end site has to worry that it may have to give up the address at some future time, these addresses have just become a lot less attractive (or useful). Thus, it is important that the assignments effectively be permanent. > So not saying anything is probably the best option. Another one is > saying that the entity in charge of the allocation is required to > provide those allocation for the long term and not specify anything > further. It is a policy decision made by the entity(ies) in charge > to decide what long term means. Letting the entity that operates this service decide the terms of the address (how long an assignment is good for, under what terms it should be reclaimned, etc.) without any sort of guidance is a recipe for creating a bad situation that we cannot fix. I.e., we get a service that isn't what this WG intended and that we can't fix it because we don't control it (e.g., in a worst case scenario, a newly created monopoly accountable to nobody). > See the contract between the chosen entity and the customer. > Again, this is policy, not protocol. i.e. this is not IETF business. Are you really suggesting that some third party (not under IETF direction) define the policy, even if the result of the policy could defeat the purpose of having such addresses? > > Is > > there some future scenario we're worried about where it becomes > > important to be able to reclaim these addresses? I.e., are they ever > > going to become a scarce resource? > I'm worried about the scenario where IETF does policy and not protocols > anymore. I believe you are confusing properties with policy. One can't completely separate the two. If you look at CIDR, we've moved to address leasing because we don't know (technically) how to do global routing if all address assignments are permanent. In the case of unique local addresses, there are no technical issues with making such assignments permanent (or do you disagree?). Thus, there is no reason why we can't make such assignments permanent. (Note: I'd agree with you that the assignments shouldn't be permanent if there was a case to be made that it may become necessary to reclaim them at some future time. Is there?) Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 5 20:51:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11008 for ; Fri, 5 Mar 2004 20:51:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQyG-00011a-HN for ipv6-archive@odin.ietf.org; Fri, 05 Mar 2004 20:51:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i261pKNj003932 for ipv6-archive@odin.ietf.org; Fri, 5 Mar 2004 20:51:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQyG-00011L-B6 for ipv6-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 20:51:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10989 for ; Fri, 5 Mar 2004 20:51:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzQyE-0007E4-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 20:51:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzQx6-00071z-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 20:50:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzQwI-0006rz-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 20:49:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQw2-0000Yn-4i; Fri, 05 Mar 2004 20:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzQv5-0000Y8-3r for ipv6@optimus.ietf.org; Fri, 05 Mar 2004 20:48:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10811 for ; Fri, 5 Mar 2004 20:48:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzQv2-0006fe-00 for ipv6@ietf.org; Fri, 05 Mar 2004 20:48:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzQu6-0006T7-00 for ipv6@ietf.org; Fri, 05 Mar 2004 20:47:03 -0500 Received: from snipe.mail.pas.earthlink.net ([207.217.120.62]) by ietf-mx with esmtp (Exim 4.12) id 1AzQtF-0006Iz-00 for ipv6@ietf.org; Fri, 05 Mar 2004 20:46:09 -0500 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=[192.168.0.4]) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AzQtC-0002Y5-00; Fri, 05 Mar 2004 17:46:06 -0800 In-Reply-To: <02cc01c40314$ed0280d0$6401a8c0@ssprunk> References: <40461D35.5D17EE08@zurich.ibm.com> <20040305142938.09785621.moore@cs.utk.edu> <01d701c402ec$8f8964a0$6401a8c0@ssprunk> <8BC9370A-6EEF-11D8-87F6-000393DB5366@cs.utk.edu> <02cc01c40314$ed0280d0$6401a8c0@ssprunk> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13F3D4A0-6F10-11D8-87F6-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit Cc: Keith Moore , "Brian E Carpenter" , From: Keith Moore Subject: Re: Adopt Address Selection API as a WG document? Date: Fri, 5 Mar 2004 20:46:25 -0500 To: "Stephen Sprunk" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> applications need a stable API that works the >> same from one platform to another, not one that changes at the whim of >> some network administrator. and we don't need an API that only works >> for "most applications". > > The API itself will be stable, it's only the returned value(s) that may > change based on exactly where a host lives and how it's configured. that's not a stable API, that's an API that behaves differently in different environments - and the differences are sufficient to break applications. it's simply not acceptable to give applications temporary addresses when they need stable addresses. if an app says it needs a stable address, then the API MUST either comply or return an error. > There is no way for software alone to determine many of the variables > involved in > address selection, especially things like security policies. which is why having security policies that expect hosts or apps being able to select addresses is a complete crock, and we should not be endorsing such brain-damage. > As long as the > API returns _something_ usable, it can be considered stable. what is "usable" varies from one application to another. perhaps I misunderstand you but you seem to be proposing a model where the app should be happy with whatever it gets, no matter how dysfunctional. as NATs have aptly demonstrated, it's completely unreasonable to expect many kinds of apps to function in that kind of environment. >>> I'm not convinced that such an API is immediately useful, however, >>> since it seems to assume a prior means of determining which addresses >>> will work at all. Most applications will be faced with a scenario >>> where >>> the source has N addresses, the destination has M addresses, and it >>> won't be clear which of the N*M combinations will work without >>> testing them all. >> >> you're absolutely right about this part. about the only thing the API >> can reasonably do is let the application specify whether it can use a >> temporary "privacy" address (as in a web browser) or whether it needs >> a >> public address (as in a server or p2p app). > > That argument is loaded with flawed assumptions. There are many > servers and > p2p usage scenarios that would be served just fine by local addresses. in other words, the app _might_ just happen to work if the cards fall right. that's not a model that app writers can work with. people expect apps to work no matter where they're plugged in, and expecting customers to guess whether the problem is in the app or in the network configuration is not an acceptable means of operation. > For instance, some admins may prefer intra-company communication use > local > addresses even if global addresses are available, while other admins > may > prefer the opposite. You won't get far ignoring the "whims" of the > person > who owns all of the hosts in question. sounds like the Golgafrincham Ark B. "what if they want fire that is nasally fitted?" yes, network admins will do whatever they want, no matter how stupid it is. our task is to define how the network operates in such a way that a) network admins can define reasonable policies, AND b) apps can function as long as policies permit, AND c) if the app breaks because of a conflict with policy, it's obvious that this is why the app breaks our task is NOT to let the network admin do whatever the hell he wants and expect the app to be able to function in the presence of arbitrary brain damage > The application writer can't possibly anticipate all ways his code > will end > up being used, which is why I believe that a per-host policy (hidden > behind > an API) is the best way to go. no, that's why giving applications a reasonably consistent view of the network independent of location is the only way to go. there is absolutely no point to deploying IPv6 if it's going to be as brain-damaged as IPv4+NAT from day one. it will only get worse from there. >> it is, and always has been, completely unreasonable to expect either >> hosts or apps to have to choose between a number of >> (source,destination) address pairs in order to successfully connect >> with other hosts. no API can solve that problem. > > Not true; it would be fairly trivial to implement an API function that > tests > all N*M pairs and return the set of pairs which appear to work. it would be trivial to implement, and unacceptably slow and unreliable. and yes, I've written the code and tried it out. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Mar 6 01:52:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21981 for ; Sat, 6 Mar 2004 01:52:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzVfb-000595-Dh for ipv6-archive@odin.ietf.org; Sat, 06 Mar 2004 01:52:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i266qNbI019773 for ipv6-archive@odin.ietf.org; Sat, 6 Mar 2004 01:52:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzVfa-00058q-TI for ipv6-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 01:52:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21975 for ; Sat, 6 Mar 2004 01:52:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzVfX-0003Tf-00 for ipv6-web-archive@ietf.org; Sat, 06 Mar 2004 01:52:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzVed-0003Jy-00 for ipv6-web-archive@ietf.org; Sat, 06 Mar 2004 01:51:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzVdt-0003AU-00 for ipv6-web-archive@ietf.org; Sat, 06 Mar 2004 01:50:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzVdL-0004oa-JQ; Sat, 06 Mar 2004 01:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzVcX-0004jy-RB for ipv6@optimus.ietf.org; Sat, 06 Mar 2004 01:49:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21866 for ; Sat, 6 Mar 2004 01:49:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzVcU-0002yz-00 for ipv6@ietf.org; Sat, 06 Mar 2004 01:49:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzVbW-0002pI-00 for ipv6@ietf.org; Sat, 06 Mar 2004 01:48:11 -0500 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1AzVaV-0002aj-00 for ipv6@ietf.org; Sat, 06 Mar 2004 01:47:07 -0500 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=[192.168.0.4]) by mallard.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AzVaP-0004Nn-00; Fri, 05 Mar 2004 22:47:02 -0800 In-Reply-To: <030b01c40333$543a9f80$6401a8c0@ssprunk> References: <40461D35.5D17EE08@zurich.ibm.com> <20040305142938.09785621.moore@cs.utk.edu> <01d701c402ec$8f8964a0$6401a8c0@ssprunk> <8BC9370A-6EEF-11D8-87F6-000393DB5366@cs.utk.edu> <02cc01c40314$ed0280d0$6401a8c0@ssprunk> <13F3D4A0-6F10-11D8-87F6-000393DB5366@cs.utk.edu> <030b01c40333$543a9f80$6401a8c0@ssprunk> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1B558F56-6F3A-11D8-87F6-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit Cc: Keith Moore , "Brian E Carpenter" , From: Keith Moore Subject: Re: Adopt Address Selection API as a WG document? Date: Sat, 6 Mar 2004 01:47:16 -0500 To: "Stephen Sprunk" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> that's not a stable API, that's an API that behaves differently in >> different environments - and the differences are sufficient to break >> applications. it's simply not acceptable to give applications >> temporary addresses when they need stable addresses. if an app says >> it >> needs a stable address, then the API MUST either comply or return an >> error. > > I'm not proposing that the API return something that conflicts with the > app's requirements. I'm saying if there are multiple valid > possibilities, > which one the API returns may vary according to site-specific policies. if the app says "I can accept either of these kinds of addresses", then it's perfectly acceptable for the API to return either of those kinds of addresses. whether it's a good idea to encourage sites to use address selection as a means of policy enforcement is a separate question. IMHO this is not sound architecture. but that's a separate question from the API. > I'm also saying that what requirements an app is allowed to specify > needs a lot of study so that programmers don't accidentally disallow > valid return values. I agree that it's hard to get the specification right, though I think part of the answer is to encourage programmers to specify functional behavior rather than specific prefix types. >>> There is no way for software alone to determine many of the variables >>> involved in address selection, especially things like security >>> policies. >> >> which is why having security policies that expect hosts or apps being >> able to select addresses is a complete crock, and we should not be >> endorsing such brain-damage. > > I meant the application can't statically determine what a site's > policy will > be; that doesn't mean the API can't determine it via some sort of > configuration. the more I think about it the clearer it becomes that specifying application policy at the network level is like trying to make fine furniture with a chainsaw - it's the wrong tool for the job. so the API that the app uses to deal with the network is not the right place to inform the app about policy. however, having the API inform the app when there's a conflict between what the app requested and what the API/host/network is able to do means that the app can provide a clear error message, and that' s extremely valuable. > >>>>> I'm not convinced that such an API is immediately useful, however, >>>>> since it seems to assume a prior means of determining which >>>>> addresses >>>>> will work at all. Most applications will be faced with a scenario >>>>> where the source has N addresses, the destination has M addresses, >>>>> and it won't be clear which of the N*M combinations will work >>>>> without testing them all. >>>> >>>> you're absolutely right about this part. about the only thing the >>>> API >>>> can reasonably do is let the application specify whether it can use >>>> a >>>> temporary "privacy" address (as in a web browser) or whether it >>>> needs >>>> a public address (as in a server or p2p app). >>> >>> That argument is loaded with flawed assumptions. There are many >>> servers and p2p usage scenarios that would be served just fine by >>> local addresses. >> >> in other words, the app _might_ just happen to work if the cards fall >> right. that's not a model that app writers can work with. people >> expect apps to work no matter where they're plugged in, and expecting >> customers to guess whether the problem is in the app or in the network >> configuration is not an acceptable means of operation. > > Instead, you propose that apps fail because they make questionable > assumptions about what is acceptable. the app writer knows what his app needs from the network. if the network doesn't provide what the app needs, the app is likely to fail. maybe it won't fail every single time it is used, but it won't be reliable. > I, as a user, want my apps to at > least _attempt_ to work instead of giving up because the address set > on my > machine (or the policy I created) doesn't live up to the app's > expectations. we _really_ need to get over the idea that sites should use address selection as a means of setting policy. > "Needs a global address" is an inherently flawed expectation; "needs an > address which can reach a given address" is not. there are apps that need global addresses in order to function properly. there are other apps which need addresses that are reachable by an arbitrary number of hosts which might be participating in the application now or at sometime in the future (though they don't need to be global). other apps only need pairwise reachability. >>> >> ... >> our task is to define how the network operates in such a way that >> >> a) network admins can define reasonable policies, AND >> b) apps can function as long as policies permit, AND >> c) if the app breaks because of a conflict with policy, it's obvious >> that this is why the app breaks >> >> our task is NOT to let the network admin do whatever the hell he wants >> and expect the app to be able to function in the presence of arbitrary >> brain damage > > I never suggested that; I gave a simple case of two mutually exclusive > local > policies which are both perfectly reasonable, but would cause apps to > needlessly fail if they make unfounded static assumptions. it's not "perfectly reasonable" for local policies to expect apps to vary how they choose addresses from one site to the next. >>> The application writer can't possibly anticipate all ways his code >>> will end up being used, which is why I believe that a per-host policy >>> (hidden behind an API) is the best way to go. >> >> no, that's why giving applications a reasonably consistent view of the >> network independent of location is the only way to go. > > There is no consistent view of the network independent of location. > Not all > addresses can reach all other addresses, and that is something we all > need > to live with. true. but if for whatever reason the network cannot or is prohibited from routing traffic between two points, it needs to be clear that it's not the app's job to do so. expecting the app to be aware of network topology, local policy, or whatever is not reasonable. > In particular, it is not guaranteed that "global" addresses' > reachability is > superior to that of "local" addresses; that depends on where you're > located. there are conditions where a local address will be bound to a host longer than a global address, and it's certainly desirable for apps to be able to identify those conditions and to use local addresses in those cases when they are otherwise consistent with the app's needs (not under all conditions). OTOH, if a network doesn't know how to route its own global addresses (while they're still associated with that network), it's thoroughly broken and we shouldn't expect apps to compensate for that. >> there is absolutely no point to deploying IPv6 if it's going to be as >> brain-damaged as IPv4+NAT from day one. it will only get worse from >> there. > > NAT is hopefully out, but firewalls are here to stay. I agree. but having filtering in the network, and expecting apps or hosts to do address selection, are two different things. >>>> it is, and always has been, completely unreasonable to expect either >>>> hosts or apps to have to choose between a number of >>>> (source,destination) address pairs in order to successfully connect >>>> with other hosts. no API can solve that problem. >>> >>> Not true; it would be fairly trivial to implement an API function >>> that >>> tests all N*M pairs and return the set of pairs which appear to work. >> >> it would be trivial to implement, and unacceptably slow and >> unreliable. >> and yes, I've written the code and tried it out. > > For reasonable values of N and M it can be done in a fraction of a > second. that's simply incorrect. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Mar 6 05:25:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11684 for ; Sat, 6 Mar 2004 05:25:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzYyw-0000kP-Bn for ipv6-archive@odin.ietf.org; Sat, 06 Mar 2004 05:24:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26AOYvk002872 for ipv6-archive@odin.ietf.org; Sat, 6 Mar 2004 05:24:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzYyv-0000kF-SM for ipv6-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 05:24:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11624 for ; Sat, 6 Mar 2004 05:24:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzYys-0006U2-00 for ipv6-web-archive@ietf.org; Sat, 06 Mar 2004 05:24:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzYxt-0006Hy-00 for ipv6-web-archive@ietf.org; Sat, 06 Mar 2004 05:23:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzYx1-000682-00 for ipv6-web-archive@ietf.org; Sat, 06 Mar 2004 05:22:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzYwT-0000QM-DM; Sat, 06 Mar 2004 05:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzYvp-0000PY-Sw for ipv6@optimus.ietf.org; Sat, 06 Mar 2004 05:21:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11445 for ; Sat, 6 Mar 2004 05:21:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzYvm-0005u4-00 for ipv6@ietf.org; Sat, 06 Mar 2004 05:21:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzYuo-0005kY-00 for ipv6@ietf.org; Sat, 06 Mar 2004 05:20:19 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1AzYtn-0005VB-00 for ipv6@ietf.org; Sat, 06 Mar 2004 05:19:15 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i26AIVJW111992; Sat, 6 Mar 2004 10:18:32 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i26AIWtd277598; Sat, 6 Mar 2004 11:18:32 +0100 Received: from zurich.ibm.com (sig-9-145-225-58.de.ibm.com [9.145.225.58]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA25068; Sat, 6 Mar 2004 11:18:23 +0100 Message-ID: <4049A58F.AD50A6B2@zurich.ibm.com> Date: Sat, 06 Mar 2004 11:18:55 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Thomas Narten CC: Alain Durand , Brian Haberman , IETF IPv6 Mailing List , Margaret Wasserman , "'Bob Hinden'" Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" References: <200403060124.i261OKH03929@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In my opinion, Thomas is correct. This is a technical choice, not a "policy" choice, and well within the IETF's competence. (Speaking as co-drafter and co-signer of RFC 2860, among other things.) Brian Thomas Narten wrote: > > Alain Durand writes: > > > On Feb 27, 2004, at 5:23 PM, Thomas Narten wrote: > > > > > > Let me ask you this then. If the word "permanent" is not appropriate, > > > what word is? To me, "not permanent" means that at some future time an > > > allocation that has been made to an endsite may be revoked. > > > The point I'm arguing is that it is not the IETF business to decide > > this. > > I respectfully disagree. Seems to me that whether or not assignment > should be permanent is a property of the type of address we are > defining and goes to heart of why we are defining unique local > addresses. My understanding is that end sites are supposed to be able > to use them however they see fit, and specifically will _not_ have to > worry about someone reclaiming them or taking them away. If an end > site has to worry that it may have to give up the address at some > future time, these addresses have just become a lot less attractive > (or useful). Thus, it is important that the assignments effectively > be permanent. > > > So not saying anything is probably the best option. Another one is > > saying that the entity in charge of the allocation is required to > > provide those allocation for the long term and not specify anything > > further. It is a policy decision made by the entity(ies) in charge > > to decide what long term means. > > Letting the entity that operates this service decide the terms of the > address (how long an assignment is good for, under what terms it > should be reclaimned, etc.) without any sort of guidance is a recipe > for creating a bad situation that we cannot fix. I.e., we get a > service that isn't what this WG intended and that we can't fix it > because we don't control it (e.g., in a worst case scenario, a newly > created monopoly accountable to nobody). > > > See the contract between the chosen entity and the customer. > > Again, this is policy, not protocol. i.e. this is not IETF business. > > Are you really suggesting that some third party (not under IETF > direction) define the policy, even if the result of the policy could > defeat the purpose of having such addresses? > > > > Is > > > there some future scenario we're worried about where it becomes > > > important to be able to reclaim these addresses? I.e., are they ever > > > going to become a scarce resource? > > > I'm worried about the scenario where IETF does policy and not protocols > > anymore. > > I believe you are confusing properties with policy. One can't > completely separate the two. If you look at CIDR, we've moved to > address leasing because we don't know (technically) how to do global > routing if all address assignments are permanent. In the case of > unique local addresses, there are no technical issues with making such > assignments permanent (or do you disagree?). Thus, there is no reason > why we can't make such assignments permanent. (Note: I'd agree with > you that the assignments shouldn't be permanent if there was a case to > be made that it may become necessary to reclaim them at some future > time. Is there?) > > Thomas > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Sun Mar 7 00:07:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19590 for ; Sun, 7 Mar 2004 00:07:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzqVO-0004SP-I7 for ipv6-archive@odin.ietf.org; Sun, 07 Mar 2004 00:07:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2757EFv017127 for ipv6-archive@odin.ietf.org; Sun, 7 Mar 2004 00:07:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzqVO-0004S7-7m for ipv6-web-archive@optimus.ietf.org; Sun, 07 Mar 2004 00:07:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19584 for ; Sun, 7 Mar 2004 00:07:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzqVM-0005Xo-00 for ipv6-web-archive@ietf.org; Sun, 07 Mar 2004 00:07:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzqUS-0005P4-00 for ipv6-web-archive@ietf.org; Sun, 07 Mar 2004 00:06:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzqTZ-0005Fk-00 for ipv6-web-archive@ietf.org; Sun, 07 Mar 2004 00:05:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzqSI-00040i-2K; Sun, 07 Mar 2004 00:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzqRZ-0003zz-NN for ipv6@optimus.ietf.org; Sun, 07 Mar 2004 00:03:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19443 for ; Sun, 7 Mar 2004 00:03:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzqRX-0004yW-00 for ipv6@ietf.org; Sun, 07 Mar 2004 00:03:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzqQW-0004k1-00 for ipv6@ietf.org; Sun, 07 Mar 2004 00:02:13 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1AzqPC-0004Yb-00 for ipv6@ietf.org; Sun, 07 Mar 2004 00:00:50 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id AD9675E2 for ; Sun, 7 Mar 2004 00:00:20 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 07 Mar 2004 00:00:20 -0500 Message-Id: <20040307050020.AD9675E2@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.56% | 21 | 15.43% | 110084 | jinmei@isl.rdc.toshiba.co.jp 9.63% | 13 | 8.63% | 61564 | pekkas@netcore.fi 8.15% | 11 | 7.24% | 51671 | kempf@docomolabs-usa.com 5.19% | 7 | 7.60% | 54252 | brian@innovationslab.net 4.44% | 6 | 4.55% | 32455 | john.loughney@nokia.com 4.44% | 6 | 4.47% | 31914 | dthaler@windows.microsoft.com 4.44% | 6 | 3.17% | 22646 | erik.nordmark@sun.com 3.70% | 5 | 3.80% | 27111 | cliu@netscreen.com 2.96% | 4 | 4.01% | 28637 | rdroms@cisco.com 2.96% | 4 | 3.98% | 28396 | moore@cs.utk.edu 2.96% | 4 | 3.56% | 25387 | stephen@sprunk.org 2.96% | 4 | 2.39% | 17081 | greg.daley@eng.monash.edu.au 2.22% | 3 | 2.34% | 16723 | brc@zurich.ibm.com 2.22% | 3 | 2.26% | 16125 | bob.hinden@nokia.com 2.22% | 3 | 2.25% | 16041 | osprey67@yahoo.com 2.22% | 3 | 2.03% | 14502 | satapati@cisco.com 1.48% | 2 | 1.38% | 9853 | yoshfuji@linux-ipv6.org 1.48% | 2 | 1.37% | 9805 | mika.liljeberg@welho.com 1.48% | 2 | 1.37% | 9765 | huitema@windows.microsoft.com 1.48% | 2 | 1.31% | 9377 | tjc@ecs.soton.ac.uk 1.48% | 2 | 1.22% | 8698 | jari.arkko@kolumbus.fi 1.48% | 2 | 1.20% | 8595 | pekka.nikander@nomadiclab.com 1.48% | 2 | 1.19% | 8511 | sharkey@zoic.org 1.48% | 2 | 0.89% | 6358 | yasuhiro@nttv6.jp 0.74% | 1 | 1.27% | 9056 | suresh.krishnan@ericsson.com 0.74% | 1 | 1.20% | 8540 | volz@metrocast.net 0.74% | 1 | 0.90% | 6434 | narten@us.ibm.com 0.74% | 1 | 0.89% | 6378 | rfc-editor@rfc-editor.org 0.74% | 1 | 0.89% | 6331 | jordi.palet@consulintel.es 0.74% | 1 | 0.81% | 5800 | h.soliman@flarion.com 0.74% | 1 | 0.80% | 5715 | vnuorval@tcs.hut.fi 0.74% | 1 | 0.70% | 4986 | fnumber@msn.com 0.74% | 1 | 0.70% | 4967 | jeroen@unfix.org 0.74% | 1 | 0.69% | 4933 | mohacsi@niif.hu 0.74% | 1 | 0.65% | 4668 | sra+ipng@hactrn.net 0.74% | 1 | 0.64% | 4561 | jyrki.soini@teliasonera.com 0.74% | 1 | 0.63% | 4464 | mkshin@pec.etri.re.kr 0.74% | 1 | 0.54% | 3838 | francis.dupont@enst-bretagne.fr 0.74% | 1 | 0.54% | 3821 | renxiang.yan@alcatel-sbell.com.cn 0.74% | 1 | 0.49% | 3481 | mailman-owner@www1.ietf.org --------+------+--------+----------+------------------------ 100.00% | 135 |100.00% | 713524 | 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 exim@www1.ietf.org Sun Mar 7 14:55:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02405 for ; Sun, 7 Mar 2004 14:55:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B04ML-0004ju-PI for ipv6-archive@odin.ietf.org; Sun, 07 Mar 2004 14:54:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i27JsnQf018214 for ipv6-archive@odin.ietf.org; Sun, 7 Mar 2004 14:54:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B04ML-0004jf-Hh for ipv6-web-archive@optimus.ietf.org; Sun, 07 Mar 2004 14:54:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02396 for ; Sun, 7 Mar 2004 14:54:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B04MI-0006D6-00 for ipv6-web-archive@ietf.org; Sun, 07 Mar 2004 14:54:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B04LP-00065Y-00 for ipv6-web-archive@ietf.org; Sun, 07 Mar 2004 14:53:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B04KP-0005xi-00 for ipv6-web-archive@ietf.org; Sun, 07 Mar 2004 14:52:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B04Jd-0004PV-IC; Sun, 07 Mar 2004 14:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B04JU-0004PD-FJ for ipv6@optimus.ietf.org; Sun, 07 Mar 2004 14:51:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02320 for ; Sun, 7 Mar 2004 14:51:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B04JR-0005oo-00 for ipv6@ietf.org; Sun, 07 Mar 2004 14:51:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B04IU-0005hk-00 for ipv6@ietf.org; Sun, 07 Mar 2004 14:50:51 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1B04IE-0005Z6-00 for ipv6@ietf.org; Sun, 07 Mar 2004 14:50:34 -0500 Received: from ssprunk (ip133.post-vineyard.dfw.ygnition.net [66.135.181.133]) by ns2.sea (8.12.11/8.12.5) with SMTP id i27Jnl9Z003105; Sun, 7 Mar 2004 11:49:51 -0800 Message-ID: <011401c4047d$5d2bef40$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" Cc: "Brian E Carpenter" , References: <40461D35.5D17EE08@zurich.ibm.com> <20040305142938.09785621.moore@cs.utk.edu> <01d701c402ec$8f8964a0$6401a8c0@ssprunk> <8BC9370A-6EEF-11D8-87F6-000393DB5366@cs.utk.edu> <02cc01c40314$ed0280d0$6401a8c0@ssprunk> <13F3D4A0-6F10-11D8-87F6-000393DB5366@cs.utk.edu> <030b01c40333$543a9f80$6401a8c0@ssprunk> <1B558F56-6F3A-11D8-87F6-000393DB5366@cs.utk.edu> Subject: Re: Adopt Address Selection API as a WG document? Date: Sun, 7 Mar 2004 13:49:03 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Keith Moore" > >> that's not a stable API, that's an API that behaves differently in > >> different environments - and the differences are sufficient to break > >> applications. it's simply not acceptable to give applications > >> temporary addresses when they need stable addresses. if an app says > >> it > >> needs a stable address, then the API MUST either comply or return an > >> error. > > > > I'm not proposing that the API return something that conflicts with the > > app's requirements. I'm saying if there are multiple valid > > possibilities, > > which one the API returns may vary according to site-specific policies. > > if the app says "I can accept either of these kinds of addresses", then > it's perfectly acceptable for the API to return either of those kinds > of addresses. ... > > > I'm also saying that what requirements an app is allowed to specify > > needs a lot of study so that programmers don't accidentally disallow > > valid return values. > > I agree that it's hard to get the specification right, though I think > part of the answer is to encourage programmers to specify functional > behavior rather than specific prefix types. I think we're in violent agreement on the above points. > whether it's a good idea to encourage sites to use address selection as > a means of policy enforcement is a separate question. IMHO this is not > sound architecture. but that's a separate question from the API. I'm not convinced it's sound either, but I can't figure out a more straightforward way of implementing the types of policies I hear customers ask for. > > I meant the application can't statically determine what a site's policy > > will be; that doesn't mean the API can't determine it via some sort of > > configuration. > > the more I think about it the clearer it becomes that specifying > application policy at the network level is like trying to make fine > furniture with a chainsaw - it's the wrong tool for the job. so the > API that the app uses to deal with the network is not the right place > to inform the app about policy. I don't think the app needs to be aware of policy if it's hidden behind the API -- presumably the policy will be configured and implemented in the OS or some system library. As long as the app can specify what behavior it needs and the policy is able to find a valid address, the app can stay oblivious. > however, having the API inform the app when there's a conflict between > what the app requested and what the API/host/network is able to do > means that the app can provide a clear error message, and that's > extremely valuable. Agreed. > >>>>> I'm not convinced that such an API is immediately useful, however, > >>>>> since it seems to assume a prior means of determining which > >>>>> addresses > >>>>> will work at all. Most applications will be faced with a scenario > >>>>> where the source has N addresses, the destination has M addresses, > >>>>> and it won't be clear which of the N*M combinations will work > >>>>> without testing them all. > >>>> > >>>> you're absolutely right about this part. about the only thing the > >>>> API > >>>> can reasonably do is let the application specify whether it can use > >>>> a > >>>> temporary "privacy" address (as in a web browser) or whether it > >>>> needs > >>>> a public address (as in a server or p2p app). > >>> > >>> That argument is loaded with flawed assumptions. There are many > >>> servers and p2p usage scenarios that would be served just fine by > >>> local addresses. > >> > >> in other words, the app _might_ just happen to work if the cards fall > >> right. that's not a model that app writers can work with. people > >> expect apps to work no matter where they're plugged in, and expecting > >> customers to guess whether the problem is in the app or in the network > >> configuration is not an acceptable means of operation. > > > > Instead, you propose that apps fail because they make questionable > > assumptions about what is acceptable. > > the app writer knows what his app needs from the network. if the > network doesn't provide what the app needs, the app is likely to fail. > maybe it won't fail every single time it is used, but it won't be > reliable. Even if the API were to return what the app asks for (e.g. a global address), there are still a large number of cases where that address still won't work because of firewalls or other necessary evils. On a slightly different note, there may be many servers or p2p apps with only local addresses available because that is the administrator's intent. Having these apps fail because no global address is available doesn't make sense, even if it does print a friendly error on the screen. This case is only marginally different than one where a global address is available but the administrator doesn't want it used for local communication. > > "Needs a global address" is an inherently flawed expectation; "needs an > > address which can reach a given address" is not. > > there are apps that need global addresses in order to function > properly. there are other apps which need addresses that are > reachable by an arbitrary number of hosts which might be participating > in the application now or at sometime in the future (though they don't > need to be global). other apps only need pairwise reachability. "Function properly" and "reachable by an arbitrary number of hosts" are both flawed in the presence of firewalls anyhow. It is well within an administrator's right to block such applications from leaving the local network, and in that case a local address becomes superior to a global one due to stability. > > I never suggested that; I gave a simple case of two mutually exclusive > > local policies which are both perfectly reasonable, but would cause apps > > to needlessly fail if they make unfounded static assumptions. > > it's not "perfectly reasonable" for local policies to expect apps to > vary how they choose addresses from one site to the next. That's the whole point of providing an API -- the app just specifies its requirements and which available address is returned (if any) will implicitly vary between sites. > > There is no consistent view of the network independent of location. > > Not all addresses can reach all other addresses, and that is something > > we all need to live with. > > true. but if for whatever reason the network cannot or is prohibited > from routing traffic between two points, it needs to be clear that it's > not the app's job to do so. expecting the app to be aware of network > topology, local policy, or whatever is not reasonable. Right. But I argue it's reasonable to allow an administrator to configure hosts with local policies, which the apps transparently inherit. > > In particular, it is not guaranteed that "global" addresses' > > reachability is > > superior to that of "local" addresses; that depends on where you're > > located. > > there are conditions where a local address will be bound to a host > longer than a global address, and it's certainly desirable for apps to > be able to identify those conditions and to use local addresses in > those cases when they are otherwise consistent with the app's needs > (not under all conditions). > > OTOH, if a network doesn't know how to route its own global addresses > (while they're still associated with that network), it's thoroughly > broken and we shouldn't expect apps to compensate for that. An "obvious" security scheme for corporate networks is to block all packets with local addresses at the firewall (as specified in the I-D) and then block access to server farms from non-local addresses (in case there's a leak or misconfiguration at the firewall, and to simplify configuration and auditing). Since the servers inside that farm will only have local addresses themselves, it is logical to require any hosts contacting them use local addresses as well. I welcome any suggestions on how to accomplish the same goals without increasing overall complexity. 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 exim@www1.ietf.org Sun Mar 7 16:47:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06831 for ; Sun, 7 Mar 2004 16:47:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0671-0003LT-Gy for ipv6-archive@odin.ietf.org; Sun, 07 Mar 2004 16:47:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i27Ll7lp012855 for ipv6-archive@odin.ietf.org; Sun, 7 Mar 2004 16:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0671-0003LG-AO for ipv6-web-archive@optimus.ietf.org; Sun, 07 Mar 2004 16:47:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06794 for ; Sun, 7 Mar 2004 16:47:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B066z-00060E-00 for ipv6-web-archive@ietf.org; Sun, 07 Mar 2004 16:47:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B066G-0005rO-00 for ipv6-web-archive@ietf.org; Sun, 07 Mar 2004 16:46:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B065W-0005i1-00 for ipv6-web-archive@ietf.org; Sun, 07 Mar 2004 16:45:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0652-000322-7v; Sun, 07 Mar 2004 16:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0649-00030e-1E for ipv6@optimus.ietf.org; Sun, 07 Mar 2004 16:44:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06646 for ; Sun, 7 Mar 2004 16:44:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0647-0005We-00 for ipv6@ietf.org; Sun, 07 Mar 2004 16:44:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0635-0005Ni-00 for ipv6@ietf.org; Sun, 07 Mar 2004 16:43:04 -0500 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 1B062d-0005Ej-00 for ipv6@ietf.org; Sun, 07 Mar 2004 16:42:35 -0500 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=[192.168.0.4]) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1B062W-000075-00; Sun, 07 Mar 2004 13:42:28 -0800 In-Reply-To: <011401c4047d$5d2bef40$6401a8c0@ssprunk> References: <40461D35.5D17EE08@zurich.ibm.com> <20040305142938.09785621.moore@cs.utk.edu> <01d701c402ec$8f8964a0$6401a8c0@ssprunk> <8BC9370A-6EEF-11D8-87F6-000393DB5366@cs.utk.edu> <02cc01c40314$ed0280d0$6401a8c0@ssprunk> <13F3D4A0-6F10-11D8-87F6-000393DB5366@cs.utk.edu> <030b01c40333$543a9f80$6401a8c0@ssprunk> <1B558F56-6F3A-11D8-87F6-000393DB5366@cs.utk.edu> <011401c4047d$5d2bef40$6401a8c0@ssprunk> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5F46C6A3-7080-11D8-87F6-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit Cc: Keith Moore , ipv6@ietf.org From: Keith Moore Subject: Re: Adopt Address Selection API as a WG document? Date: Sun, 7 Mar 2004 16:42:46 -0500 To: "Stephen Sprunk" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> whether it's a good idea to encourage sites to use address selection >> as >> a means of policy enforcement is a separate question. IMHO this is >> not >> sound architecture. but that's a separate question from the API. > > I'm not convinced it's sound either, but I can't figure out a more > straightforward way of implementing the types of policies I hear > customers > ask for. what policies are those? what kinds of filtering can be implemented with address selection that cannot be implemented without it? >>> I meant the application can't statically determine what a site's >>> policy >>> will be; that doesn't mean the API can't determine it via some sort >>> of >>> configuration. >> >> the more I think about it the clearer it becomes that specifying >> application policy at the network level is like trying to make fine >> furniture with a chainsaw - it's the wrong tool for the job. so the >> API that the app uses to deal with the network is not the right place >> to inform the app about policy. > > I don't think the app needs to be aware of policy if it's hidden > behind the > API -- presumably the policy will be configured and implemented in the > OS or > some system library. As long as the app can specify what behavior it > needs > and the policy is able to find a valid address, the app can stay > oblivious. that's true only as long as the same policy applies to every host that is participating in the app. any app that crosses policy domains has the potential for conflicts between those policies. in one part of the network the policy is to favor globals; in another the policy is to favor locals. there's no good reason to support this kind of inconsistency and complexity. what we need are a set of rules for assigning addresses to hosts and for use of addresses by hosts and apps that works the same everywhere. that doesn't stop networks from having policies, but it does mean that there are correct and incorrect ways to implement those policies. >> the app writer knows what his app needs from the network. if the >> network doesn't provide what the app needs, the app is likely to fail. >> maybe it won't fail every single time it is used, but it won't be >> reliable. > > Even if the API were to return what the app asks for (e.g. a global > address), there are still a large number of cases where that address > still > won't work because of firewalls or other necessary evils. it is not at all clear that firewalls as we currently know them are necessary, though I do accept that they're going to continue to exist for awhile. as long as packet filters exist the best we can hope for is to get them to return appropriate ICMP messages. > On a slightly different note, there may be many servers or p2p apps > with > only local addresses available because that is the administrator's > intent. the rules have to accommodate the fact that not everyone is connected to the public internet and not everyone has public addresses. apps have to use local addresses if global addresses are not available. of course this limits the app to whatever addresses are reachable. but the same is true for global addresses, since as you point out, those addresses can still be filtered. on the other hand, if your net has a global prefix, trying to limit a host or an app to a local prefix is not a very good way to implement policy. it's the wrong tool for the job. > Having these apps fail because no global address is available doesn't > make > sense, even if it does print a friendly error on the screen. This > case is > only marginally different than one where a global address is available > but > the administrator doesn't want it used for local communication. no, that's just wrong. it's one thing to say that an app isn't expected to communicate if the network isn't wiling to route packets between its hosts. it's quite another to say that it's appropriate for network admins to restrict which addresses an app or host can use in order to keep the network from routing packets between certain hosts. it's crude and imprecise, it imposes unnecessary complexity on hosts and apps, and it's unreliable. it's much easier to reliably implement a policy if reachability is the same for every address that is available to a host than if reachability varies from one prefix to another. it's also much easier to monitor network traffic for policy violations if this is the case. >>> "Needs a global address" is an inherently flawed expectation; "needs >>> an >>> address which can reach a given address" is not. >> >> there are apps that need global addresses in order to function >> properly. there are other apps which need addresses that are >> reachable by an arbitrary number of hosts which might be participating >> in the application now or at sometime in the future (though they don't >> need to be global). other apps only need pairwise reachability. > > "Function properly" and "reachable by an arbitrary number of hosts" > are both > flawed in the presence of firewalls anyhow. ARRRRRRRRRRGH! no, they're not flawed. it may be that what the app needs and how the admin has configured a firewall are mutually inconsistent. that doesn't inherently mean there's something wrong with the app. it's perfectly reasonable for some apps to operate that way. it might be that the admin simply doesn't want that app to operate. it might be that the admin has misconfigured the firewall. it might be that present-day firewalls are too crude to allow the admin to implement the policy that he wants and still have the app operate. but folks need to stop blaming apps for failing when they impose unreasonable conditions on their operation. > It is well within an > administrator's right to block such applications from leaving the local > network, and in that case a local address becomes superior to a global > one > due to stability. you're confusing two different things here. one is policy, and the other is use of local addresses for stability. if the app can reasonably make use of local addresses, telling the app "hey, you can use this more stable local address in place of this global one" is a useful thing to do. then the app can optimize if it's able to do so. but this doesn't work equally well for all apps. some apps need for every host to use the same address and for all of those addresses to be reachable by all participating hosts. those apps probably don't want to use local addresses unless they're the only ones available. this is something for the app to decide, not something for an admin to try to dictate with policy. it's not reasonable to expect admins to know how every app operates and what they need in terms of addresses. it is reasonable to let admins control which hosts or users or principals an app can talk to, but prefix assignment is not the right mechanism for the job. >>> I never suggested that; I gave a simple case of two mutually >>> exclusive >>> local policies which are both perfectly reasonable, but would cause >>> apps >>> to needlessly fail if they make unfounded static assumptions. >> >> it's not "perfectly reasonable" for local policies to expect apps to >> vary how they choose addresses from one site to the next. > > That's the whole point of providing an API -- the app just specifies > its > requirements and which available address is returned (if any) will > implicitly vary between sites. having an API is useful - to a point. different kinds of apps prefer different kinds of addresses. some apps prefer privacy addresses; others need addresses that have a long-term association with the host. some apps prefer local addresses even when a global is available, others have the opposite preference. some apps prefer an ephemeral address (like an address that changes when the host moves) for the sake of efficiency, others prefer one that will stay the same even if the host moves even though this is less efficient. it's good to have an API that lets the host and app negotiate these things. what's not a good idea is to expect this API to be a means for implementing policy. the fact that the address selection is hidden by an API does not keep it from breaking apps. >>> There is no consistent view of the network independent of location. >>> Not all addresses can reach all other addresses, and that is >>> something >>> we all need to live with. >> >> true. but if for whatever reason the network cannot or is prohibited >> from routing traffic between two points, it needs to be clear that >> it's >> not the app's job to do so. expecting the app to be aware of network >> topology, local policy, or whatever is not reasonable. > > Right. But I argue it's reasonable to allow an administrator to > configure > hosts with local policies, which the apps transparently inherit. that's like arguing that it's reasonable to allow the administrator to unplug the machines from the mains and still expect the apps to work. sure enough, you can implement a policy of sorts by doing that - but it's a very crude mechanism. we can't stop admins from doing things like this, but that doesn't mean we should tell them that it's a good way to implement policy. (and an API won't help much) > An "obvious" security scheme for corporate networks is to block all > packets > with local addresses at the firewall (as specified in the I-D) which I-D is this? I've been ill for several months and not able to keep up. but that's a REALLY, REALLY Bad Idea - one which needs to be thoroughly discredited. > and then > block access to server farms from non-local addresses (in case there's > a > leak or misconfiguration at the firewall, and to simplify > configuration and > auditing). Since the servers inside that farm will only have local > addresses themselves, it is logical to require any hosts contacting > them use > local addresses as well. I welcome any suggestions on how to > accomplish the > same goals without increasing overall complexity. the method you're proposing is pretty complex already - it just puts the complexity in the hosts and apps (not only in having to implement the policy but in being expected to work around the resulting dysfunctionality) if you must put policy in addresses, don't put it in the "local" vs. "global" bits - put it in the least significant bits of the subnet. that lets you write simple filtering rules at the routers without expecting apps to be contortionists. here's the thing - it's rarely the case that an admin really wants to isolate a network or even a significant set of hosts. what the admin typically wants (if he'll take the time to think about it) is to let some apps traverse boundaries and other apps not traverse those boundaries. also, it's less and less often the case that the boundaries that an admin wants to enforce conveniently coincide with routers. of course admins try to arrange their networks that way, but there are constantly good reasons to make exceptions. meanwhile app writers are standing on their heads trying to make their apps work in the presence of arbitrary constraints imposed by network admins -- even when the network admins weren't trying to break those apps. what this means to me is that we need to provide better tools for network admins to specify policy to apps and to enforce that policy in depth. but that's not the same thing as saying that we need to give network admins more tools for limiting which addresses a host or app can use. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 8 09:08:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01262 for ; Mon, 8 Mar 2004 09:08:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LQ3-0003Dt-RZ for ipv6-archive@odin.ietf.org; Mon, 08 Mar 2004 09:07:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28E7lYn012378 for ipv6-archive@odin.ietf.org; Mon, 8 Mar 2004 09:07:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LQ3-0003DR-AT for ipv6-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 09:07:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01254 for ; Mon, 8 Mar 2004 09:07:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0LQ1-0004Qw-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 09:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0LP0-0004HK-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 09:06:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0LOH-00048P-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 09:05:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LNP-0002j6-SB; Mon, 08 Mar 2004 09:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0LMu-0002iT-T8 for ipv6@optimus.ietf.org; Mon, 08 Mar 2004 09:04:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01109 for ; Mon, 8 Mar 2004 09:04:29 -0500 (EST) From: jarno.rajahalme@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0LMt-0003xy-00 for ipv6@ietf.org; Mon, 08 Mar 2004 09:04:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0LLz-0003qQ-00 for ipv6@ietf.org; Mon, 08 Mar 2004 09:03:35 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1B0LLb-0003io-00 for ipv6@ietf.org; Mon, 08 Mar 2004 09:03:11 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i28E2xC13686; Mon, 8 Mar 2004 16:02:59 +0200 (EET) X-Scanned: Mon, 8 Mar 2004 16:02:24 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i28E2Orv018953; Mon, 8 Mar 2004 16:02:24 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00EqLhtr; Mon, 08 Mar 2004 16:02:23 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i28E2M725835; Mon, 8 Mar 2004 16:02:22 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Mar 2004 16:02:22 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Mar 2004 16:02:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Appeal on "Unique Local IPv6 Unicast Addresses" Date: Mon, 8 Mar 2004 16:02:22 +0200 Message-ID: <009CA59D1752DD448E07F8EB2F91175701FD0728@esebe004.ntc.nokia.com> Thread-Topic: Appeal on "Unique Local IPv6 Unicast Addresses" thread-index: AcQDGq3/lx/QR6xbSsqftE8bbGPOzwB+tYLA To: , Cc: , , , X-OriginalArrivalTime: 08 Mar 2004 14:02:22.0201 (UTC) FILETIME=[FA1F1690:01C40515] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thomas Narten wrote: > why we can't make such assignments permanent. (Note: I'd agree with > you that the assignments shouldn't be permanent if there was a case to > be made that it may become necessary to reclaim them at some future > time. Is there?) >=20 What if someone manages to hoard the address space and then starts to = sell them? Assume a bug in the system managing the allocations and = someone exploiting it and getting 1/2 of the whole address space that = they now "own" for good. Maybe there should be a notion of reclaiming prefixes that should not = have been allocated in the first place? Regards, Jarno -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 8 13:08:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17563 for ; Mon, 8 Mar 2004 13:08:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0PAZ-0003vB-Hb for ipv6-archive@odin.ietf.org; Mon, 08 Mar 2004 13:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28I83jn015063 for ipv6-archive@odin.ietf.org; Mon, 8 Mar 2004 13:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0PAY-0003ud-Ic for ipv6-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 13:08:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17554 for ; Mon, 8 Mar 2004 13:07:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0PAV-000464-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 13:07:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0P9V-0003vb-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 13:06:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0P90-0003lN-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 13:06:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0P8d-0003SX-P2; Mon, 08 Mar 2004 13:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0P8X-0003RC-QM for ipv6@optimus.ietf.org; Mon, 08 Mar 2004 13:05:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17465 for ; Mon, 8 Mar 2004 13:05:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0P8V-0003kQ-00 for ipv6@ietf.org; Mon, 08 Mar 2004 13:05:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0P7c-0003aj-00 for ipv6@ietf.org; Mon, 08 Mar 2004 13:05:01 -0500 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx with esmtp (Exim 4.12) id 1B0P73-0003Q3-00 for ipv6@ietf.org; Mon, 08 Mar 2004 13:04:25 -0500 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id i28I4ON8019289 for ; Mon, 8 Mar 2004 20:04:24 +0200 (EET) Received: from halonen.eur.soneragroup.net (halonen.eur.soneragroup.net [131.177.121.199]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id i28I4NsY019279 for ; Mon, 8 Mar 2004 20:04:23 +0200 (EET) Received: from teliasonera.com ([194.142.21.49]) by halonen.eur.soneragroup.net with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Mar 2004 20:04:23 +0200 Message-ID: <404CB5A2.4080104@teliasonera.com> Date: Mon, 08 Mar 2004 20:04:18 +0200 From: Jyrki Soini Organization: TeliaSonera Finland User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: ICMPv6 echo reply to multicast packet thread Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2004 18:04:23.0742 (UTC) FILETIME=[C9A265E0:01C40537] Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I sent a comment to ICMPv6 update draft during IETF meeting and received a few comments but not quite a discussion. Here is somewhat extreme example of the DoS attack vulnerability I'm worried about: Imagine, one day man is landing on Mars and real-time video is multicasted on Internet. There are 100 million listeners on the group. The multicast group is any-source group using embedded RP address. The video quality is not perfect and one listener decides to debug the problem. He sends a ICMPv6 Echo Request packets to the group address without thinking beforehand. As the group is any-source group, the host is allowed to send packets. Packet gets delivered to the RP that sends it through the multicast tree. Current ICMPv6 specification states at Chapter 4.2 Echo Reply Message: "An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast or anycast address." The consequence is that the original Echo Request packet gets 100 000 000 unicast Echo Reply messages back. Ping to multicast address has operational usage as debugging tool and totally disabling reply to Echo Request message sent to an IPv6 multicast address would not be a good solution. I see two alternatives to limit the Echo Reply to multicast packet problem: 1. Limit Echo Reply packet to only be allowed on link-scope multicast echo requests. 2. Require that hop-limit is set to for instance value 1 for the Echo Reply packet. I find the latter alternative is better as this way also global scope multicast groups may be debugged still although the echo reply will be discarded by the first router. Message sent to anycast address should only cause one reply message and that should not be problematic. I propose changing chapter 4.2 Echo Reply Message paragraph: An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast or anycast address. In this case, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received. to: An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast address and the Hop-Limit IPv6 header field MUST be set to value 1. If Echo Reply message is sent in responce to an Echo Request message sent to an IPv6 multicast or anycast address, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received. Perhaphs in practice the hop-limit could be somewhat bigger than 1 without real problems? --- Jyrki Soini -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 8 13:40:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20082 for ; Mon, 8 Mar 2004 13:40:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0PfY-0007FK-US for ipv6-archive@odin.ietf.org; Mon, 08 Mar 2004 13:40:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28Ie4N5027848 for ipv6-archive@odin.ietf.org; Mon, 8 Mar 2004 13:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0PfX-0007Ex-9Y for ipv6-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 13:40:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20056 for ; Mon, 8 Mar 2004 13:40:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0PfU-00031N-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 13:40:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Peq-0002ok-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 13:39:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Pdq-0002Z1-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 13:38:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Pda-0006mE-1Q; Mon, 08 Mar 2004 13:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Pcs-0006bA-4h for ipv6@optimus.ietf.org; Mon, 08 Mar 2004 13:37:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19702 for ; Mon, 8 Mar 2004 13:37:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Pcq-0002JE-00 for ipv6@ietf.org; Mon, 08 Mar 2004 13:37:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Pbb-000233-00 for ipv6@ietf.org; Mon, 08 Mar 2004 13:36:00 -0500 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1B0Pal-0001of-00 for ipv6@ietf.org; Mon, 08 Mar 2004 13:35:08 -0500 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id C89FC86B1; Mon, 8 Mar 2004 19:35:04 +0100 (CET) From: "Jeroen Massar" To: "'Jyrki Soini'" , Subject: RE: ICMPv6 echo reply to multicast packet thread Date: Mon, 8 Mar 2004 19:34:07 +0100 Organization: Unfix MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <404CB5A2.4080104@teliasonera.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: AcQFOBV8BmDNCQK5TcOQlhf12BuBWwAA0+Aw Message-Id: <20040308183504.C89FC86B1@purgatory.unfix.org> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jyrki Soini wrote: > I sent a comment to ICMPv6 update draft during IETF meeting > and received a few comments but not quite a discussion. Here is somewhat extreme > example of the DoS attack vulnerability I'm worried about: > > Imagine, one day man is landing on Mars and real-time video is > multicasted on Internet. There are 100 million listeners on the > group. I like this idea, especially the part where 100 million users are using IPv6 ;) I see two alternatives to limit the Echo Reply to multicast packet > problem: > 1. Limit Echo Reply packet to only be allowed on link-scope multicast > echo requests. > 2. Require that hop-limit is set to for instance value 1 for the > Echo Reply packet. > Perhaphs in practice the hop-limit could be somewhat bigger > than 1 without real problems? I would suggest that the default hoplimit for these kind of ICMP's gets set to 1 but that it is configurable in cases where the ISP knows the size of their multicast network. In an ideal solution it would be only the hops of a maximum of 2 AS's. In light of the above and debugging multicast wouldn't it be a good idea to revive and implement mtrace, eg as in: http://archive.dante.net/mbone/refs/draft-ietf-idmr-traceroute-ipm-07.txt But then for IPv6? Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQEy8ngAAVlYAn2N4aqJu7SfQIyb5e6Lh/Ka0 6iQWAKCznpaI+nNNUnBEPMzLAzTqZyED+g== =GlD7 -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 8 17:45:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08104 for ; Mon, 8 Mar 2004 17:45:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TUl-0002Yw-7a for ipv6-archive@odin.ietf.org; Mon, 08 Mar 2004 17:45:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28MjBuJ009844 for ipv6-archive@odin.ietf.org; Mon, 8 Mar 2004 17:45:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TUl-0002Yh-2r for ipv6-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 17:45:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08097 for ; Mon, 8 Mar 2004 17:45:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TUi-0003F9-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 17:45:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TU2-00033p-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 17:44:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0TTD-0002qn-00 for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 17:43:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0TTD-0000hd-Jj for ipv6-web-archive@ietf.org; Mon, 08 Mar 2004 17:43:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TSf-00025x-Dk; Mon, 08 Mar 2004 17:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0TSX-00025P-Ar for ipv6@optimus.ietf.org; Mon, 08 Mar 2004 17:42:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07934 for ; Mon, 8 Mar 2004 17:42:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0TSU-0002jr-00 for ipv6@ietf.org; Mon, 08 Mar 2004 17:42:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0TRW-0002b9-00 for ipv6@ietf.org; Mon, 08 Mar 2004 17:41:50 -0500 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1B0TQY-0002MB-00 for ipv6@ietf.org; Mon, 08 Mar 2004 17:40:51 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id RAA11589; Mon, 8 Mar 2004 17:40:42 -0500 (EST) Date: Mon, 8 Mar 2004 17:40:42 -0500 (EST) From: Dan Lanciani Message-Id: <200403082240.RAA11589@ss10.danlan.com> To: ipv6@ietf.org Subject: RE: Appeal on "Unique Local IPv6 Unicast Addresses" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 jarno.rajahalme@nokia.com wrote: |Thomas Narten wrote: |> why we can't make such assignments permanent. (Note: I'd agree with |> you that the assignments shouldn't be permanent if there was a case to |> be made that it may become necessary to reclaim them at some future |> time. Is there?) |> | |What if someone manages to hoard the address space and then starts to sell them? Assume a bug in the system managing the allocations and someone exploiting it and getting 1/2 of the whole address space that they now "own" for good. We are already contemplating a one-time fee per allocation. If someone is willing to come up with enough money to acquire 1/2 the address space (that's a _lot_ of money for any plausible value of the one-time fee) the registry entity will have vast resources to work out a better scheme for handing out the remaining 1/2 of the address space. |Maybe there should be a notion of reclaiming prefixes that should not have been allocated in the first place? Vague "notions" like that severely devalue the prefixes, and specific wording will likely fail to cover whatever may go wrong. In the worst case we can always allocate another prefix. After all, this is only a /8. It's not like we are giving away another /3... Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 9 00:46:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23880 for ; Tue, 9 Mar 2004 00:46:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0a41-0005ow-3L for ipv6-archive@odin.ietf.org; Tue, 09 Mar 2004 00:46:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i295k1tH022368 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 00:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0a40-0005oh-UU for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 00:46:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23761 for ; Tue, 9 Mar 2004 00:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0a3y-0007Hx-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 00:45:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0a1e-0006UP-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 00:43:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0ZyC-0005co-03 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 00:40:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0Zlr-000153-Cn for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 00:27:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Zis-0002dO-62; Tue, 09 Mar 2004 00:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ZGx-0000Iw-A4 for ipv6@optimus.ietf.org; Mon, 08 Mar 2004 23:55:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21141 for ; Mon, 8 Mar 2004 23:55:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ZGv-0006Kh-00 for ipv6@ietf.org; Mon, 08 Mar 2004 23:55:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0ZG5-0006Av-00 for ipv6@ietf.org; Mon, 08 Mar 2004 23:54:25 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1B0ZF1-00060y-00 for ipv6@ietf.org; Mon, 08 Mar 2004 23:53:19 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id DC0E215214; Tue, 9 Mar 2004 13:53:11 +0900 (JST) Date: Tue, 09 Mar 2004 13:53:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: ipv6@ietf.org Subject: reference dependency (DS to PS) (Re: [rfc2462bis] M/O flags and DHCPv6) In-Reply-To: <4.3.2.7.2.20040304025619.01fdb038@flask.cisco.com> References: <4.3.2.7.2.20040304023041.029dc170@flask.cisco.com> <4.3.2.7.2.20040304025619.01fdb038@flask.cisco.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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Thu, 04 Mar 2004 03:00:08 -0500, >>>>> Ralph Droms said: > Jinmei - I mistyped and you guessed what I had intended to ask. Good catch > and thanks for the clarification. > Can anyone supply a direct reference to an explicit statement that "a DS > spec cannot have a normative reference to a PS spec."? I've not seen any responses yet...I guess we could deal with the original issue with leaving this open, but it's still very helpful to clarify this point to make a realistic decision. If no one can give a concrete pointer, I'll assume "a DS spec cannot have a normative reference to a PS spec" for safety. 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 exim@www1.ietf.org Tue Mar 9 10:52:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04338 for ; Tue, 9 Mar 2004 10:52:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jW3-0002cg-Os for ipv6-archive@odin.ietf.org; Tue, 09 Mar 2004 10:51:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29FpZx8010076 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 10:51:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jW3-0002cR-Fn for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:51:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04256 for ; Tue, 9 Mar 2004 10:51:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jW1-0005QI-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 10:51:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jSY-0004Mz-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 10:47:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0jOM-00035G-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 10:43:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jI3-0004Q6-Sa; Tue, 09 Mar 2004 10:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0i63-0005IK-Af for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 09:20:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28365 for ; Tue, 9 Mar 2004 09:20:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0i61-0003vd-00 for ipv6@ietf.org; Tue, 09 Mar 2004 09:20:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0i54-0003lc-00 for ipv6@ietf.org; Tue, 09 Mar 2004 09:19:39 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1B0i4A-0003S5-00 for ipv6@ietf.org; Tue, 09 Mar 2004 09:18:42 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i29EFCpS102160; Tue, 9 Mar 2004 14:15:12 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i29EFF6c249234; Tue, 9 Mar 2004 15:15:15 +0100 Received: from zurich.ibm.com (gsine09.us.sine.ibm.com [9.14.6.39]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id PAA38734; Tue, 9 Mar 2004 15:15:06 +0100 Message-ID: <404D843E.D4EDAE92@zurich.ibm.com> Date: Tue, 09 Mar 2004 09:45:50 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: narten@us.ibm.com, Alain.Durand@Sun.COM, brian@innovationslab.net, ipv6@ietf.org, margaret@thingmagic.com, Bob.Hinden@nokia.com Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" References: <009CA59D1752DD448E07F8EB2F91175701FD0728@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jarno, this is exactly why the fixed charge is suggested - to make the cost of bulk hoarding significant. And no, I don't want to imagine such a bug - I have more confidence than that in IANA and the organisations IANA delegates to. Brian jarno.rajahalme@nokia.com wrote: > > Thomas Narten wrote: > > why we can't make such assignments permanent. (Note: I'd agree with > > you that the assignments shouldn't be permanent if there was a case to > > be made that it may become necessary to reclaim them at some future > > time. Is there?) > > > > What if someone manages to hoard the address space and then starts to sell them? Assume a bug in the system managing the allocations and someone exploiting it and getting 1/2 of the whole address space that they now "own" for good. > > Maybe there should be a notion of reclaiming prefixes that should not have been allocated in the first place? > > Regards, > > Jarno > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 9 14:12:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15679 for ; Tue, 9 Mar 2004 14:12:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0mdy-00026L-IQ for ipv6-archive@odin.ietf.org; Tue, 09 Mar 2004 14:11:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29JBwlQ008076 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 14:11:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0mdy-00026A-Bn for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 14:11:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15658 for ; Tue, 9 Mar 2004 14:11:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0mdw-0007VD-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 14:11:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0mcz-0007La-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 14:10:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0mcY-0007Bb-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 14:10:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0mc7-0001sw-J5; Tue, 09 Mar 2004 14:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0mb6-0001jn-0E for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 14:09:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15495 for ; Tue, 9 Mar 2004 14:08:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0mb3-00070V-00 for ipv6@ietf.org; Tue, 09 Mar 2004 14:08:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0maB-0006qE-00 for ipv6@ietf.org; Tue, 09 Mar 2004 14:08:04 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B0mZX-0006ds-00 for ipv6@ietf.org; Tue, 09 Mar 2004 14:07:23 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i29J6kT26025; Tue, 9 Mar 2004 11:06:46 -0800 X-mProtect: <200403091906> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrDfWyE; Tue, 09 Mar 2004 11:06:42 PST Message-ID: <404E15B8.B01685BB@iprg.nokia.com> Date: Tue, 09 Mar 2004 11:06:32 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: jarno.rajahalme@nokia.com, ipv6@ietf.org Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" References: <009CA59D1752DD448E07F8EB2F91175701FD0728@esebe004.ntc.nokia.com> <404D843E.D4EDAE92@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Brian, I think that the fixed charge is a mistake, and should be avoided. To avoid hoarding, of course it would be good to avoid bugs. In case, that is considered impossible (sigh!) we can also demand that each address and/or prefix be accompanied by a certificate generated by IANA with a one-way hash to validate it. The hash is to be unforgeable. The certificate is to contain the time of issuance. Nobody is going to be able to present a billion certificates satisfying the time constraint that each one be separated by one or more seconds. This can be made to be machine verifiable also. Maybe there is another way, but in any case I strongly think the fixed charge should be avoided. And, finally, I assert that the bugs can be avoided anyway. It doesn't have to be more than a few hundred lines of code. Regards, Charlie P. Brian E Carpenter wrote: > > Jarno, this is exactly why the fixed charge is suggested - to make > the cost of bulk hoarding significant. > > And no, I don't want to imagine such a bug - I have more confidence than > that in IANA and the organisations IANA delegates to. > > Brian > > jarno.rajahalme@nokia.com wrote: > > > > Thomas Narten wrote: > > > why we can't make such assignments permanent. (Note: I'd agree with > > > you that the assignments shouldn't be permanent if there was a case to > > > be made that it may become necessary to reclaim them at some future > > > time. Is there?) > > > > > > > What if someone manages to hoard the address space and then starts to sell them? Assume a bug in the system managing the allocations and someone exploiting it and getting 1/2 of the whole address space that they now "own" for good. > > > > Maybe there should be a notion of reclaiming prefixes that should not have been allocated in the first place? > > > > Regards, > > > > Jarno > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Tue Mar 9 14:46:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17622 for ; Tue, 9 Mar 2004 14:46:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nAu-0004o6-OM for ipv6-archive@odin.ietf.org; Tue, 09 Mar 2004 14:46:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29Jk0C0018472 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 14:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nAu-0004nr-HM for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 14:46:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17577 for ; Tue, 9 Mar 2004 14:45:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nAr-0005ml-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 14:45:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0nA1-0005cZ-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 14:45:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0n9R-0005Rn-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 14:44:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0n90-0004IT-Mr; Tue, 09 Mar 2004 14:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0n8r-0004Hn-QV for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 14:43:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17485 for ; Tue, 9 Mar 2004 14:43:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0n8p-0005PK-00 for ipv6@ietf.org; Tue, 09 Mar 2004 14:43:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0n83-0005Fs-00 for ipv6@ietf.org; Tue, 09 Mar 2004 14:43:04 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B0n7D-0004ux-00 for ipv6@ietf.org; Tue, 09 Mar 2004 14:42:11 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i29JfWj21952; Tue, 9 Mar 2004 11:41:32 -0800 X-mProtect: <200403091941> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpd0JjbvD; Tue, 09 Mar 2004 11:41:29 PST Message-Id: <4.3.2.7.2.20040309113229.024e1320@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Mar 2004 11:41:10 -0800 To: "Charles E. Perkins" From: Bob Hinden Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" Cc: Brian E Carpenter , jarno.rajahalme@nokia.com, ipv6@ietf.org In-Reply-To: <404E15B8.B01685BB@iprg.nokia.com> References: <009CA59D1752DD448E07F8EB2F91175701FD0728@esebe004.ntc.nokia.com> <404D843E.D4EDAE92@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Charlie, >I think that the fixed charge is a mistake, and >should be avoided. I trust that everyone commenting on this has actually read the current draft. A fixed charge was removed several drafts ago. The current draft does not impose a fixed charge for a prefix, but instead sets a requirement that the allocation authority implement a mechanism that prevents hoarding. Specifically from section 3.2.1 Centrally Assigned Global IDs: - Provide mechanisms that prevent hoarding of these allocations. .... The allocation service should include sufficient provisions to avoid hoarding of numbers. This can be accomplished by various ways, for example, requiring an exchange of documents, a verbal contact, or a proof that the request is on behalf of a human rather than a machine. The service may charge a small fee in order to cover its costs, but the fee should be low enough to not create a barrier to anyone needing one. The precise mechanisms should be decided by the registration authority. Bob >To avoid hoarding, of course it would be good to >avoid bugs. In case, that is considered impossible >(sigh!) we can also demand that each address and/or >prefix be accompanied by a certificate generated >by IANA with a one-way hash to validate it. >The hash is to be unforgeable. The certificate >is to contain the time of issuance. > >Nobody is going to be able to present a billion >certificates satisfying the time constraint that >each one be separated by one or more seconds. >This can be made to be machine verifiable also. > >Maybe there is another way, but in any case I >strongly think the fixed charge should be avoided. > >And, finally, I assert that the bugs can be >avoided anyway. It doesn't have to be more >than a few hundred lines of code. > >Regards, >Charlie P. > > >Brian E Carpenter wrote: > > > > Jarno, this is exactly why the fixed charge is suggested - to make > > the cost of bulk hoarding significant. > > > > And no, I don't want to imagine such a bug - I have more confidence than > > that in IANA and the organisations IANA delegates to. > > > > Brian > > > > jarno.rajahalme@nokia.com wrote: > > > > > > Thomas Narten wrote: > > > > why we can't make such assignments permanent. (Note: I'd agree with > > > > you that the assignments shouldn't be permanent if there was a case to > > > > be made that it may become necessary to reclaim them at some future > > > > time. Is there?) > > > > > > > > > > What if someone manages to hoard the address space and then starts to > sell them? Assume a bug in the system managing the allocations and > someone exploiting it and getting 1/2 of the whole address space that > they now "own" for good. > > > > > > Maybe there should be a notion of reclaiming prefixes that should not > have been allocated in the first place? > > > > > > Regards, > > > > > > Jarno > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Brian E Carpenter > > Distinguished Engineer, Internet Standards & Technology, IBM > > > > -------------------------------------------------------------------- > > 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 exim@www1.ietf.org Tue Mar 9 15:17:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20406 for ; Tue, 9 Mar 2004 15:17:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nep-0007zf-BR for ipv6-archive@odin.ietf.org; Tue, 09 Mar 2004 15:16:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29KGtZe030721 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 15:16:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nep-0007zQ-1O for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 15:16:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20362 for ; Tue, 9 Mar 2004 15:16:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nen-0003Zf-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 15:16:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0ndt-0003QW-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 15:15:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0ndc-0003H2-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 15:15:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nd1-0007Jb-L8; Tue, 09 Mar 2004 15:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ncr-0007Gj-Ta for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 15:14:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20166 for ; Tue, 9 Mar 2004 15:14:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ncq-0003Fu-00 for ipv6@ietf.org; Tue, 09 Mar 2004 15:14:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0nbz-00036z-00 for ipv6@ietf.org; Tue, 09 Mar 2004 15:14:00 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B0nbJ-0002uG-00 for ipv6@ietf.org; Tue, 09 Mar 2004 15:13:17 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i29KCdA09449; Tue, 9 Mar 2004 12:12:39 -0800 X-mProtect: <200403092012> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdD46tKU; Tue, 09 Mar 2004 12:12:37 PST Message-ID: <404E2531.6040006@iprg.nokia.com> Date: Tue, 09 Mar 2004 12:12:33 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden CC: "Charles E. Perkins" , Brian E Carpenter , jarno.rajahalme@nokia.com, ipv6@ietf.org Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" References: <009CA59D1752DD448E07F8EB2F91175701FD0728@esebe004.ntc.nokia.com> <404D843E.D4EDAE92@zurich.ibm.com> <4.3.2.7.2.20040309113229.024e1320@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Has there been any resolution as to a name for the new addresses? As I recall, there was some earlier discussion to this point. Thanks - Fred ftemplin@iprg.nokia.com Bob Hinden wrote: > Charlie, > >> I think that the fixed charge is a mistake, and >> should be avoided. > > > I trust that everyone commenting on this has actually read the current > draft. A fixed charge was removed several drafts ago. > > The current draft does not impose a fixed charge for a prefix, but > instead sets a requirement that the allocation authority implement a > mechanism that prevents hoarding. Specifically from section 3.2.1 > Centrally Assigned Global IDs: > > - Provide mechanisms that prevent hoarding of these allocations. > > .... > > The allocation service should include sufficient provisions to avoid > hoarding of numbers. This can be accomplished by various ways, for > example, requiring an exchange of documents, a verbal contact, or a > proof that the request is on behalf of a human rather than a machine. > The service may charge a small fee in order to cover its costs, but > the fee should be low enough to not create a barrier to anyone > needing one. The precise mechanisms should be decided by the > registration authority. > > Bob > > >> To avoid hoarding, of course it would be good to >> avoid bugs. In case, that is considered impossible >> (sigh!) we can also demand that each address and/or >> prefix be accompanied by a certificate generated >> by IANA with a one-way hash to validate it. >> The hash is to be unforgeable. The certificate >> is to contain the time of issuance. >> >> Nobody is going to be able to present a billion >> certificates satisfying the time constraint that >> each one be separated by one or more seconds. >> This can be made to be machine verifiable also. >> >> Maybe there is another way, but in any case I >> strongly think the fixed charge should be avoided. >> >> And, finally, I assert that the bugs can be >> avoided anyway. It doesn't have to be more >> than a few hundred lines of code. >> >> Regards, >> Charlie P. >> >> >> Brian E Carpenter wrote: >> > >> > Jarno, this is exactly why the fixed charge is suggested - to make >> > the cost of bulk hoarding significant. >> > >> > And no, I don't want to imagine such a bug - I have more confidence >> than >> > that in IANA and the organisations IANA delegates to. >> > >> > Brian >> > >> > jarno.rajahalme@nokia.com wrote: >> > > >> > > Thomas Narten wrote: >> > > > why we can't make such assignments permanent. (Note: I'd agree >> with >> > > > you that the assignments shouldn't be permanent if there was a >> case to >> > > > be made that it may become necessary to reclaim them at some >> future >> > > > time. Is there?) >> > > > >> > > >> > > What if someone manages to hoard the address space and then >> starts to sell them? Assume a bug in the system managing the >> allocations and someone exploiting it and getting 1/2 of the whole >> address space that they now "own" for good. >> > > >> > > Maybe there should be a notion of reclaiming prefixes that should >> not have been allocated in the first place? >> > > >> > > Regards, >> > > >> > > Jarno >> > > >> > > -------------------------------------------------------------------- >> > > IETF IPv6 working group mailing list >> > > ipv6@ietf.org >> > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> > > -------------------------------------------------------------------- >> > >> > -- >> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> > Brian E Carpenter >> > Distinguished Engineer, Internet Standards & Technology, IBM >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 9 19:22:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09066 for ; Tue, 9 Mar 2004 19:22:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rU7-00063H-Tl for ipv6-archive@odin.ietf.org; Tue, 09 Mar 2004 19:22:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A0M7IT023252 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 19:22:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rU6-00062x-Ux for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 19:22:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09057 for ; Tue, 9 Mar 2004 19:22:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0rU5-0003Zf-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 19:22:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0rT8-0003Pi-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 19:21:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0rSW-0003G2-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 19:20:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rS8-0005en-MJ; Tue, 09 Mar 2004 19:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rRH-0005c1-1q for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 19:19:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08863 for ; Tue, 9 Mar 2004 19:19:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0rRF-00036L-00 for ipv6@ietf.org; Tue, 09 Mar 2004 19:19:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0rQK-0002wf-00 for ipv6@ietf.org; Tue, 09 Mar 2004 19:18:13 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1B0rPz-0002lj-00 for ipv6@ietf.org; Tue, 09 Mar 2004 19:17:51 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i2A0HGfX002470 for ; Tue, 9 Mar 2004 18:17:16 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Mar 2004 18:12:23 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 9 Mar 2004 18:16:49 -0600 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GPWW00M2; Tue, 9 Mar 2004 19:17:13 -0500 Date: Tue, 9 Mar 2004 19:16:31 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: Jyrki Soini cc: ipv6@ietf.org Subject: Re: ICMPv6 echo reply to multicast packet thread In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830D8F6B74@eammlex037.lmc.ericsson.se> Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830FEC5BFA-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 10 Mar 2004 00:12:23.0578 (UTC) FILETIME=[5CA7BFA0:01C40634] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jyrki, Find comments inline. Regards Suresh On Mon, 8 Mar 2004, Jyrki Soini wrote: >The consequence is that the original Echo Request packet gets 100 000 >000 unicast Echo Reply messages back. I do not see anything wrong with this scenario. If I send an ICMP Echo Request to 100M nodes I MUST expect a Echo reply from 100M nodes. How about if I sent a DATA packet, which requires an ACK, to the group by mistake? > >Ping to multicast address has operational usage as debugging tool and >totally disabling reply to Echo Request message sent to an IPv6 >multicast address would not be a good solution. Agree. I would really like to have this. But if I had to choose between probabilistic echo replies or none, I would pick none. > >I see two alternatives to limit the Echo Reply to multicast packet >problem: >1. Limit Echo Reply packet to only be allowed on link-scope multicast > echo requests. >2. Require that hop-limit is set to for instance value 1 for the > Echo Reply packet. > Setting the hop limit to 1 does not help . If half my multicast group is across a router and I DO NOT KNOW this it would become impossible to debug multicast. So remove the SHOULD and replace it with either a MUST or a MUST NOT. "An Echo Reply MUST/MUST NOT be sent in response to an Echo Request message sent to an IPv6 multicast or anycast address" This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 9 19:36:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09621 for ; Tue, 9 Mar 2004 19:36:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rhf-0006wb-MG for ipv6-archive@odin.ietf.org; Tue, 09 Mar 2004 19:36:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A0a7oN026687 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 19:36:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rhf-0006wM-Hj for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 19:36:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09612 for ; Tue, 9 Mar 2004 19:36:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0rhe-0005xo-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 19:36:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0rgb-0005oE-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 19:35:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0rfn-0005fY-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 19:34:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rfd-0006di-G6; Tue, 09 Mar 2004 19:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rfb-0006dT-Mx for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 19:33:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09515 for ; Tue, 9 Mar 2004 19:33:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0rfa-0005dx-00 for ipv6@ietf.org; Tue, 09 Mar 2004 19:33:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0rec-0005Sm-00 for ipv6@ietf.org; Tue, 09 Mar 2004 19:32:58 -0500 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1B0rdd-00059b-00 for ipv6@ietf.org; Tue, 09 Mar 2004 19:31:57 -0500 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 5A3C286F1; Wed, 10 Mar 2004 01:31:44 +0100 (CET) From: "Jeroen Massar" To: "'Suresh Krishnan'" , "'Jyrki Soini'" Cc: Subject: RE: ICMPv6 echo reply to multicast packet thread Date: Wed, 10 Mar 2004 01:30:49 +0100 Organization: Unfix MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830FEC5BFA-100000@eammlex037.lmc.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQGNYD4SCJTLyr3QYGxZsCXpbvqhwAADrow Message-Id: <20040310003144.5A3C286F1@purgatory.unfix.org> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Suresh Krishnan wrote: > Hi Jyrki, > Find comments inline. > > Regards > Suresh > > On Mon, 8 Mar 2004, Jyrki Soini wrote: > > >The consequence is that the original Echo Request packet gets 100 000 > >000 unicast Echo Reply messages back. > > I do not see anything wrong with this scenario. If I send an > ICMP Echo > Request to 100M nodes I MUST expect a Echo reply from 100M nodes. How > about if I sent a DATA packet, which requires an ACK, to the group by > mistake? I guess that Jyrki's thoughts where more along the lines of: "What if I send a simple ICMPv6 Echo Request with *your* source address". The only real solution for this of course is filtering, but I am not going to see that happen knowing that quite a number, make that most, IPv4 based ISP's don't filter their customers on source addresses. Even RFC1918 addresses seem to be unfiltered at most ISP's. Talking about source filtering here, which should be very easy as you know yourself as an ISP which prefixes one assigned to that user or simply to yourself as an ISP, a simple "source !myprefix drop" entry in your peering/transit router fixes this all, better stick as close to the client as possible et voila. But then still other ISP's don't and you are still vulnerable. > >Ping to multicast address has operational usage as debugging tool and > >totally disabling reply to Echo Request message sent to an IPv6 > >multicast address would not be a good solution. > > Agree. I would really like to have this. But if I had to > choose between probabilistic echo replies or none, I would pick none. None would indeed be better as then you are not thinking "but maybe they have configured it to not do it". This is somewhat the same problem that occured when there where a lot of icmp attacks over unicast and Cisco set a default ratelimit on their routers, after some time even simple traceroutes would not work anymore due to this. The Mtrace method is the real answer to debugging multicast. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQE5huAAAYiMAn3LsXEQRPtuMYKmIBTMiYXqa W8Y1AJ9PDUb7zbDAP6psz3w2GycZq/R4xA== =LHVq -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 9 20:06:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10529 for ; Tue, 9 Mar 2004 20:06:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sAe-0000L4-BD for ipv6-archive@odin.ietf.org; Tue, 09 Mar 2004 20:06:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A164jI001296 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 20:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sAe-0000Kp-6A for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 20:06:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10506 for ; Tue, 9 Mar 2004 20:06:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0sAc-000362-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 20:06:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0s9h-0002vA-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 20:05:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0s8y-0002k0-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 20:04:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0s8g-0008AU-8P; Tue, 09 Mar 2004 20:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0s7w-00085W-6C for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 20:03:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10377 for ; Tue, 9 Mar 2004 20:03:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0s7u-0002Yb-00 for ipv6@ietf.org; Tue, 09 Mar 2004 20:03:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0s73-0002Ns-00 for ipv6@ietf.org; Tue, 09 Mar 2004 20:02:21 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1B0s6O-0002Bh-00 for ipv6@ietf.org; Tue, 09 Mar 2004 20:01:40 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i2A113Lc013119 for ; Tue, 9 Mar 2004 19:01:03 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Mar 2004 18:56:18 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 9 Mar 2004 19:00:44 -0600 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GPWW005Q; Tue, 9 Mar 2004 20:01:07 -0500 Date: Tue, 9 Mar 2004 20:00:25 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: Jeroen Massar cc: "'Suresh Krishnan'" , "'Jyrki Soini'" , Subject: RE: ICMPv6 echo reply to multicast packet thread In-Reply-To: <20040310003144.5A3C286F1@purgatory.unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 10 Mar 2004 00:56:18.0609 (UTC) FILETIME=[7F419210:01C4063A] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jeroen, Find comments inline. Regards Suresh On Wed, 10 Mar 2004, Jeroen Massar wrote: >I guess that Jyrki's thoughts where more along the lines of: >"What if I send a simple ICMPv6 Echo Request with *your* source address". Aha. That makes more sense to me. But why should we point to just ICMPv6 Echo request? Pretty much all data packets which need an ack can be used for this attack. It could be any protocol, not just ICMPv6. Anyway all the more reason for a MUST NOT. > >The only real solution for this of course is filtering, but I am >not going to see that happen knowing that quite a number, make >that most, IPv4 based ISP's don't filter their customers on source >addresses. Even RFC1918 addresses seem to be unfiltered at most ISP's. >Talking about source filtering here, which should be very easy as >you know yourself as an ISP which prefixes one assigned to that user >or simply to yourself as an ISP, a simple "source !myprefix drop" >entry in your peering/transit router fixes this all, better stick >as close to the client as possible et voila. I agree. > >But then still other ISP's don't and you are still vulnerable. > >> >Ping to multicast address has operational usage as debugging tool and >> >totally disabling reply to Echo Request message sent to an IPv6 >> >multicast address would not be a good solution. >> >> Agree. I would really like to have this. But if I had to >> choose between probabilistic echo replies or none, I would pick none. > >None would indeed be better as then you are not thinking "but maybe >they have configured it to not do it". Exactly. I would rather live without the uncertainity. > >This is somewhat the same problem that occured when there where >a lot of icmp attacks over unicast and Cisco set a default ratelimit >on their routers, after some time even simple traceroutes would >not work anymore due to this. > >The Mtrace method is the real answer to debugging multicast. Didn't know mtrace worked with v6 addresses. Is there an implementation out there for IPv6? Would be cool to have. > > Sorry. Can't help it. It is appended by the mail server ;-). > >Greets, > Jeroen This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 9 20:16:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11119 for ; Tue, 9 Mar 2004 20:16:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sKZ-0001Fh-A3 for ipv6-archive@odin.ietf.org; Tue, 09 Mar 2004 20:16:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A1GJ1M004812 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 20:16:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sKZ-0001FX-3p for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 20:16:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11047 for ; Tue, 9 Mar 2004 20:16:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0sKX-0004xw-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 20:16:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0sJX-0004lt-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 20:15:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0sIa-0004ax-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 20:14:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sIL-0000u3-9l; Tue, 09 Mar 2004 20:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0sHU-0000tP-MR for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 20:13:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10939 for ; Tue, 9 Mar 2004 20:13:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0sHS-0004P0-00 for ipv6@ietf.org; Tue, 09 Mar 2004 20:13:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0sGY-0004FB-00 for ipv6@ietf.org; Tue, 09 Mar 2004 20:12:10 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1B0sFv-00043I-00 for ipv6@ietf.org; Tue, 09 Mar 2004 20:11:31 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i2A1AtLc014671 for ; Tue, 9 Mar 2004 19:10:55 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Mar 2004 19:06:09 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 9 Mar 2004 19:10:35 -0600 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GPWW000L; Tue, 9 Mar 2004 20:10:54 -0500 Date: Tue, 9 Mar 2004 20:10:13 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Ralph Droms , Subject: Re: reference dependency (DS to PS) (Re: [rfc2462bis] M/O flags and DHCPv6) In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830D8F6B78@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-OriginalArrivalTime: 10 Mar 2004 01:06:09.0671 (UTC) FILETIME=[DF8E7970:01C4063B] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Hi Jinmei, Don't if it is concrete or not but Section 4.2.4 of RFC2026 states Note: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. (See Section 7.) Since PS is lower than DS on the maturity level, a DS spec cannot have a normative reference to a PS spec. Regards Suresh On Tue, 9 Mar 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: >>>>>> On Thu, 04 Mar 2004 03:00:08 -0500, >>>>>> Ralph Droms said: > >> Jinmei - I mistyped and you guessed what I had intended to ask. Good catch >> and thanks for the clarification. > >> Can anyone supply a direct reference to an explicit statement that "a DS >> spec cannot have a normative reference to a PS spec."? > >I've not seen any responses yet...I guess we could deal with the >original issue with leaving this open, but it's still very helpful to >clarify this point to make a realistic decision. > >If no one can give a concrete pointer, I'll assume "a DS spec cannot >have a normative reference to a PS spec" for safety. > > 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 >-------------------------------------------------------------------- > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 9 22:07:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14517 for ; Tue, 9 Mar 2004 22:07:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0u3t-0006pq-Em for ipv6-archive@odin.ietf.org; Tue, 09 Mar 2004 22:07:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A37DU1026268 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 22:07:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0u3t-0006pb-3e for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 22:07:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14469 for ; Tue, 9 Mar 2004 22:07:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0u3q-00075Y-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 22:07:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0u2x-0006ve-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 22:06:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0u2J-0006m6-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 22:05:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0u1o-0006P5-6F; Tue, 09 Mar 2004 22:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0u15-0006My-1f for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 22:04:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14327 for ; Tue, 9 Mar 2004 22:04:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0u11-0006a2-00 for ipv6@ietf.org; Tue, 09 Mar 2004 22:04:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0tzx-0006NP-00 for ipv6@ietf.org; Tue, 09 Mar 2004 22:03:09 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B0tyw-0006Bh-00 for ipv6@ietf.org; Tue, 09 Mar 2004 22:02:07 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2A328GG022063 for ; Tue, 9 Mar 2004 20:02:08 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i2A30nxO018786 for ; Tue, 9 Mar 2004 21:00:51 -0600 Received: from motorola.com (10.232.1.134 [10.232.1.134]) by zin05exm02.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.2) id F5D4T394; Wed, 10 Mar 2004 08:32:02 +0530 Message-ID: <404E8525.A4F5DEE@motorola.com> Date: Wed, 10 Mar 2004 08:31:57 +0530 From: Bhaskar S Organization: Motorola India Electronics Limited X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipv6@ietf.org CC: Bhaskar S-A13895 Subject: Question regarding router redirect Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have a question regarding IPv6 router redirect. Can an IPv6 router send a redirect for a particular route? Here is a situation: (It is assumed that no routing protocol is being run) Internet | R1 +---+-----------+------+-----+ | | R2 H1 | H2 Let us say Router R1 is the default router for H1. R1 connects H1 to internet (IPv6). Also Router R1, R2 and H1 are all on the same link. H2 is connected to Router R2. If host H1 wants to reach H2 can router R1 redirect it to R2 for this particular route? Or will H1 be able to learn about H2 from R2 router advertisements? -- Thanks and Regards, Bhaskar S. Ph: 5598615-4012 ************************************************** [ ] General Business Information [x] Motorola Internal Use only [ ] Motorola Confidential Proprietary POPI - A Responsibility we all share ************************************************** -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 10 00:57:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20847 for ; Wed, 10 Mar 2004 00:57:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0wia-000736-61 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 00:57:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A5vNAa027088 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 00:57:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0wiZ-00072p-AM for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 00:57:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20825 for ; Wed, 10 Mar 2004 00:57:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0wiW-0003eG-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 00:57:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0whW-0003Ue-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 00:56:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0wgw-0003La-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 00:55:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0wgK-0006lD-3r; Wed, 10 Mar 2004 00:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0wfX-0006kc-4L for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 00:54:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20750 for ; Wed, 10 Mar 2004 00:54:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0wfU-0003B9-00 for ipv6@ietf.org; Wed, 10 Mar 2004 00:54:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0weY-00032x-00 for ipv6@ietf.org; Wed, 10 Mar 2004 00:53:15 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1B0we5-0002tp-00 for ipv6@ietf.org; Wed, 10 Mar 2004 00:52:45 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2A5qBxJ115050; Wed, 10 Mar 2004 05:52:11 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2A5qFqk168320; Wed, 10 Mar 2004 06:52:16 +0100 Received: from zurich.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id GAA36300; Wed, 10 Mar 2004 06:52:08 +0100 Message-ID: <404EAD20.7F331E06@zurich.ibm.com> Date: Wed, 10 Mar 2004 06:52:32 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Bob Hinden CC: "Charles E. Perkins" , jarno.rajahalme@nokia.com, ipv6@ietf.org Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" References: <009CA59D1752DD448E07F8EB2F91175701FD0728@esebe004.ntc.nokia.com> <404D843E.D4EDAE92@zurich.ibm.com> <4.3.2.7.2.20040309113229.024e1320@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes, I appologise for accidentally resurrecting the fixed charge, by typing "is suggested" when my brain was thinking "was suggested." We did indeed all agree to delegate *that* choice to IANA. Brian Bob Hinden wrote: > > Charlie, > > >I think that the fixed charge is a mistake, and > >should be avoided. > > I trust that everyone commenting on this has actually read the current > draft. A fixed charge was removed several drafts ago. > > The current draft does not impose a fixed charge for a prefix, but instead > sets a requirement that the allocation authority implement a mechanism that > prevents hoarding. Specifically from section 3.2.1 Centrally Assigned > Global IDs: > > - Provide mechanisms that prevent hoarding of these allocations. > > .... > > The allocation service should include sufficient provisions to avoid > hoarding of numbers. This can be accomplished by various ways, for > example, requiring an exchange of documents, a verbal contact, or a > proof that the request is on behalf of a human rather than a machine. > The service may charge a small fee in order to cover its costs, but > the fee should be low enough to not create a barrier to anyone > needing one. The precise mechanisms should be decided by the > registration authority. > > Bob > > >To avoid hoarding, of course it would be good to > >avoid bugs. In case, that is considered impossible > >(sigh!) we can also demand that each address and/or > >prefix be accompanied by a certificate generated > >by IANA with a one-way hash to validate it. > >The hash is to be unforgeable. The certificate > >is to contain the time of issuance. > > > >Nobody is going to be able to present a billion > >certificates satisfying the time constraint that > >each one be separated by one or more seconds. > >This can be made to be machine verifiable also. > > > >Maybe there is another way, but in any case I > >strongly think the fixed charge should be avoided. > > > >And, finally, I assert that the bugs can be > >avoided anyway. It doesn't have to be more > >than a few hundred lines of code. > > > >Regards, > >Charlie P. > > > > > >Brian E Carpenter wrote: > > > > > > Jarno, this is exactly why the fixed charge is suggested - to make > > > the cost of bulk hoarding significant. > > > > > > And no, I don't want to imagine such a bug - I have more confidence than > > > that in IANA and the organisations IANA delegates to. > > > > > > Brian > > > > > > jarno.rajahalme@nokia.com wrote: > > > > > > > > Thomas Narten wrote: > > > > > why we can't make such assignments permanent. (Note: I'd agree with > > > > > you that the assignments shouldn't be permanent if there was a case to > > > > > be made that it may become necessary to reclaim them at some future > > > > > time. Is there?) > > > > > > > > > > > > > What if someone manages to hoard the address space and then starts to > > sell them? Assume a bug in the system managing the allocations and > > someone exploiting it and getting 1/2 of the whole address space that > > they now "own" for good. > > > > > > > > Maybe there should be a notion of reclaiming prefixes that should not > > have been allocated in the first place? > > > > > > > > Regards, > > > > > > > > Jarno -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 10 01:17:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21720 for ; Wed, 10 Mar 2004 01:17:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0x1x-0000Vm-8K for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 01:17:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A6HPBh001966 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 01:17:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0x1w-0000Vd-Tl for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 01:17:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21692 for ; Wed, 10 Mar 2004 01:17:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0x1t-0006pl-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 01:17:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0x0r-0006fR-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 01:16:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0wzt-0006Vj-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 01:15:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0wzf-0000AR-MF; Wed, 10 Mar 2004 01:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0wyv-00009G-C2 for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 01:14:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21495 for ; Wed, 10 Mar 2004 01:14:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0wys-0006LS-00 for ipv6@ietf.org; Wed, 10 Mar 2004 01:14:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0wxz-0006CD-00 for ipv6@ietf.org; Wed, 10 Mar 2004 01:13:20 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1B0wx5-00062a-00 for ipv6@ietf.org; Wed, 10 Mar 2004 01:12:23 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2A6COwr028179 for ; Tue, 9 Mar 2004 23:12:24 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUC001XLJWNPR@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Tue, 09 Mar 2004 23:12:24 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUC00KYMJWH3K@mail.sun.net> for ipv6@ietf.org; Tue, 09 Mar 2004 23:12:23 -0700 (MST) Date: Tue, 09 Mar 2004 22:12:15 -0800 From: Alain Durand Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" In-reply-to: <404EAD20.7F331E06@zurich.ibm.com> To: Brian E Carpenter Cc: ipv6@ietf.org, "Charles E. Perkins" , Bob Hinden , jarno.rajahalme@nokia.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <009CA59D1752DD448E07F8EB2F91175701FD0728@esebe004.ntc.nokia.com> <404D843E.D4EDAE92@zurich.ibm.com> <4.3.2.7.2.20040309113229.024e1320@mailhost.iprg.nokia.com> <404EAD20.7F331E06@zurich.ibm.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Mar 9, 2004, at 9:52 PM, Brian E Carpenter wrote: > Yes, I appologise for accidentally resurrecting the fixed charge, > by typing "is suggested" when my brain was thinking "was suggested." > > We did indeed all agree to delegate *that* choice to IANA. This is the part that bothers me. If we delegate the choice of the anti-hoarding mechanism to IANA, why don't we also delegate to IANA the decision to make the allocation permanent or reclaimable? - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 10 01:25:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22149 for ; Wed, 10 Mar 2004 01:25:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0x9X-00018G-TB for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 01:25:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A6PFsP004346 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 01:25:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0x9X-000181-OV for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 01:25:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22082 for ; Wed, 10 Mar 2004 01:25:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0x9U-0000Oo-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 01:25:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0x8V-0000DC-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 01:24:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0x7W-00000n-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 01:23:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0x7N-0000lr-N2; Wed, 10 Mar 2004 01:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0x6r-0000lH-MU for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 01:22:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21921 for ; Wed, 10 Mar 2004 01:22:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0x6o-0007fE-00 for ipv6@ietf.org; Wed, 10 Mar 2004 01:22:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0x5o-0007VY-00 for ipv6@ietf.org; Wed, 10 Mar 2004 01:21:24 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0x5U-0007M0-00 for ipv6@ietf.org; Wed, 10 Mar 2004 01:21:04 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2A6KJh23993; Wed, 10 Mar 2004 08:20:19 +0200 Date: Wed, 10 Mar 2004 08:20:19 +0200 (EET) From: Pekka Savola To: Jeroen Massar cc: "'Suresh Krishnan'" , "'Jyrki Soini'" , Subject: RE: ICMPv6 echo reply to multicast packet thread In-Reply-To: <20040310003144.5A3C286F1@purgatory.unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 10 Mar 2004, Jeroen Massar wrote: > > On Mon, 8 Mar 2004, Jyrki Soini wrote: > > >The consequence is that the original Echo Request packet gets 100 000 > > >000 unicast Echo Reply messages back. > > > > I do not see anything wrong with this scenario. If I send an ICMP > > Echo Request to 100M nodes I MUST expect a Echo reply from 100M > > nodes. How about if I sent a DATA packet, which requires an ACK, > > to the group by mistake? > > I guess that Jyrki's thoughts where more along the lines of: > "What if I send a simple ICMPv6 Echo Request with *your* source address". Note that when you send to a multicast address, your source address is checked to be RPF-wise correct, otherwise it's dropped in the multicast forwarding. So, I don't think spoofing is that feasible a scenario in "multicast ping". If we disallow ICMP Echo Request, what about other services (TCP/UDP) that may be listening at the receiver systems? Those could be likewise affected -- TCP SYN/ACK, or a UDP response packet could have tremendous effect on the network as well. Inevitably, we'll seem to be reaching to a conclusion that we cannot avoid this at the specification level -- but the solution lies at the concerned parties in the form of filtering. Note that this problem does not (really) exist if SSM is used, and this is easily prevented if draft-ietf-mboned-embeddedrp-02.txt is used (which are the only two reasonable options), as you can put in filters in your RP configuration, preventing anyone (except specific sources) from sending packets to the members of the group. -- 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 exim@www1.ietf.org Wed Mar 10 03:47:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26708 for ; Wed, 10 Mar 2004 03:47:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zN9-0004HQ-WB for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 03:47:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A8lRNU016422 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 03:47:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zN8-0004GV-KT for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 03:47:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26666 for ; Wed, 10 Mar 2004 03:47:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0zN6-0002CG-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 03:47:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0zM8-0001yw-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 03:46:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0zLB-0001oc-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 03:45:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zKs-0003mm-AJ; Wed, 10 Mar 2004 03:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zKD-0003ge-UA for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 03:44:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26545 for ; Wed, 10 Mar 2004 03:44:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0zKB-0001d6-00 for ipv6@ietf.org; Wed, 10 Mar 2004 03:44:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0zJ8-0001RW-00 for ipv6@ietf.org; Wed, 10 Mar 2004 03:43:18 -0500 Received: from mtagate7.de.ibm.com ([195.212.29.156]) by ietf-mx with esmtp (Exim 4.12) id 1B0zII-00017A-00 for ipv6@ietf.org; Wed, 10 Mar 2004 03:42:26 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2A8fov4054066; Wed, 10 Mar 2004 08:41:50 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2A8fo6W223616; Wed, 10 Mar 2004 09:41:51 +0100 Received: from zurich.ibm.com (gsine10.us.sine.ibm.com [9.14.6.40]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id JAA54308; Wed, 10 Mar 2004 09:41:43 +0100 Message-ID: <404ECF96.63D3FD28@zurich.ibm.com> Date: Wed, 10 Mar 2004 09:19:34 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Alain Durand CC: ipv6@ietf.org, "Charles E. Perkins" , Bob Hinden , jarno.rajahalme@nokia.com Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" References: <009CA59D1752DD448E07F8EB2F91175701FD0728@esebe004.ntc.nokia.com> <404D843E.D4EDAE92@zurich.ibm.com> <4.3.2.7.2.20040309113229.024e1320@mailhost.iprg.nokia.com> <404EAD20.7F331E06@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alain Durand wrote: > > On Mar 9, 2004, at 9:52 PM, Brian E Carpenter wrote: > > > Yes, I appologise for accidentally resurrecting the fixed charge, > > by typing "is suggested" when my brain was thinking "was suggested." > > > > We did indeed all agree to delegate *that* choice to IANA. > > This is the part that bothers me. If we delegate the choice of the > anti-hoarding mechanism to IANA, > why don't we also delegate to IANA the decision to make the allocation > permanent or reclaimable? Because (in my mind) the whole technical purpose of these assignments is permanence. The only reason I would want one is permanence. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 10 03:52:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27006 for ; Wed, 10 Mar 2004 03:52:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zRv-0004ws-A1 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 03:52:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A8qNmI019015 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 03:52:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zRt-0004wc-GX for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 03:52:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26950 for ; Wed, 10 Mar 2004 03:52:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0zRr-0003Cs-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 03:52:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0zQy-00031b-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 03:51:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0zPz-0002rS-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 03:50:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zPn-0004c2-O4; Wed, 10 Mar 2004 03:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0zPP-0004Zj-DV for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 03:49:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26866 for ; Wed, 10 Mar 2004 03:49:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0zPM-0002i5-00 for ipv6@ietf.org; Wed, 10 Mar 2004 03:49:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0zOa-0002VW-00 for ipv6@ietf.org; Wed, 10 Mar 2004 03:48:57 -0500 Received: from mignon.ki.iif.hu ([193.6.222.240]) by ietf-mx with esmtp (Exim 4.12) id 1B0zNd-0002Bz-00 for ipv6@ietf.org; Wed, 10 Mar 2004 03:47:57 -0500 Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id 87C405796; Wed, 10 Mar 2004 09:47:22 +0100 (CET) Received: from mignon.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21326-01-5; Wed, 10 Mar 2004 09:47:20 +0100 (CET) Received: by mignon.ki.iif.hu (Postfix, from userid 1003) id BCDAE57B3; Wed, 10 Mar 2004 09:47:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id BA9F557A8; Wed, 10 Mar 2004 09:47:20 +0100 (CET) Date: Wed, 10 Mar 2004 09:47:20 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Mattias Pettersson Cc: ipv6@ietf.org Subject: Re: Multiple DRs on a link In-Reply-To: <404E23A1.60700@ericsson.com> Message-ID: <20040310094331.Q10925@mignon.ki.iif.hu> References: <404E23A1.60700@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, 9 Mar 2004, Mattias Pettersson wrote: > Hi, > > [This issue spans some WGs but it originates from here I believe.] > > We've had a small discussion in NEMO about multiple default routers on a > link, and whether these DRs are allowed to advertise different prefix > sets or not. > > Think of this small network: > > > ISP A ISP B > \ / > Ra Rb > | | > -+-----+-----+- > | > H > > Further assume that Ra advertises prefix Pa and Rb advertises prefix Pb. > Host H will have two DRs, hear two prefixes and build addresses out of > the both. > > What I'm asking for is whether this scenario was ever considered > "broken" unless there is some form of coordination between Ra and Rb. I > seem to recall that there was a discussion on ipng/IPv6 on exactly this > long ago but on the other hand I can't find it. > > The reason for calling this scenario broken is that H must be careful > with what source address to use when sending to either default router > (and that is a requirement we can't put on a legacy IPv6 host). One can > assume that both ISPs perform ingress filtering. If H contructs a packet > with a source address Sa from Pa and: > > - sends it to Ra: > - the packet will be routed successfully > > - but if it was to send it to Rb instead: > - (1) ISP B would drop it due to ingress filtering, or > - (2) Rb would have to forward it to Ra, or > - (3) Rb would have to tunnel it to ISP A, or > - (4) Rb would have to send a redirect to H, or > - (5) Rb or ISP B would generate an ICMP error about bad source address > > Alternatives 2-5 are typically described in draft-huitema-multi6-hosts, > but they either: > - require some form of coordination between the routers and their > ISPs, or they > - require that the host H implement some additional mapping between > prefixes/source addresses and default routers. > > To H there is no difference between Ra and Rb. Both claim that they are > default routers. Now both should be able to forward any traffic from H. > But unless Ra and Rb are coordinated in some of the ways described above > or that host H implement _new_ requirements in > draft-huitema-multi6-hosts (which standard IPv6 hosts do not), then host > H will have to take a chance on what default router to use (last heard? > first heard?). If H happened to select Ra as default router, packets > with source Sa will go through, but no packets with source Sb. And > default router selection will not happen again until Ra becomes unreachable. > > So the question is: am I correct to regard this scenario as broken and > say it should not be encouraged? I also think that nobody plans to build > fixed networks like this, just for these reasons. However, people may > want to build NEMO-type of networks just like this, as it is convenient > when mobile routers are rather independent, they come and go, and each > connects to one ISP and each only advertises a prefix from its ISP. > Awkwardly, then it is more important than ever that the mobile routers > are cooperating otherwise legacy IPv6 hosts won't be able to get plain > connectivity. I think this is not broken at all. The host should select the correct prefix according to the source address selection rules. I tried this scenario approximately 3 years ago on a KAME stack and it was working correctly. Best Regards, Janos Mohacsi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 10 08:50:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08064 for ; Wed, 10 Mar 2004 08:50:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B145i-0006ts-Qn for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 08:49:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ADnkfP026512 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 08:49:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B145i-0006tD-JY for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 08:49:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08054 for ; Wed, 10 Mar 2004 08:49:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B145h-0000YE-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 08:49:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B144k-0000Lm-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 08:48:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B144N-0000Bt-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 08:48:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1442-0006TN-83; Wed, 10 Mar 2004 08:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B143b-0006Su-0U for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 08:47:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07991 for ; Wed, 10 Mar 2004 08:47:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B143Z-0000AX-00 for ipv6@ietf.org; Wed, 10 Mar 2004 08:47:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B142g-00002I-00 for ipv6@ietf.org; Wed, 10 Mar 2004 08:46:38 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1429-0007hc-00 for ipv6@ietf.org; Wed, 10 Mar 2004 08:46:06 -0500 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2ADk5Or005162 for ; Wed, 10 Mar 2004 13:46:05 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA29697 for ; Wed, 10 Mar 2004 13:46:03 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2ADk3007201 for ipv6@ietf.org; Wed, 10 Mar 2004 13:46:03 GMT Date: Wed, 10 Mar 2004 13:46:03 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Multiple DRs on a link Message-ID: <20040310134603.GB793@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <404E23A1.60700@ericsson.com> <20040310094331.Q10925@mignon.ki.iif.hu> <20040310133441.GA793@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040310133441.GA793@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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Mar 10, 2004 at 01:34:41PM +0000, Tim Chown wrote: > > For the multihoming side, look at > http://www.ietf.org/internet-drafts/draft-huitema-multi6-hosts-03.txt > where issues like in/egress filtering are discussed. [Sorry - I just realised I answered part of your question with your question :) but the discussion on multi6 on whether source address selection is enough is relevant if you haven't seen it...] I agree the issue spans multiple WGs and it would be good to ensure that there is agreement/convergence between thinking in those WGs (at least nemo, multi6 and ipv6). Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 10 10:21:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14750 for ; Wed, 10 Mar 2004 10:21:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15WU-0004W5-2l for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 10:21:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AFLUAa017360 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 10:21:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15WT-0004Vv-Sq for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 10:21:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14709 for ; Wed, 10 Mar 2004 10:21:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B15WR-0002dj-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 10:21:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B15Uj-00025N-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 10:19:43 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B15S5-0001Nb-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 10:16:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B15S2-0004Lm-LY for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 10:16:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15RC-0002CQ-9l; Wed, 10 Mar 2004 10:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15R2-000297-M4 for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 10:15:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13371 for ; Wed, 10 Mar 2004 10:15:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B15R0-00014I-00 for ipv6@ietf.org; Wed, 10 Mar 2004 10:15:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B15PO-0000Yh-00 for ipv6@ietf.org; Wed, 10 Mar 2004 10:14:11 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B15OG-0000HE-00 for ipv6@ietf.org; Wed, 10 Mar 2004 10:13:01 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2AFCwqY018593 for ; Wed, 10 Mar 2004 16:12:58 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Mar 2004 16:12:58 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYF4CZ0A; Wed, 10 Mar 2004 16:13:51 +0100 Message-ID: <404F2FBD.9030901@ericsson.com> Date: Wed, 10 Mar 2004 16:09:49 +0100 X-Sybari-Trust: bfdfaa41 2c4885b5 73569057 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohacsi Janos CC: ipv6@ietf.org Subject: Re: Multiple DRs on a link References: <404E23A1.60700@ericsson.com> <20040310094331.Q10925@mignon.ki.iif.hu> In-Reply-To: <20040310094331.Q10925@mignon.ki.iif.hu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2004 15:12:58.0084 (UTC) FILETIME=[2BBB0A40:01C406B2] Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Janos, Mohacsi Janos wrote: > > On Tue, 9 Mar 2004, Mattias Pettersson wrote: > > > > I think this is not broken at all. The host should select the correct > prefix according to the source address selection rules. I tried this > scenario approximately 3 years ago on a KAME stack and it was working > correctly. But what source address selection rules do you refer to? I saw Alper's response and I'm happy he pointed it out because I haven't been aware of it, but the wording there is really weak. Other than that I don't understand what rules in 3484 help here. I got rather familiar with the KAME stack during 1999-2001 and to my knowledge the default router selection is made once and the host sticks to that router as long as it is considered reachable. What source address being used doesn't matter to what next-hop is used. /Mattias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 10 10:26:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15224 for ; Wed, 10 Mar 2004 10:26:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15ag-0005DA-Pc for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 10:25:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AFPo4U020029 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 10:25:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15ag-0005Cv-EC for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 10:25:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15216 for ; Wed, 10 Mar 2004 10:25:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B15ae-0003kW-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 10:25:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B15Zt-0003ak-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 10:25:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B15ZF-0003Pr-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 10:24:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B15ZF-0004Xo-Jj for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 10:24:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15Yw-0004n3-CC; Wed, 10 Mar 2004 10:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15Xy-0004ei-6k for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 10:23:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14883 for ; Wed, 10 Mar 2004 10:22:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B15Xv-00037K-00 for ipv6@ietf.org; Wed, 10 Mar 2004 10:23:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B15Ws-0002ps-00 for ipv6@ietf.org; Wed, 10 Mar 2004 10:21:55 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B15Vo-0002VI-00 for ipv6@ietf.org; Wed, 10 Mar 2004 10:20:48 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i2AFKkYG026163 for ; Wed, 10 Mar 2004 16:20:47 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Mar 2004 16:20:20 +0100 Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GSL3AGWY; Wed, 10 Mar 2004 16:20:46 +0100 Message-ID: <404F3190.9010008@ericsson.com> Date: Wed, 10 Mar 2004 16:17:36 +0100 X-Sybari-Trust: 301caf7e 2c4885b5 73569057 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bhaskar S CC: ipv6@ietf.org Subject: Re: Question regarding router redirect References: <404E8525.A4F5DEE@motorola.com> In-Reply-To: <404E8525.A4F5DEE@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2004 15:20:20.0108 (UTC) FILETIME=[33328CC0:01C406B3] Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bhaskar S wrote: > Hi, > > I have a question regarding IPv6 router redirect. Can an IPv6 > router send a redirect for a particular route? > > Here is a situation: > (It is assumed that no routing protocol is being run) > > Internet > | > R1 > +---+-----------+------+-----+ > | | > R2 H1 > | > H2 > > Let us say Router R1 is the default router for H1. R1 connects > H1 to internet (IPv6). Also Router R1, R2 and H1 are all on the > same link. H2 is connected to Router R2. If host H1 wants to > reach H2 can router R1 redirect it to R2 for this particular > route? Yes, R1 will tell H1 that R2 is a better next hop. > > Or will H1 be able to learn about H2 from R2 router > advertisements? R2 shouldn't advertise on that (upper) link. /Mattias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 10 16:29:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07896 for ; Wed, 10 Mar 2004 16:29:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BGF-0000i1-O1 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 16:29:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ALT7kR002719 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 16:29:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BGF-0000hf-GS for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 16:29:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07853 for ; Wed, 10 Mar 2004 16:29:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1BGD-00071R-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 16:29:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1BFb-0006rw-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 16:28:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1BEs-0006eI-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 16:27:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BEE-0000ON-5v; Wed, 10 Mar 2004 16:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1BDW-0000Ne-LV for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 16:26:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07339 for ; Wed, 10 Mar 2004 16:26:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1BDU-0006KY-00 for ipv6@ietf.org; Wed, 10 Mar 2004 16:26:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1BBx-0005qy-00 for ipv6@ietf.org; Wed, 10 Mar 2004 16:24:42 -0500 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 with esmtp (Exim 4.12) id 1B1BAF-0005NZ-00 for ipv6@ietf.org; Wed, 10 Mar 2004 16:22:55 -0500 Received: from defiant.dfw.nostrum.com (IDENT:http@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id i2ALMfa04805; Wed, 10 Mar 2004 15:22:41 -0600 Received: from 66.150.60.2 (SquirrelMail authenticated user sprunk) by defiant.dfw.nostrum.com with HTTP; Wed, 10 Mar 2004 15:22:41 -0600 (CST) Message-ID: <41892.66.150.60.2.1078953761.squirrel@defiant.dfw.nostrum.com> In-Reply-To: References: <20040310003144.5A3C286F1@purgatory.unfix.org> Date: Wed, 10 Mar 2004 15:22:41 -0600 (CST) Subject: RE: ICMPv6 echo reply to multicast packet thread From: "Stephen Sprunk" To: "Suresh Krishnan" Cc: "Jeroen Massar" , "'Suresh Krishnan'" , "'Jyrki Soini'" , ipv6@ietf.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=PRIORITY_NO_NAME autolearn=no version=2.60 Suresh Krishnan said: > On Wed, 10 Mar 2004, Jeroen Massar wrote: >>I guess that Jyrki's thoughts where more along the lines of: >>"What if I send a simple ICMPv6 Echo Request with *your* source address". > > Aha. That makes more sense to me. But why should we point to just ICMPv6 > Echo request? Pretty much all data packets which need an ack can be used > for this attack. It could be any protocol, not just ICMPv6. Anyway all the > more reason for a MUST NOT. Wait a minute... Now we're talking about prohibiting ANY multicast app from responding unicast to multicasted data? That's a basic part of functionality that is assumed in many apps! Can someone explain why we're looking for a different solution to this behavior for IPv6 when the IPv4 behavior is already set in stone? For apps which may not even be aware which version they're using, why should IPv6 not respond in some or all cases when IPv4 always does? >>The only real solution for this of course is filtering, but I am >>not going to see that happen knowing that quite a number, make >>that most, IPv4 based ISP's don't filter their customers on source >>addresses. Even RFC1918 addresses seem to be unfiltered at most ISP's. >>Talking about source filtering here, which should be very easy as >>you know yourself as an ISP which prefixes one assigned to that user >>or simply to yourself as an ISP, a simple "source !myprefix drop" >>entry in your peering/transit router fixes this all, better stick >>as close to the client as possible et voila. I don't see the relevance of this to multicast, since RPF inherently stops all off-subnet spoofing. What problem are we trying to solve? S -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 10 20:44:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19802 for ; Wed, 10 Mar 2004 20:44:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1FFG-0006nE-2S for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 20:44:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B1iM5T026111 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 20:44:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1FFF-0006n1-Mh for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 20:44:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19795 for ; Wed, 10 Mar 2004 20:44:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1FFD-0007NK-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 20:44:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1FEC-0007DW-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 20:43:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1FDZ-00073T-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 20:42:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1FCz-0006PM-I4; Wed, 10 Mar 2004 20:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1FCJ-0006Om-CK for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 20:41:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19502 for ; Wed, 10 Mar 2004 20:41:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1FCH-0006p7-00 for ipv6@ietf.org; Wed, 10 Mar 2004 20:41:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1FBF-0006bP-00 for ipv6@ietf.org; Wed, 10 Mar 2004 20:40:14 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1B1FAL-0006Q6-00 for ipv6@ietf.org; Wed, 10 Mar 2004 20:39:17 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:adaf:3d21:3dbf:c495]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 48FFC15210; Thu, 11 Mar 2004 10:39:11 +0900 (JST) Date: Thu, 11 Mar 2004 10:39:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mattias Pettersson Cc: Bhaskar S , ipv6@ietf.org Subject: Re: Question regarding router redirect In-Reply-To: <404F3190.9010008@ericsson.com> References: <404E8525.A4F5DEE@motorola.com> <404F3190.9010008@ericsson.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Wed, 10 Mar 2004 16:17:36 +0100, >>>>> Mattias Pettersson said: >> Internet >> | >> R1 >> +---+-----------+------+-----+ >> | | >> R2 H1 >> | >> H2 >> >> Let us say Router R1 is the default router for H1. R1 connects >> H1 to internet (IPv6). Also Router R1, R2 and H1 are all on the >> same link. H2 is connected to Router R2. If host H1 wants to >> reach H2 can router R1 redirect it to R2 for this particular >> route? > Yes, R1 will tell H1 that R2 is a better next hop. >> >> Or will H1 be able to learn about H2 from R2 router >> advertisements? > R2 shouldn't advertise on that (upper) link. I think R2 actually should. Otherwise, H1 won't be able to communicate with H2 when R1 is down. So, both R1 and R2 should advertise RAs on the upper link (from R2). If the "redirect storms" really matter, we then should use a new feature described in draft-ietf-ipv6-router-selection-03.txt. 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 exim@www1.ietf.org Wed Mar 10 22:28:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23609 for ; Wed, 10 Mar 2004 22:28:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Grl-0004xw-6D for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 22:28:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B3SDlT019082 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 22:28:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Grk-0004xh-W2 for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 22:28:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23575 for ; Wed, 10 Mar 2004 22:28:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Grh-0007Gj-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 22:28:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Gqn-00077O-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 22:27:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Gq0-0006yu-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 22:26:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Gpf-0004aG-BD; Wed, 10 Mar 2004 22:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Gon-0004Yg-UX for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 22:25:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23447 for ; Wed, 10 Mar 2004 22:25:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Gok-0006na-00 for ipv6@ietf.org; Wed, 10 Mar 2004 22:25:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Gnm-0006eV-00 for ipv6@ietf.org; Wed, 10 Mar 2004 22:24:06 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1B1Gmt-0006OZ-00 for ipv6@ietf.org; Wed, 10 Mar 2004 22:23:11 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i2B3MYLc008533 for ; Wed, 10 Mar 2004 21:22:34 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Mar 2004 21:17:47 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 10 Mar 2004 21:22:13 -0600 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GPWXASP2; Wed, 10 Mar 2004 22:22:36 -0500 Date: Wed, 10 Mar 2004 22:21:51 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: Stephen Sprunk cc: Suresh Krishnan , Jeroen Massar , "'Jyrki Soini'" , Subject: RE: ICMPv6 echo reply to multicast packet thread In-Reply-To: <41892.66.150.60.2.1078953761.squirrel@defiant.dfw.nostrum.com> Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830FEC5BFB-100000@eammlex037.lmc.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 11 Mar 2004 03:17:47.0562 (UTC) FILETIME=[6D7AC0A0:01C40717] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Hi Stephen, Find comments inline. Regards Suresh On Wed, 10 Mar 2004, Stephen Sprunk wrote: >Suresh Krishnan said: >> On Wed, 10 Mar 2004, Jeroen Massar wrote: >>>I guess that Jyrki's thoughts where more along the lines of: >>>"What if I send a simple ICMPv6 Echo Request with *your* source address". >> >> Aha. That makes more sense to me. But why should we point to just ICMPv6 >> Echo request? Pretty much all data packets which need an ack can be used >> for this attack. It could be any protocol, not just ICMPv6. Anyway all the >> more reason for a MUST NOT. > >Wait a minute... Now we're talking about prohibiting ANY multicast app >from responding unicast to multicasted data? That's a basic part of >functionality that is assumed in many apps! > >Can someone explain why we're looking for a different solution to this >behavior for IPv6 when the IPv4 behavior is already set in stone? For >apps which may not even be aware which version they're using, why should >IPv6 not respond in some or all cases when IPv4 always does? The problem is not about apps responding unicast to multicast data. It is specifically only about apps sending unicast ICMPv6 Echo replies in response to ICMPv6 echo requests sent to multicast addresses. Everything else (all data packet behavior) is not under discussion here. The statement about IP4v4 always responding to multicast echo requests is not entirely true. The expected IPv4 host behavior is described in RFC 1122 3.2.2.6 Echo Request/Reply: RFC-792 Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies. A host SHOULD also implement an application-layer interface for sending an Echo Request and receiving an Echo Reply, for diagnostic purposes. An ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded. So an IPV4 may or may not respond to an ICMP echo request message. In IPv6 we have a chance to take away this uncertainity and replace it with either a host MUST respond or a host MUST NOT respond to ICMP echo requests sent to a multicast address. This takes out the guesswork about "is the host down or did the admin configure it to not respond to echo requests?". > >>>The only real solution for this of course is filtering, but I am >>>not going to see that happen knowing that quite a number, make >>>that most, IPv4 based ISP's don't filter their customers on source >>>addresses. Even RFC1918 addresses seem to be unfiltered at most ISP's. >>>Talking about source filtering here, which should be very easy as >>>you know yourself as an ISP which prefixes one assigned to that user >>>or simply to yourself as an ISP, a simple "source !myprefix drop" >>>entry in your peering/transit router fixes this all, better stick >>>as close to the client as possible et voila. > >I don't see the relevance of this to multicast, since RPF inherently stops >all off-subnet spoofing. What problem are we trying to solve? I did not write the above passage even though you attributed it to me ;-). > >S > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 01:31:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01206 for ; Thu, 11 Mar 2004 01:31:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Jj1-0000qv-V0 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 01:31:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B6VN31003270 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 01:31:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Jj1-0000qc-PP for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 01:31:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01171 for ; Thu, 11 Mar 2004 01:31:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Jiy-0004JM-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 01:31:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Ji4-000480-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 01:30:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Jh9-0003yO-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 01:29:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Jgk-0000UR-C1; Thu, 11 Mar 2004 01:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1JgJ-0000SO-7Z for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 01:28:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01074 for ; Thu, 11 Mar 2004 01:28:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1JgG-0003mU-00 for ipv6@ietf.org; Thu, 11 Mar 2004 01:28:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1JfE-0003ba-00 for ipv6@ietf.org; Thu, 11 Mar 2004 01:27:28 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B1JeV-0003Ro-00 for ipv6@ietf.org; Thu, 11 Mar 2004 01:26:43 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 653AF8996C; Thu, 11 Mar 2004 08:26:37 +0200 (EET) Message-ID: <40500617.9030301@kolumbus.fi> Date: Thu, 11 Mar 2004 08:24:23 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: "'Jyrki Soini'" , ipv6@ietf.org Subject: Re: ICMPv6 echo reply to multicast packet thread References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > Note that when you send to a multicast address, your source address is > checked to be RPF-wise correct, otherwise it's dropped in the > multicast forwarding. So, I don't think spoofing is that feasible a > scenario in "multicast ping". Right. I think this protection is good enough that we can generally rely on it, as long as the remaining case (on path attacker) is understood and mentioned in the security considerations. > If we disallow ICMP Echo Request, what about other services (TCP/UDP) > that may be listening at the receiver systems? Those could be > likewise affected -- TCP SYN/ACK, or a UDP response packet could have > tremendous effect on the network as well. Yes. A couple of comments: - Some of those applications might not be answering if the destination address is a multicast address. So this may not apply to all applications. But it would apply to some. - As discussed in the context of the ICMPv6 spec revision, there are similar multicast respond flooding issues even with base IPv6 processing before you get to any "application" such as ping. Unrecognized destination option, for instance, would cause a flood of responses. In general, we may not wish to limit the ability of applications to respond to multicast, that may be needed in some cases. However, applications that do respond to multicast probably want to say something about the remaining case in their security considerations section. Some applications may also use some form of source authentication to ensure that only the legitimate sender's messages are processed. This still leaves open what the behaviour for ICMPv6 Echo Request should be. I would not bundle this issue with what the other applications do, but my default answer would be to not respond to multicast requests unless there is a specific reason to do so. In this case there seems to be some discussion about multicast debugging capabilities. I do not have experience of that myself. Are multicast echo requests the primary multicast debugging mechanism? If yes, we should allow responses to be sent. If not, I agree with Suresh that it should be disallowed. Note that multicast debugging through echo responses is naturally limited to rather small multicast groups ;-) So I suspect people who need multicast in a large scale are going to need another debugging tool in any case. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 01:58:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02150 for ; Thu, 11 Mar 2004 01:58:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1K94-00045U-TT for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 01:58:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B6wI1m015711 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 01:58:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1K94-00045K-NY for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 01:58:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02083 for ; Thu, 11 Mar 2004 01:58:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1K91-0000am-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 01:58:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1K81-0000Qp-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 01:57:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1K72-0000HI-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 01:56:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1K6t-0003ha-AD; Thu, 11 Mar 2004 01:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1K6F-0003gJ-9W for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 01:55:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01997 for ; Thu, 11 Mar 2004 01:55:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1K6B-0000AH-00 for ipv6@ietf.org; Thu, 11 Mar 2004 01:55:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1K5J-000027-00 for ipv6@ietf.org; Thu, 11 Mar 2004 01:54:26 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B1K4b-0007hn-00 for ipv6@ietf.org; Thu, 11 Mar 2004 01:53:42 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6337B89969; Thu, 11 Mar 2004 08:53:42 +0200 (EET) Message-ID: <40500C70.90306@kolumbus.fi> Date: Thu, 11 Mar 2004 08:51:28 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown , "Mattias Pettersson L (KI/EAB)" Cc: ipv6@ietf.org Subject: Re: Multiple DRs on a link References: <404E23A1.60700@ericsson.com> <20040310094331.Q10925@mignon.ki.iif.hu> <20040310133441.GA793@login.ecs.soton.ac.uk> <20040310134603.GB793@login.ecs.soton.ac.uk> In-Reply-To: <20040310134603.GB793@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tim Chown wrote: > I agree the issue spans multiple WGs and it would be good to ensure that > there is agreement/convergence between thinking in those WGs (at least nemo, > multi6 and ipv6). Right. In addition, the SEND WG had an issue about this as well, when they debated the semantics of prefixes in router certificates. (They decided to stick with the IPv6 RA semantics. That is, SEND hopes someone else, maybe multi6, will make it clearer what the rules are.) I have also seen the RFC 3484 rules, and I agree with others that they are somewhat vague. In any case, multi6 is already discussing this so eventually there will be a spec that will guide us. However, in any case when there are multiple routers with different prefixes on the same link, currently implemented IPv6 hosts may make the wrong decision. Certainly at least those nodes that predate RFC 3484. But I have a question about the NEMO case. I had assumed that mobile routers move around and attach their egress interface to various place in the internet. And that their ingress interface serves a number of hosts, unaware of the movements. I don't see the default router selection as an issue in this scenario, as the hosts will stick to the same mobile router all the time, and the mobile router acts like a host on its egress interface. So if the visited link works for hosts, it should work for mobile routers. But perhaps you are considering a situation where the ingress interface of two mobile routers may be shared, or that a mobile router's ingress interface may suddenly appear on some stationary network. If we allow this, there could be problems. Do we really need it? --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 02:13:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15231 for ; Thu, 11 Mar 2004 02:13:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1KNe-0000z0-1l for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 02:13:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B7DLWG003768 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 02:13:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1KNc-0000yQ-WC for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 02:13:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15107 for ; Thu, 11 Mar 2004 02:13:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1KNZ-0002qt-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 02:13:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1KMd-0002ed-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 02:12:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1KLf-0002TV-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 02:11:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1KLP-0008MH-9v; Thu, 11 Mar 2004 02:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1KKp-0008E9-DS for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 02:10:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14098 for ; Thu, 11 Mar 2004 02:10:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1KKl-0002JD-00 for ipv6@ietf.org; Thu, 11 Mar 2004 02:10:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1KJp-00029k-00 for ipv6@ietf.org; Thu, 11 Mar 2004 02:09:26 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B1KJL-0001zR-00 for ipv6@ietf.org; Thu, 11 Mar 2004 02:08:55 -0500 content-class: urn:content-classes:message Subject: RE: Multiple DRs on a link Date: Thu, 11 Mar 2004 02:08:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Multiple DRs on a link X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQHNfD1BN+cUTkETi6jMRqxHMCCGAAAFcIQ From: "Soliman Hesham" To: "Jari Arkko" , "Tim Chown" , "Mattias Pettersson L (KI/EAB)" Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Right. In addition, the SEND WG had an issue about this as well, when > they debated the semantics of prefixes in router certificates. (They > decided to stick with the IPv6 RA semantics. That is, SEND hopes > someone else, maybe multi6, will make it clearer what the rules are.) >=20 > I have also seen the RFC 3484 rules, and I agree with others that > they are somewhat vague. In any case, multi6 is already discussing > this so eventually there will be a spec that will guide us. However, > in any case when there are multiple routers with different prefixes > on the same link, currently implemented IPv6 hosts may make the > wrong decision. Certainly at least those nodes that predate RFC 3484. =3D> I think even the nodes that implement 3484 may make the=20 wrong decision. The text that Alper sent is not "standards text" and I suspect there are implementations (e.g. BSD) that don't follow this. >=20 > But I have a question about the NEMO case. I had assumed that mobile > routers move around and attach their egress interface to various > place in the internet. And that their ingress interface serves > a number of hosts, unaware of the movements. I don't see the > default router selection as an issue in this scenario, as the > hosts will stick to the same mobile router all the time, and > the mobile router acts like a host on its egress interface. So > if the visited link works for hosts, it should work for mobile > routers. =3D> The problem is when you have 2 MRs, each advertising a different prefix (i.e. different home prefix). Hesham >=20 > But perhaps you are considering a situation where the ingress > interface of two mobile routers may be shared, or that a mobile > router's ingress interface may suddenly appear on some stationary > network. If we allow this, there could be problems. Do we really > need it? >=20 > --Jari >=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 exim@www1.ietf.org Thu Mar 11 02:33:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16862 for ; Thu, 11 Mar 2004 02:33:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Kh7-0006Kc-9d for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 02:33:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B7XTkV024337 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 02:33:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Kh6-0006KS-PP for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 02:33:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16836 for ; Thu, 11 Mar 2004 02:33:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Kh3-0005tt-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 02:33:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Kg6-0005kA-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 02:32:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1KfJ-0005bH-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 02:31:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Ket-0005rk-Fg; Thu, 11 Mar 2004 02:31:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1KeA-0005oT-1z for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 02:30:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16683 for ; Thu, 11 Mar 2004 02:30:23 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Ke6-0005R8-00 for ipv6@ietf.org; Thu, 11 Mar 2004 02:30:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1KdC-0005Aj-00 for ipv6@ietf.org; Thu, 11 Mar 2004 02:29:27 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B1Kcl-000524-00 for ipv6@ietf.org; Thu, 11 Mar 2004 02:28:59 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2B7SwA13072; Thu, 11 Mar 2004 09:28:58 +0200 (EET) X-Scanned: Thu, 11 Mar 2004 09:28:42 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2B7SgUp022735; Thu, 11 Mar 2004 09:28:42 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00noA10V; Thu, 11 Mar 2004 09:28:41 EET 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 i2B7SeH18575; Thu, 11 Mar 2004 09:28:40 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Mar 2004 23:28:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ICMPv6 echo reply to multicast packet thread Date: Thu, 11 Mar 2004 01:28:39 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F799CB@daebe009.americas.nokia.com> Thread-Topic: ICMPv6 echo reply to multicast packet thread Thread-Index: AcQHMkyIsXekvBRGRGOOf22xHDaXKQAB1uZg To: , Cc: , X-OriginalArrivalTime: 11 Mar 2004 07:28:40.0020 (UTC) FILETIME=[79719140:01C4073A] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > - As discussed in the context of the ICMPv6 spec revision, there are > similar multicast respond flooding issues even with base IPv6 > processing before you get to any "application" such as ping. > Unrecognized destination option, for instance, would cause a > flood of responses. This has been described as point 5 in the Security Considerations=20 section of the latest draft (draft-ietf-ipngwg-icmp-v3-03.txt). > In general, we may not wish to limit the ability of applications > to respond to multicast, that may be needed in some cases. However, > applications that do respond to multicast probably want to say > something about the remaining case in their security considerations > section. Some applications may also use some form of source=20 > authentication to ensure that only the legitimate sender's messages=20 > are processed. I agree. > This still leaves open what the behaviour for ICMPv6 Echo Request > should be. I would not bundle this issue with what the other > applications do, but my default answer would be to not respond > to multicast requests unless there is a specific reason to do > so. In this case there seems to be some discussion about multicast > debugging capabilities. I do not have experience of that myself. > Are multicast echo requests the primary multicast debugging > mechanism? If yes, we should allow responses to be sent. If not, > I agree with Suresh that it should be disallowed. Note that > multicast debugging through echo responses is naturally limited > to rather small multicast groups ;-) So I suspect people who > need multicast in a large scale are going to need another > debugging tool in any case. I do not have any preferences here either. I agree with Pekka that it should be either MUST or MUST NOT. Leaving it as a=20 SHOULD is not a good idea. Now, who can tell if multicast echo request is the primary=20 multicast debugging mechanism or not ?? Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 08:39:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01357 for ; Thu, 11 Mar 2004 08:39:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1QOT-0003lh-Fc for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 08:38:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BDcbN8014484 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 08:38:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1QOT-0003lX-7k for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 08:38:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01329 for ; Thu, 11 Mar 2004 08:38:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1QOS-0001E5-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 08:38:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1QNU-00015H-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 08:37:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1QMc-0000xb-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 08:36:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1QLy-00038p-Kq; Thu, 11 Mar 2004 08:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1QLU-00037W-Gp for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 08:35:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01230 for ; Thu, 11 Mar 2004 08:35:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1QLT-0000oa-00 for ipv6@ietf.org; Thu, 11 Mar 2004 08:35:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1QKb-0000gr-00 for ipv6@ietf.org; Thu, 11 Mar 2004 08:34:37 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B1QJm-0000XQ-00 for ipv6@ietf.org; Thu, 11 Mar 2004 08:33:46 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E76B389851; Thu, 11 Mar 2004 15:33:44 +0200 (EET) Message-ID: <40506A32.2000707@kolumbus.fi> Date: Thu, 11 Mar 2004 15:31:30 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: "Mattias Pettersson L (KI/EAB)" , ipv6@ietf.org Subject: Re: Multiple DRs on a link References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Soliman Hesham wrote: > => There are many different reasons. I sent a verly long > email about this to nemo (monet back then). One simple > scenario is that you might be walking around with a PAN > that happens to have 2 MRs on a single link (e.g. a laptop > and a mobile phone). The two MRs could share the same ingress > link and have different egress links. For instance your laptop > might have a WLAN card and your mobile might have a cellular > interface. Once you walk into an airport lounge or starbucks > you'll suddenly have a multihomed PAN. By definition, each MR > must have a separate home prefix. So each will advertise > a different prefix on the ingress side. > Other uses my include redundancy (e.g. a train company providing > WLAN access on the train). In this case two MRs may be used > and they have to advertise different home prefixes. The scenarios seem valid. Note that from the hosts' perspective the same scenarios will have an ingress filtering issue whether or not NEMO is being used to provide session continuity and stable addressing. But we knew that this is an issue even without NEMO. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 08:56:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02025 for ; Thu, 11 Mar 2004 08:56:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Qev-0005Gl-Br for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 08:55:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BDtb3N020252 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 08:55:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Qeu-0005GZ-UB for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 08:55:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02010 for ; Thu, 11 Mar 2004 08:55:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Qet-0003Wi-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 08:55:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Qe0-0003PU-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 08:54:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Qdh-0003IA-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 08:54:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1QdN-0004vt-V0; Thu, 11 Mar 2004 08:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Qd1-0004qO-Tu for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 08:53:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01925 for ; Thu, 11 Mar 2004 08:53:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Qd0-0003Gw-00 for ipv6@ietf.org; Thu, 11 Mar 2004 08:53:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Qc6-00039T-00 for ipv6@ietf.org; Thu, 11 Mar 2004 08:52:43 -0500 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 with esmtp (Exim 4.12) id 1B1Qbb-000325-00 for ipv6@ietf.org; Thu, 11 Mar 2004 08:52:11 -0500 Received: from defiant.dfw.nostrum.com (IDENT:http@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id i2BDq2a26940; Thu, 11 Mar 2004 07:52:02 -0600 Received: from 66.150.60.2 (SquirrelMail authenticated user sprunk) by defiant.dfw.nostrum.com with HTTP; Thu, 11 Mar 2004 07:52:02 -0600 (CST) Message-ID: <25102.66.150.60.2.1079013122.squirrel@defiant.dfw.nostrum.com> In-Reply-To: <40500617.9030301@kolumbus.fi> References: <40500617.9030301@kolumbus.fi> Date: Thu, 11 Mar 2004 07:52:02 -0600 (CST) Subject: Re: ICMPv6 echo reply to multicast packet thread From: "Stephen Sprunk" To: "Jari Arkko" Cc: "Pekka Savola" , "'Jyrki Soini'" , ipv6@ietf.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=PRIORITY_NO_NAME autolearn=no version=2.60 Jari Arkko said: > Pekka Savola wrote: >> Note that when you send to a multicast address, your source address is >> checked to be RPF-wise correct, otherwise it's dropped in the >> multicast forwarding. So, I don't think spoofing is that feasible a >> scenario in "multicast ping". > > Right. I think this protection is good enough that we can > generally rely on it, as long as the remaining case (on path > attacker) is understood and mentioned in the security > considerations. With the noted exception, do we have consensus that multicast ping is not useful as a DoS attack vector? > In general, we may not wish to limit the ability of applications > to respond to multicast, that may be needed in some cases. However, > applications that do respond to multicast probably want to say > something about the remaining case in their security considerations > section. Some applications may also use some form of source authentication > to ensure that only the legitimate sender's messages are processed. I don't think anyone would object to individual protocols being hardened, or at least studied, for multicast-specific security problems. > This still leaves open what the behaviour for ICMPv6 Echo Request > should be. I would not bundle this issue with what the other > applications do, but my default answer would be to not respond > to multicast requests unless there is a specific reason to do > so. In this case there seems to be some discussion about multicast > debugging capabilities. I do not have experience of that myself. > Are multicast echo requests the primary multicast debugging > mechanism? If yes, we should allow responses to be sent. If not, > I agree with Suresh that it should be disallowed. Note that > multicast debugging through echo responses is naturally limited > to rather small multicast groups ;-) So I suspect people who > need multicast in a large scale are going to need another > debugging tool in any case. IMHO, a multicast ping is the only tool that is simple enough and ubiquitous enough for end users to attempt diagnostics before calling their support folks -- one simple command tells you whether your problems are at the network layer or application layer. I say keep it. S -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 09:11:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02664 for ; Thu, 11 Mar 2004 09:11:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1QtS-0000jy-Bg for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 09:10:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BEAcft002835 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 09:10:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1QtR-0000je-Co for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 09:10:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02654 for ; Thu, 11 Mar 2004 09:10:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1QtP-0005cm-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 09:10:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1QsV-0005Vq-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 09:09:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Qs9-0005Oh-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 09:09:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Qrt-0000RT-AN; Thu, 11 Mar 2004 09:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Qra-0000PK-0k for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 09:08:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02568 for ; Thu, 11 Mar 2004 09:08:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1QrY-0005Nu-00 for ipv6@ietf.org; Thu, 11 Mar 2004 09:08:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Qqd-0005GD-00 for ipv6@ietf.org; Thu, 11 Mar 2004 09:07:44 -0500 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 with esmtp (Exim 4.12) id 1B1QqL-00058O-00 for ipv6@ietf.org; Thu, 11 Mar 2004 09:07:25 -0500 Received: from defiant.dfw.nostrum.com (IDENT:http@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id i2BE5xa27267; Thu, 11 Mar 2004 08:05:59 -0600 Received: from 66.150.60.2 (SquirrelMail authenticated user sprunk) by defiant.dfw.nostrum.com with HTTP; Thu, 11 Mar 2004 08:06:00 -0600 (CST) Message-ID: <25799.66.150.60.2.1079013960.squirrel@defiant.dfw.nostrum.com> In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830FEC5BFB-100000@eammlex037.lmc.ericss on.se> References: <41892.66.150.60.2.1078953761.squirrel@defiant.dfw.nostrum.com> <7B2A7784F4B7F0409947481F3F3FEF830FEC5BFB-100000@eammlex037.lmc.ericss on.se> Date: Thu, 11 Mar 2004 08:06:00 -0600 (CST) Subject: RE: ICMPv6 echo reply to multicast packet thread From: "Stephen Sprunk" To: "Suresh Krishnan" Cc: "Stephen Sprunk" , "Suresh Krishnan " , "Jeroen Massar " , "'Jyrki Soini'" , ipv6@ietf.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Suresh Krishnan said: > On Wed, 10 Mar 2004, Stephen Sprunk wrote: >>Suresh Krishnan said: >>> Aha. That makes more sense to me. But why should we point to just >>> ICMPv6 Echo request? Pretty much all data packets which need an >>> ack can be used for this attack. It could be any protocol, not >>> just ICMPv6. Anyway all the more reason for a MUST NOT. >> >>Wait a minute... Now we're talking about prohibiting ANY multicast app >>from responding unicast to multicasted data? That's a basic part of >>functionality that is assumed in many apps! >> >>Can someone explain why we're looking for a different solution to this >>behavior for IPv6 when the IPv4 behavior is already set in stone? For >>apps which may not even be aware which version they're using, why should >>IPv6 not respond in some or all cases when IPv4 always does? > > The problem is not about apps responding unicast to multicast data. It is > specifically only about apps sending unicast ICMPv6 Echo replies in > response to ICMPv6 echo requests sent to multicast addresses. Everything > else (all data packet behavior) is not under discussion here. You pointed out that ICMP echo is not the only protocol this attack can (supposedly) use; my argument is that turning off ICMP echo replies is only useful if we prohibit all other apps from replying as well. Given the noted holes in other aspects of ICMP that still MUST respond in error conditions, we're just shifting the problem around without making it any more difficult for attackers. If they can't flood someone with Echo Replies, they'll just flood someone with Destination Unreachables (or some other response) -- assuming, of course, they find a way around RPF. > The statement about IP4v4 always responding to multicast echo requests > is not entirely true. The expected IPv4 host behavior is described in RFC > 1122 RFC 1122 Sec 3.2.2.6 is ambiguous. The only self-consistent reading I can find is that hosts MUST respond if they receive an echo request, but the _network_ may drop broadcast or multicast pings before delivering them. >>>>The only real solution for this of course is filtering, but I am >>>>not going to see that happen knowing that quite a number, make >>>>that most, IPv4 based ISP's don't filter their customers on source >>>>addresses. Even RFC1918 addresses seem to be unfiltered at most ISP's. >>>>Talking about source filtering here, which should be very easy as >>>>you know yourself as an ISP which prefixes one assigned to that user >>>>or simply to yourself as an ISP, a simple "source !myprefix drop" >>>>entry in your peering/transit router fixes this all, better stick >>>>as close to the client as possible et voila. >> >>I don't see the relevance of this to multicast, since RPF inherently >>stops all off-subnet spoofing. What problem are we trying to solve? > > I did not write the above passage even though you attributed it to me ;-). It's been quoted many times, but I figured it was worth responding to. S -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 13:02:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14005 for ; Thu, 11 Mar 2004 13:02:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1UV6-0000KH-FH for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 13:01:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BI1imn001252 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 13:01:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1UV6-0000K7-5z for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 13:01:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13959 for ; Thu, 11 Mar 2004 13:01:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1UV4-0007UK-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 13:01:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1UU6-0007LE-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 13:00:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1UT9-0007Cv-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 12:59:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1USU-0008PZ-3V; Thu, 11 Mar 2004 12:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1USC-0008Ll-Os for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 12:58:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13825 for ; Thu, 11 Mar 2004 12:58:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1USB-00075A-00 for ipv6@ietf.org; Thu, 11 Mar 2004 12:58:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1URN-0006yE-00 for ipv6@ietf.org; Thu, 11 Mar 2004 12:57:54 -0500 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx with esmtp (Exim 4.12) id 1B1UQu-0006qf-00 for ipv6@ietf.org; Thu, 11 Mar 2004 12:57:24 -0500 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id i2BHvMN8017764 for ; Thu, 11 Mar 2004 19:57:22 +0200 (EET) Received: from kallio.eur.soneragroup.net (kallio.eur.soneragroup.net [131.177.121.200]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id i2BHvLsU017742;Thu, 11 Mar 2004 19:57:21 +0200 (EET) Received: from teliasonera.com ([194.142.21.49]) by kallio.eur.soneragroup.net with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Mar 2004 19:57:21 +0200 Message-ID: <4050A87A.8040403@teliasonera.com> Date: Thu, 11 Mar 2004 19:57:14 +0200 From: Jyrki Soini Organization: TeliaSonera Finland User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Sprunk , ipv6@ietf.org Subject: Re: ICMPv6 echo reply to multicast packet thread References: <41892.66.150.60.2.1078953761.squirrel@defiant.dfw.nostrum.com> <7B2A7784F4B7F0409947481F3F3FEF830FEC5BFB-100000@eammlex037.lmc.ericsson.se > <25799.66.150.60.2.1079013960.squirrel@defiant.dfw.nostrum.com> In-Reply-To: <25799.66.150.60.2.1079013960.squirrel@defiant.dfw.nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2004 17:57:21.0362 (UTC) FILETIME=[4D1D9320:01C40792] Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stephen Sprunk wrote: >Suresh Krishnan said: > > >>On Wed, 10 Mar 2004, Stephen Sprunk wrote: >> >> >>>Suresh Krishnan said: >>> >>> >>>>Aha. That makes more sense to me. But why should we point to just >>>>ICMPv6 Echo request? Pretty much all data packets which need an >>>>ack can be used for this attack. It could be any protocol, not >>>>just ICMPv6. Anyway all the more reason for a MUST NOT. >>>> >>>> >>>Wait a minute... Now we're talking about prohibiting ANY multicast app >>> >>> >>>from responding unicast to multicasted data? That's a basic part of >> >> >>>functionality that is assumed in many apps! >>> >>>Can someone explain why we're looking for a different solution to this >>>behavior for IPv6 when the IPv4 behavior is already set in stone? For >>>apps which may not even be aware which version they're using, why should >>>IPv6 not respond in some or all cases when IPv4 always does? >>> >>> >>The problem is not about apps responding unicast to multicast data. It is >> specifically only about apps sending unicast ICMPv6 Echo replies in >>response to ICMPv6 echo requests sent to multicast addresses. Everything >>else (all data packet behavior) is not under discussion here. >> >> > >You pointed out that ICMP echo is not the only protocol this attack can >(supposedly) use; my argument is that turning off ICMP echo replies is >only useful if we prohibit all other apps from replying as well. Given >the noted holes in other aspects of ICMP that still MUST respond in error >conditions, we're just shifting the problem around without making it any >more difficult for attackers. If they can't flood someone with Echo >Replies, they'll just flood someone with Destination Unreachables (or some >other response) -- assuming, of course, they find a way around RPF. > > > The ICMPv6 specs is pretty careful on Error Messages in response to multicast packet. 2.4. Message Processing Rules (e) An ICMPv6 error message MUST NOT be sent as a result of receiving: ... (e.3) a packet destined to an IPv6 multicast address (there are two exceptions to this rule: (1) the Packet Too Big Message - Section 3.2 - to allow Path MTU discovery to work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 - Section 3.4 - reporting an unrecognized IPv6 option that has the Option Type highest-order two bits set to 10), or (e.4) a packet sent as a link-layer multicast, (the exception from e.3 applies to this case too), or (e.5) a packet sent as a link-layer broadcast, (the exception from e.3 applies to this case too), or (e.6) a packet whose source address does not uniquely identify a single node -- e.g., the IPv6 Unspecified Address, an IPv6 multicast address, or an address known by the ICMP message sender to be an IPv6 anycast address. I find it contradicting to be this careful for error conditions while to easier to generate non-error condition reply SHOULD be sent. I agree that multicast ping is useful tool and would not like to totally get rid of it. Still it is dangerous in case of large multicast groups. How about the following wording: An Echo Reply MUST be sent in response to an Echo Request message sent to an IPv6 multicast address. By default hop-limit IPv6 header field MUST be set to value 1 [on non-router hosts?]. The hop-limit SHOULD be administratively configurable. Hop-limit limitation is used to prevent Echo Reply message storms on large multicast groups. If Echo Reply message is sent in responce to an Echo Request message sent to an IPv6 multicast or anycast address, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received. This makes it possible to use ping to multicast address and get always response, if other nodes are on the same link. By default there would be no echo reply storm for multi-link groups (except on each link the number of multicast listeners on link causes two packets: echo reply and time exceeded back from router). For multilink case group can still be investigated by increasing some nodes echo-reply hop-limit may be increased to bigger value. If [on non-router hosts?] is added to the wording, routers would send echo reply messages to multicast echo request packets. Still the resulted echo reply storm will be decreased from the current situation. --- Jyrki Soini -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 13:37:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15555 for ; Thu, 11 Mar 2004 13:37:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1V3f-00051O-UV for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 13:37:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BIbRv9019280 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 13:37:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1V3e-00050i-VI for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 13:37:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15517 for ; Thu, 11 Mar 2004 13:37:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1V3c-0004vo-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 13:37:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1V2X-0004ka-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 13:36:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1V1i-0004Yq-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 13:35:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1V1N-0004Ga-Sl; Thu, 11 Mar 2004 13:35:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Tif-0004J4-30 for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 12:11:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11844 for ; Thu, 11 Mar 2004 12:11:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Tid-0000RB-00 for ipv6@ietf.org; Thu, 11 Mar 2004 12:11:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Thg-0000Je-00 for ipv6@ietf.org; Thu, 11 Mar 2004 12:10:40 -0500 Received: from adsl-66-127-127-227.dsl.scrm01.pacbell.net ([66.127.127.227] helo=wes.hardakers.net) by ietf-mx with esmtp (Exim 4.12) id 1B1Tgk-0000BX-00 for ipv6@ietf.org; Thu, 11 Mar 2004 12:09:42 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 9C37811E487; Thu, 11 Mar 2004 09:09:40 -0800 (PST) To: dthaler@microsoft.com Cc: ipv6@ietf.org Subject: comments on the tunnel-mib From: Wes Hardaker Organization: Sparta Date: Thu, 11 Mar 2004 09:09:40 -0800 Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 2 quick comments: 1) I'd move the deprecated parts of the mib to the bottom, which is a more common place to list older-not-used parts (so the newer parts are seen first). 2) I've had some users want to list start and end times within the tunnel list. Not all tunnels would have end times, but some will (eg, ipsec tunnels with configured tear-down times). A zero value could be used for infinite tunnels. Thoughts? -- Wes Hardaker Sparta -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 14:26:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15556 for ; Thu, 11 Mar 2004 13:37:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1V3g-00051P-0s for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 13:37:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BIbRuW019295 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 13:37:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1V3f-00050v-HF for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 13:37:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15520 for ; Thu, 11 Mar 2004 13:37:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1V3d-0004vt-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 13:37:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1V2Y-0004kj-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 13:36:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1V1i-0004Yr-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 13:35:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1V1M-0004GH-6R; Thu, 11 Mar 2004 13:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1TX8-0002QS-RB for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 11:59:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11372 for ; Thu, 11 Mar 2004 11:59:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1TX7-0006Xf-00 for ipv6@ietf.org; Thu, 11 Mar 2004 11:59:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1TWC-0006QK-00 for ipv6@ietf.org; Thu, 11 Mar 2004 11:58:49 -0500 Received: from adsl-66-127-127-227.dsl.scrm01.pacbell.net ([66.127.127.227] helo=wes.hardakers.net) by ietf-mx with esmtp (Exim 4.12) id 1B1TVl-0006IG-00 for ipv6@ietf.org; Thu, 11 Mar 2004 11:58:21 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 43AC111E487; Thu, 11 Mar 2004 08:58:17 -0800 (PST) To: ipv6@ietf.org Subject: comments on ipCidrRouteNumber From: Wes Hardaker Organization: Sparta Date: Thu, 11 Mar 2004 08:58:17 -0800 Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 When showing the IP-FORWARD-MIB to some operators who are likely going to use devices deploying it, they had the following suggestion: Change inetCidrRouteNumber "entries are not invalid" to "entries that are valid". -- Wes Hardaker Sparta -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 14:33:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17939 for ; Thu, 11 Mar 2004 14:33:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Vvh-0001Hz-2k for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 14:33:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BJXHAG004949 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 14:33:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Vvg-0001Hk-U0 for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 14:33:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17917 for ; Thu, 11 Mar 2004 14:33:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Vve-0004lf-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 14:33:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Vua-0004bI-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 14:32:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Vu6-0004Re-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 14:31:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1VtX-0000qY-Q7; Thu, 11 Mar 2004 14:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1VtJ-0000nJ-K6 for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 14:30:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17795 for ; Thu, 11 Mar 2004 14:30:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1VtH-0004Pn-00 for ipv6@ietf.org; Thu, 11 Mar 2004 14:30:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1VsP-0004Ir-00 for ipv6@ietf.org; Thu, 11 Mar 2004 14:29:53 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1B1Vrx-0004Ad-00 for ipv6@ietf.org; Thu, 11 Mar 2004 14:29:25 -0500 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Mar 2004 11:28:55 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Mar 2004 11:28:54 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Mar 2004 11:28:13 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Mar 2004 11:27:22 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 11 Mar 2004 11:28:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comments on the tunnel-mib Date: Thu, 11 Mar 2004 11:28:52 -0800 Message-ID: Thread-Topic: comments on the tunnel-mib thread-index: AcQHi4cIsxhjTEToRfiB13rOh3+goAAEwfkw From: "Dave Thaler" To: "Wes Hardaker" Cc: X-OriginalArrivalTime: 11 Mar 2004 19:28:26.0439 (UTC) FILETIME=[068E2570:01C4079F] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Wes Hardaker writes: > 2 quick comments: >=20 > 1) I'd move the deprecated parts of the mib to the bottom, which is > a more common place to list older-not-used parts (so the newer > parts are seen first). No problem (although in my opinion it's not worth updating the document solely for this). =20 > 2) I've had some users want to list start and end times within the > tunnel list. Not all tunnels would have end times, but some will > (eg, ipsec tunnels with configured tear-down times). A zero value > could be used for infinite tunnels. Thoughts? I didn't quite follow that. Assuming start time is in the past, can you elaborate on why ifLastChange and ifCounterDiscontinuityTime=20 in the IF-MIB are not sufficient? And it sounds like you're saying the end time is in the future, i.e. an expiration time on the entry, is that right? -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 19:52:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07302 for ; Thu, 11 Mar 2004 19:52:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1auE-0004EC-0n for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 19:52:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0q5xQ016246 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 19:52:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1auD-0004Dx-Hb for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:52:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07059 for ; Thu, 11 Mar 2004 19:52:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1auB-0003yU-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 19:52:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1apv-0002oE-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 19:47:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1aoe-0002b9-02 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 19:46:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1aec-0005U0-RE for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 19:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ad7-0002az-V0; Thu, 11 Mar 2004 19:34:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1aYo-0001Ku-CN for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 19:29:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06192 for ; Thu, 11 Mar 2004 19:29:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1aYm-0000Ru-00 for ipv6@ietf.org; Thu, 11 Mar 2004 19:29:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1aXt-0000LF-00 for ipv6@ietf.org; Thu, 11 Mar 2004 19:29:02 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B1aWx-0000D0-00 for ipv6@ietf.org; Thu, 11 Mar 2004 19:28:03 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2C0Rtex016872; Thu, 11 Mar 2004 17:27:56 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2C0RrQ00669; Fri, 12 Mar 2004 01:27:53 +0100 (MET) Date: Thu, 11 Mar 2004 16:27:58 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Multiple DRs on a link To: Alper Yegin Cc: "'Mattias Pettersson'" , ipv6@ietf.org In-Reply-To: "Your message with ID" <000101c4066d$e6bb1a00$e82f024b@sisa.samsung.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 > There is some relevant text in RFC 3484: > > Implementations may also use the choice of router to influence the > choice of source address. For example, suppose a host is on a link > with two routers. One router is advertising a global prefix A and > the other router is advertising global prefix B. Then when sending > via the first router, the host may prefer source addresses with > prefix A and when sending via the second router, prefer source > addresses with prefix B. > > This provides guidance in the right direction, but I'm not sure if it is > sufficient, or ever implemented. As others have said the above language is really weak. But even if the language was a MUST and it was universally implemented I don't think it would help; other issues would have to be resolved. For instance, what should the host do when it suspects that the 1st hop router is down? (e.g. due to NUD failing) In the model that all routers on the link are assumed equal, the host, as is specified in RFC 2461, can switch to using a different 1st hop router. But in what I would call the source based routing model (where the source address determines which 1st hop router is used), switching to a different 1st hop router might be a bad idea (ingress filtering above that router might discard all such packets); continuing to send packets to the 1st hop router that advertised the prefix might actually be better - in case the router receives the packets they will make it to the destination. Thus I thing there is a rather large architectural question lurking in this issue. *If* we want to pursue this path at a minimum the host needs to know whether using the original 1st hop router is better or not. One way to do this is to require that routers on the same link must advertise the same set of prefixes (and make the router advertisement consistency in RFC 2461 check this?). If we did that then the hosts could assume that when different routers advertise different sets, the routers are not managed by the same entity and the host should use a 1st hop router that is consistent with the source address. But the host could switch 1st hop routers among the set of routers that advertise the same set of prefixes. I don't know whether we could make the operational requirement that the routers on the same link (that don't want source-based routing) must advertise the same set of prefixes stick. Depends on what the current operational practices I guess. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 20:17:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09231 for ; Thu, 11 Mar 2004 20:17:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1bIP-0006wZ-MI for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 20:17:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C1H5Wj026685 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 20:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1bIP-0006wK-GJ for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 20:17:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09216 for ; Thu, 11 Mar 2004 20:17:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1bIN-0000Tu-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 20:17:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1bHY-0000L4-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 20:16:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1bGl-0000DU-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 20:15:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1bGT-0006cy-9D; Thu, 11 Mar 2004 20:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Y4w-0004tJ-K0 for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 16:50:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29044 for ; Thu, 11 Mar 2004 16:50:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Y4u-0002sB-00 for ipv6@ietf.org; Thu, 11 Mar 2004 16:50:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Y42-0002l0-00 for ipv6@ietf.org; Thu, 11 Mar 2004 16:50:03 -0500 Received: from adsl-66-127-127-227.dsl.scrm01.pacbell.net ([66.127.127.227] helo=wes.hardakers.net) by ietf-mx with esmtp (Exim 4.12) id 1B1Y3h-0002d8-00 for ipv6@ietf.org; Thu, 11 Mar 2004 16:49:42 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 2947011E487; Thu, 11 Mar 2004 13:49:38 -0800 (PST) To: "Dave Thaler" Cc: Subject: Re: comments on the tunnel-mib References: From: Wes Hardaker Organization: Sparta Date: Thu, 11 Mar 2004 13:49:38 -0800 In-Reply-To: (Dave Thaler's message of "Thu, 11 Mar 2004 11:28:52 -0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Thu, 11 Mar 2004 11:28:52 -0800, "Dave Thaler" said: >> 2) I've had some users want to list start and end times within the >> tunnel list. Not all tunnels would have end times, but some will >> (eg, ipsec tunnels with configured tear-down times). A zero value >> could be used for infinite tunnels. Thoughts? Dave> I didn't quite follow that. Assuming start time is in the past, Dave> can you elaborate on why ifLastChange and ifCounterDiscontinuityTime Dave> in the IF-MIB are not sufficient? Because a momentary lapse in reasoning made me forget that your tunnels are directly tied in a 1 to 1 fashion with an ifIndex. Now that I remember this, I'm not actually sure the MIB is what I'm looking for anyway... Dave> And it sounds like you're saying the end time is in the future, i.e. Dave> an expiration time on the entry, is that right? Right. -- Wes Hardaker Sparta -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 11 22:36:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14757 for ; Thu, 11 Mar 2004 22:36:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1dTD-0004dN-9a for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 22:36:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C3aNPf017806 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 22:36:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1dTD-0004d7-0s for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 22:36:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14741 for ; Thu, 11 Mar 2004 22:36:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1dT9-0003KX-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 22:36:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1dSB-0003Br-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 22:35:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1dRK-000339-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 22:34:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1dQw-0004Kk-5b; Thu, 11 Mar 2004 22:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1dQ3-0004JG-0m for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 22:33:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14565 for ; Thu, 11 Mar 2004 22:33:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1dPz-0002qj-00 for ipv6@ietf.org; Thu, 11 Mar 2004 22:33:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1dP1-0002hz-00 for ipv6@ietf.org; Thu, 11 Mar 2004 22:32:03 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B1dO5-0002TK-00 for ipv6@ietf.org; Thu, 11 Mar 2004 22:31:05 -0500 content-class: urn:content-classes:message Subject: RE: Multiple DRs on a link Date: Thu, 11 Mar 2004 22:30:32 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Multiple DRs on a link X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQHyeWavnVK4NImQa2qU+2PN1XhLgAFuJ4g From: "Soliman Hesham" To: "Erik Nordmark" , "Alper Yegin" Cc: "Mattias Pettersson" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > *If* we want to pursue this path at a minimum the host needs to know > whether using the original 1st hop router is better or not. > One way to do this is to require that routers on the same link > must advertise the same set of prefixes (and make the router=20 > advertisement > consistency in RFC 2461 check this?). > If we did that then the hosts could assume that when=20 > different routers > advertise different sets, the routers are not managed by the same > entity and the host should use a 1st hop router that is=20 > consistent with > the source address. But the host could switch 1st hop=20 > routers among the > set of routers that advertise the same set of prefixes. =3D> I think that it's generally a good idea to recommend that, despite the fact that we don't yet have a full solution. I.e. there is nothing to lose if we recommend that and there are potential gains. This will also simplify MIP movement detection a bit. Should we strengthen the language on this in 2461bis? There is already a recommendation that routers should=20 check other RAs for consistency, but I don't think it says anything about advertising the same prefixes. Perhaps we can add that as a "RECOMMEND". >=20 > I don't know whether we could make the operational=20 > requirement that the routers > on the same link (that don't want source-based routing) must=20 > advertise the > same set of prefixes stick. Depends on what the current=20 > operational practices > I guess. =3D> Agreed. But then again better now, when there is not global deployment, than few years down the road when it is widely deployed. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 12 00:04:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18029 for ; Fri, 12 Mar 2004 00:04:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1epq-0000m8-J0 for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 00:03:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C53owd002974 for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 00:03:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1epq-0000lr-Bs for ipv6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 00:03:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17873 for ; Fri, 12 Mar 2004 00:03:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1epo-0007Yb-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 00:03:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1enV-000713-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 00:01:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1emw-0006rt-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 00:00:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1ejh-0000du-As for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 23:57:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ejF-0008VH-E7; Thu, 11 Mar 2004 23:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1eiP-0008TP-4u for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 23:56:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17582 for ; Thu, 11 Mar 2004 23:56:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1eiM-0006LM-00 for ipv6@ietf.org; Thu, 11 Mar 2004 23:56:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ehT-0006Ek-00 for ipv6@ietf.org; Thu, 11 Mar 2004 23:55:11 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1B1egj-00061D-00 for ipv6@ietf.org; Thu, 11 Mar 2004 23:54:25 -0500 Received: from eamrcnt716.exu.ericsson.se (eamrcnt716.exu.ericsson.se [138.85.90.247]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i2C4rtfX024744 for ; Thu, 11 Mar 2004 22:53:55 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt716.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Mar 2004 22:52:01 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 11 Mar 2004 22:53:42 -0600 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GPWXBBKB; Thu, 11 Mar 2004 23:53:51 -0500 Date: Thu, 11 Mar 2004 23:53:05 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: Mukesh.Gupta@nokia.com cc: jari.arkko@kolumbus.fi, , , Subject: RE: ICMPv6 echo reply to multicast packet thread In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830D8F6B96@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 12 Mar 2004 04:52:01.0906 (UTC) FILETIME=[C224ED20:01C407ED] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 11 Mar 2004 Mukesh.Gupta@nokia.com wrote: >Now, who can tell if multicast echo request is the primary >multicast debugging mechanism or not ?? Since there is no alternate mechanism, this has become the primary and preferred multicast debugging mechanism. If some mechanism is proposed which is better and is less liable to be misused, it will become the primary mechanism. The KAME project was working on a multicast traceroute tool for IPv6 a while ago. I have not personally used it. Probably Jinmei can comment further on this. Regards Suresh This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 12 08:37:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20187 for ; Fri, 12 Mar 2004 08:37:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mqw-0006JT-02 for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 08:37:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CDbTFx024253 for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 08:37:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mqv-0006J3-Ef for ipv6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 08:37:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20161 for ; Fri, 12 Mar 2004 08:37:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1mqu-00048z-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 08:37:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1mq0-000425-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 08:36:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1mp7-0003vH-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 08:35:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1moZ-0005xZ-0U; Fri, 12 Mar 2004 08:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mo0-0005vT-Se for ipv6@optimus.ietf.org; Fri, 12 Mar 2004 08:34:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20012 for ; Fri, 12 Mar 2004 08:34:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1mnz-0003mM-00 for ipv6@ietf.org; Fri, 12 Mar 2004 08:34:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1mn0-0003cG-00 for ipv6@ietf.org; Fri, 12 Mar 2004 08:33:27 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1B1mlz-0003L2-00 for ipv6@ietf.org; Fri, 12 Mar 2004 08:32:23 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i2CDVkBv004063; Fri, 12 Mar 2004 14:31:46 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i2CDVl2D003212; Fri, 12 Mar 2004 14:31:47 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 12 Mar 2004 14:31:47 +0100 From: Stig Venaas To: Suresh Krishnan Cc: Mukesh.Gupta@nokia.com, jari.arkko@kolumbus.fi, pekkas@netcore.fi, jyrki.soini@teliasonera.com, ipv6@ietf.org Subject: Re: ICMPv6 echo reply to multicast packet thread Message-ID: <20040312133146.GA3191@sverresborg.uninett.no> References: <7B2A7784F4B7F0409947481F3F3FEF830D8F6B96@eammlex037.lmc.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Mar 11, 2004 at 11:53:05PM -0500, Suresh Krishnan wrote: > On Thu, 11 Mar 2004 Mukesh.Gupta@nokia.com wrote: > > >Now, who can tell if multicast echo request is the primary > >multicast debugging mechanism or not ?? > > Since there is no alternate mechanism, this has become the primary and > preferred multicast debugging mechanism. If some mechanism is proposed > which is better and is less liable to be misused, it will become the > primary mechanism. The KAME project was working on a multicast traceroute > tool for IPv6 a while ago. I have not personally used it. Probably > Jinmei can comment further on this. Especially pinging ff02::1 is often used not just for debugging multicast, but also for other debugging. So I think this is useful, even if some other multicast debugging mechanisms are introduced. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 12 08:48:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20886 for ; Fri, 12 Mar 2004 08:48:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1n17-0007ZF-Um for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 08:48:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CDm1Nm029088 for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 08:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1n17-0007Z5-Nn for ipv6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 08:48:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20845 for ; Fri, 12 Mar 2004 08:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1n15-0005hx-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 08:47:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1n0F-0005Xb-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 08:47:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1mzS-0005MC-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 08:46:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mzC-0007CV-F7; Fri, 12 Mar 2004 08:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mz1-0007BA-7b for ipv6@optimus.ietf.org; Fri, 12 Mar 2004 08:45:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20582 for ; Fri, 12 Mar 2004 08:45:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1myz-0005Hx-00 for ipv6@ietf.org; Fri, 12 Mar 2004 08:45:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1mxx-00056r-00 for ipv6@ietf.org; Fri, 12 Mar 2004 08:44:45 -0500 Received: from canet.u-strasbg.fr ([130.79.90.179]) by ietf-mx with esmtp (Exim 4.12) id 1B1mxA-0004yJ-00 for ipv6@ietf.org; Fri, 12 Mar 2004 08:43:56 -0500 Received: from canet.u-strasbg.fr (localhost [127.0.0.1]) by canet.u-strasbg.fr (8.12.9/8.12.9) with ESMTP id i2CDjCZn013433; Fri, 12 Mar 2004 14:45:12 +0100 (CET) (envelope-from hoerdt@clarinet.u-strasbg.fr) Received: from localhost (hoerdt@localhost) by canet.u-strasbg.fr (8.12.9/8.12.9/Submit) with ESMTP id i2CDjC0f013430; Fri, 12 Mar 2004 14:45:12 +0100 (CET) X-Authentication-Warning: canet.u-strasbg.fr: hoerdt owned process doing -bs Date: Fri, 12 Mar 2004 14:45:12 +0100 (CET) From: Hoerdt Mickael X-X-Sender: hoerdt@canet.u-strasbg.fr To: Stig Venaas cc: Suresh Krishnan , Mukesh.Gupta@nokia.com, jari.arkko@kolumbus.fi, pekkas@netcore.fi, jyrki.soini@teliasonera.com, ipv6@ietf.org Subject: Re: ICMPv6 echo reply to multicast packet thread In-Reply-To: <20040312133146.GA3191@sverresborg.uninett.no> Message-ID: <20040312144114.G13413@canet.u-strasbg.fr> References: <7B2A7784F4B7F0409947481F3F3FEF830D8F6B96@eammlex037.lmc.ericsson.se> <20040312133146.GA3191@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello, Allowing or not allowing a reply to a icmpv6 multicast request message is an interesting question. Now I am wondering why it is not allowed to answer to such a message in IPv4 (=> http://www.icir.org/fenner/mcast/icmp.html) and allowed in IPv6 ? Thank you, Hoerdt Mickael LSIIT Laboratory On Fri, 12 Mar 2004, Stig Venaas wrote: > On Thu, Mar 11, 2004 at 11:53:05PM -0500, Suresh Krishnan wrote: > > On Thu, 11 Mar 2004 Mukesh.Gupta@nokia.com wrote: > > > > >Now, who can tell if multicast echo request is the primary > > >multicast debugging mechanism or not ?? > > > > Since there is no alternate mechanism, this has become the primary and > > preferred multicast debugging mechanism. If some mechanism is proposed > > which is better and is less liable to be misused, it will become the > > primary mechanism. The KAME project was working on a multicast traceroute > > tool for IPv6 a while ago. I have not personally used it. Probably > > Jinmei can comment further on this. > > > Especially pinging ff02::1 is often used not just for debugging > multicast, but also for other debugging. So I think this is useful, > even if some other multicast debugging mechanisms are introduced. > > Stig > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Fri Mar 12 09:42:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24262 for ; Fri, 12 Mar 2004 09:42:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nqy-0003fj-QH for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 09:41:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CEfaDK014113 for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 09:41:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nqy-0003fY-2j for ipv6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 09:41:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24246 for ; Fri, 12 Mar 2004 09:41:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nqw-0006Ds-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 09:41:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nq2-00066a-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 09:40:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1npD-0005zQ-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 09:39:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1noU-0003Jx-8x; Fri, 12 Mar 2004 09:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1noH-0003JY-FV for ipv6@optimus.ietf.org; Fri, 12 Mar 2004 09:38:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24115 for ; Fri, 12 Mar 2004 09:38:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1noF-0005rQ-00 for ipv6@ietf.org; Fri, 12 Mar 2004 09:38:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nna-0005hh-00 for ipv6@ietf.org; Fri, 12 Mar 2004 09:38:06 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nmf-0005Pr-00 for ipv6@ietf.org; Fri, 12 Mar 2004 09:37:10 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2CEaQo07901; Fri, 12 Mar 2004 16:36:26 +0200 Date: Fri, 12 Mar 2004 16:36:26 +0200 (EET) From: Pekka Savola To: Hoerdt Mickael cc: Stig Venaas , Suresh Krishnan , , , , Subject: Re: ICMPv6 echo reply to multicast packet thread In-Reply-To: <20040312144114.G13413@canet.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 12 Mar 2004, Hoerdt Mickael wrote: > Allowing or not allowing a reply to a icmpv6 multicast request message is > an interesting question. > > Now I am wondering why it is not allowed to answer to such a message in > IPv4 (=> http://www.icir.org/fenner/mcast/icmp.html) and allowed in IPv6 ? Uhh -- it's fine to answer an ICMP echo request, but you should not send ICMP errors bassed on v4 packets. The same general principle applies to v6 as well -- with the exception that options formed in a certain way still require a reply. This could be an attack vector in the future, if multicast were to be used in the large scale. > On Fri, 12 Mar 2004, Stig Venaas wrote: > > > On Thu, Mar 11, 2004 at 11:53:05PM -0500, Suresh Krishnan wrote: > > > On Thu, 11 Mar 2004 Mukesh.Gupta@nokia.com wrote: > > > > > > >Now, who can tell if multicast echo request is the primary > > > >multicast debugging mechanism or not ?? > > > > > > Since there is no alternate mechanism, this has become the primary and > > > preferred multicast debugging mechanism. If some mechanism is proposed > > > which is better and is less liable to be misused, it will become the > > > primary mechanism. The KAME project was working on a multicast traceroute > > > tool for IPv6 a while ago. I have not personally used it. Probably > > > Jinmei can comment further on this. > > > > > > Especially pinging ff02::1 is often used not just for debugging > > multicast, but also for other debugging. So I think this is useful, > > even if some other multicast debugging mechanisms are introduced. > > > > Stig > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -- 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 exim@www1.ietf.org Fri Mar 12 12:51:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07149 for ; Fri, 12 Mar 2004 12:51:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qo3-0001tC-71 for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 12:50:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CHolcM007256 for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 12:50:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qo2-0001sx-Vd for ipv6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 12:50:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07142 for ; Fri, 12 Mar 2004 12:50:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qo1-0002cM-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 12:50:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qnB-0002VJ-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 12:49:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1qmf-0002NE-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 12:49:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qmM-0001Zd-9J; Fri, 12 Mar 2004 12:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qm0-0001Yv-RT for ipv6@optimus.ietf.org; Fri, 12 Mar 2004 12:48:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07002 for ; Fri, 12 Mar 2004 12:48:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qlz-0002LD-00 for ipv6@ietf.org; Fri, 12 Mar 2004 12:48:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ql5-0002CO-00 for ipv6@ietf.org; Fri, 12 Mar 2004 12:47:44 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1B1qk6-00023H-00 for ipv6@ietf.org; Fri, 12 Mar 2004 12:46:43 -0500 Message-ID: <018301c4085a$09f0a060$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Erik Nordmark" , "Soliman Hesham" Cc: "Erik Nordmark" , "Alper Yegin" , "Mattias Pettersson" , References: Subject: Re: Multiple DRs on a link Date: Fri, 12 Mar 2004 09:47:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > RFC 2461 explicitly doesn't require checking the set of prefixes (but > it does say to check that the lifetimes on a prefix which both routers > advertise are consistent, etc). > *If* we are going to change this, I don't think it should be a subtle > setence in 2461bis; I think it should be a standalone RFC so > that operators and implementors pay attention. > If we do that, making 2461bis have the same message makes sense. > > Perhaps writing up a draft for v6ops would be a good start. > Pointing out that the current flexibility (of different prefixes > advertised by different routers) doesn't have any operational use, but > allowing hosts, for Nemo and multihoming reasons, to tell when > there are source address constraints might have some use. > I agree. jak -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 12 12:54:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07402 for ; Fri, 12 Mar 2004 12:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qrB-0001xq-95 for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 12:54:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CHs1cL007544 for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 12:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qrB-0001xb-42 for ipv6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 12:54:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07298 for ; Fri, 12 Mar 2004 12:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qr9-000394-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 12:53:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qpt-0002sM-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 12:52:42 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1qoq-0002fc-01 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 12:51:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1qjH-0004h9-NY for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 12:45:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qiU-0001Er-UY; Fri, 12 Mar 2004 12:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qi7-0001Do-Uj for ipv6@optimus.ietf.org; Fri, 12 Mar 2004 12:44:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06846 for ; Fri, 12 Mar 2004 12:44:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qi6-0001pP-00 for ipv6@ietf.org; Fri, 12 Mar 2004 12:44:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qhE-0001iG-00 for ipv6@ietf.org; Fri, 12 Mar 2004 12:43:45 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1B1qgV-0001Nn-00 for ipv6@ietf.org; Fri, 12 Mar 2004 12:42:59 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2CHgMng016070; Fri, 12 Mar 2004 09:42:23 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2CHgKQ15740; Fri, 12 Mar 2004 18:42:20 +0100 (MET) Date: Fri, 12 Mar 2004 09:42:25 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Multiple DRs on a link To: Soliman Hesham Cc: Erik Nordmark , Alper Yegin , Mattias Pettersson , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 > Should we strengthen the language on this in 2461bis? > There is already a recommendation that routers should > check other RAs for consistency, but I don't think > it says anything about advertising the same prefixes. > Perhaps we can add that as a "RECOMMEND". RFC 2461 explicitly doesn't require checking the set of prefixes (but it does say to check that the lifetimes on a prefix which both routers advertise are consistent, etc). *If* we are going to change this, I don't think it should be a subtle setence in 2461bis; I think it should be a standalone RFC so that operators and implementors pay attention. If we do that, making 2461bis have the same message makes sense. Perhaps writing up a draft for v6ops would be a good start. Pointing out that the current flexibility (of different prefixes advertised by different routers) doesn't have any operational use, but allowing hosts, for Nemo and multihoming reasons, to tell when there are source address constraints might have some use. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Mar 14 00:07:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18937 for ; Sun, 14 Mar 2004 00:07:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Npy-000643-Sf for ipv6-archive@odin.ietf.org; Sun, 14 Mar 2004 00:06:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2E56wSa023310 for ipv6-archive@odin.ietf.org; Sun, 14 Mar 2004 00:06:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Npy-00063t-N3 for ipv6-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 00:06:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18920 for ; Sun, 14 Mar 2004 00:06:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Npw-0005H8-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 00:06:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Np2-0005AD-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 00:06:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2Nnz-00052X-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 00:04:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Nn8-0005fG-6l; Sun, 14 Mar 2004 00:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2NmL-0005bR-RW for ipv6@optimus.ietf.org; Sun, 14 Mar 2004 00:03:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18639 for ; Sun, 14 Mar 2004 00:03:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2NmJ-0004pI-00 for ipv6@ietf.org; Sun, 14 Mar 2004 00:03:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2NlP-0004i6-00 for ipv6@ietf.org; Sun, 14 Mar 2004 00:02:16 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1B2Nk4-0004Ts-00 for ipv6@ietf.org; Sun, 14 Mar 2004 00:00:52 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 2F8195F3 for ; Sun, 14 Mar 2004 00:00:23 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 14 Mar 2004 00:00:23 -0500 Message-Id: <20040314050023.2F8195F3@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 8.47% | 5 | 9.58% | 30410 | suresh.krishnan@ericsson.ca 6.78% | 4 | 9.11% | 28903 | stephen@sprunk.org 6.78% | 4 | 6.19% | 19643 | h.soliman@flarion.com 6.78% | 4 | 5.88% | 18650 | jari.arkko@kolumbus.fi 6.78% | 4 | 5.54% | 17592 | pekkas@netcore.fi 5.08% | 3 | 5.78% | 18351 | jyrki.soini@teliasonera.com 5.08% | 3 | 5.46% | 17328 | mattias.l.pettersson@ericsson.com 5.08% | 3 | 5.00% | 15875 | brc@zurich.ibm.com 5.08% | 3 | 3.25% | 10298 | hardaker@tislabs.com 3.39% | 2 | 3.25% | 10310 | jeroen@unfix.org 3.39% | 2 | 3.11% | 9871 | erik.nordmark@sun.com 1.69% | 1 | 4.73% | 15003 | moore@cs.utk.edu 3.39% | 2 | 2.73% | 8651 | stig.venaas@uninett.no 3.39% | 2 | 2.63% | 8334 | jinmei@isl.rdc.toshiba.co.jp 3.39% | 2 | 2.59% | 8211 | tjc@ecs.soton.ac.uk 1.69% | 1 | 2.68% | 8497 | alper.yegin@samsung.com 1.69% | 1 | 2.49% | 7916 | ftemplin@iprg.nokia.com 1.69% | 1 | 2.28% | 7240 | bob.hinden@nokia.com 1.69% | 1 | 2.12% | 6717 | mohacsi@niif.hu 1.69% | 1 | 1.83% | 5811 | mukesh.gupta@nokia.com 1.69% | 1 | 1.82% | 5785 | charliep@iprg.nokia.com 1.69% | 1 | 1.75% | 5568 | sra+ipng@hactrn.net 1.69% | 1 | 1.57% | 4969 | hoerdt@clarinet.u-strasbg.fr 1.69% | 1 | 1.48% | 4684 | jarno.rajahalme@nokia.com 1.69% | 1 | 1.47% | 4670 | dthaler@windows.microsoft.com 1.69% | 1 | 1.35% | 4285 | bhaskar.s@motorola.com 1.69% | 1 | 1.31% | 4141 | alain.durand@sun.com 1.69% | 1 | 1.25% | 3962 | ipng-incoming@danlan.com 1.69% | 1 | 1.16% | 3688 | kempf@docomolabs-usa.com 1.69% | 1 | 0.61% | 1921 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 59 |100.00% | 317284 | 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 exim@www1.ietf.org Sun Mar 14 15:03:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04136 for ; Sun, 14 Mar 2004 15:03:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bos-0007ro-D3 for ipv6-archive@odin.ietf.org; Sun, 14 Mar 2004 15:02:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2EK2kFY030211 for ipv6-archive@odin.ietf.org; Sun, 14 Mar 2004 15:02:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bor-0007r5-Tc for ipv6-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 15:02:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04014 for ; Sun, 14 Mar 2004 15:02:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2boo-00043M-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 15:02:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2bnF-0003eI-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 15:01:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2blh-0003J0-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 14:59:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bkL-0003b3-IM; Sun, 14 Mar 2004 14:58:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2X8u-0008EU-6F for ipv6@optimus.ietf.org; Sun, 14 Mar 2004 10:03:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21835 for ; Sun, 14 Mar 2004 10:03:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2X8s-0000aO-00 for ipv6@ietf.org; Sun, 14 Mar 2004 10:03:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2X7y-0000Um-00 for ipv6@ietf.org; Sun, 14 Mar 2004 10:02:11 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1B2X7H-0000Oq-00 for ipv6@ietf.org; Sun, 14 Mar 2004 10:01:27 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:bdff:fee3:efdf:baf7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id F2A511521B; Mon, 15 Mar 2004 00:01:24 +0900 (JST) Date: Mon, 15 Mar 2004 00:01:24 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mattias Pettersson Cc: Mohacsi Janos , ipv6@ietf.org Subject: Re: Multiple DRs on a link In-Reply-To: <404F2FBD.9030901@ericsson.com> References: <404E23A1.60700@ericsson.com> <20040310094331.Q10925@mignon.ki.iif.hu> <404F2FBD.9030901@ericsson.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Wed, 10 Mar 2004 16:09:49 +0100, >>>>> Mattias Pettersson said: >> I think this is not broken at all. The host should select the correct >> prefix according to the source address selection rules. I tried this >> scenario approximately 3 years ago on a KAME stack and it was working >> correctly. > But what source address selection rules do you refer to? I saw Alper's > response and I'm happy he pointed it out because I haven't been aware of > it, but the wording there is really weak. > Other than that I don't understand what rules in 3484 help here. I got > rather familiar with the KAME stack during 1999-2001 and to my knowledge > the default router selection is made once and the host sticks to that > router as long as it is considered reachable. What source address being > used doesn't matter to what next-hop is used. Just to clarify a few things about a particular implementation, KAME implemented most part of RFC3484 (in 2001), but does not support the capability cited in this thread. As far as I can see, the source address selection algorithm (based on RFC3484) implemented in KAME can only solve some part of the problem. For example, if longest matching against the destination address suggests the correct source address, it will work fine. In general, however, the implementation can choose an undesirable source address that can be filtered in an ISP (or can cause other unpleasant problems). 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 exim@www1.ietf.org Sun Mar 14 15:51:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04141 for ; Sun, 14 Mar 2004 15:03:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bot-0007sZ-4i for ipv6-archive@odin.ietf.org; Sun, 14 Mar 2004 15:02:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2EK2lcF030276 for ipv6-archive@odin.ietf.org; Sun, 14 Mar 2004 15:02:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bos-0007sC-Vb for ipv6-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 15:02:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04017 for ; Sun, 14 Mar 2004 15:02:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2boq-00043Y-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 15:02:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2bnG-0003eR-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 15:01:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2blh-0003J1-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 14:59:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bkQ-0003cV-0c; Sun, 14 Mar 2004 14:58:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2XWA-00036N-Qn for ipv6@optimus.ietf.org; Sun, 14 Mar 2004 10:27:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22561 for ; Sun, 14 Mar 2004 10:27:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2XW8-00030V-00 for ipv6@ietf.org; Sun, 14 Mar 2004 10:27:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2XVC-0002ur-00 for ipv6@ietf.org; Sun, 14 Mar 2004 10:26:11 -0500 Received: from smtp.exodus.net ([66.35.230.237] helo=smtp02-w.exodus.net) by ietf-mx with esmtp (Exim 4.12) id 1B2XV0-0002p7-00 for ipv6@ietf.org; Sun, 14 Mar 2004 10:25:58 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i2ECXMEv006434 for ; Sun, 14 Mar 2004 06:33:32 -0600 Received: from [192.168.2.2] (unverified [24.61.30.237]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Sun, 14 Mar 2004 07:25:07 -0800 Mime-Version: 1.0 X-Sender: margaret@thingmagic.com@ms101.mail1.com Message-Id: Date: Sun, 14 Mar 2004 10:24:48 -0500 To: ipv6@ietf.org From: Margaret Wasserman Subject: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt Content-Type: multipart/mixed; boundary="============_-1132844589==_============" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MIME_SUSPECT_NAME autolearn=no version=2.60 --============_-1132844589==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hi All, I've completed my AD evaluation of draft-ietf-ipv6-unique-local-addr-03.txt. My comments (attached below) include a few substantive issues that I would like to discuss with the WG before sending this draft to IETF last call. Thoughts? I have also included a few non-blocking editorial comments that should be addresses in the next revision, if any. Margaret --============_-1132844589==_============ Content-Id: Content-Type: multipart/appledouble; boundary="============_-1132844589==_D============" --============_-1132844589==_D============ Content-Type: application/applefile; name="%draft-ietf-ipv6-unique-local-addr-03.txt" Content-Disposition: attachment; filename="%draft-ietf-ipv6-unique-local-addr-03.txt" ; modification-date="Sun, 14 Mar 2004 10:19:45 -0500" Content-Transfer-Encoding: base64 AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAAB8AAAAJAAAAXQAAACAA AAAIAAAAfQAAABBkcmFmdC1pZXRmLWlwdjYtdW5pcXUjNEFBMDgudHh0AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH5u5BB+buQUttDAAH5u+D --============_-1132844589==_D============ Content-Type: application/octet-stream; name="draft-ietf-ipv6-unique-local-addr-03.txt" Content-Disposition: attachment; filename="draft-ietf-ipv6-unique-local-addr-03.txt" Content-Transfer-Encoding: base64 ClNVQlNUQU5USVZFIElTU1VFUzoKCigxKSBUaGlzIGRyYWZ0IGRvZXNuJ3QgbWVudGlv biB0aGUgcmV2ZXJzZSBETlMgdHJlZS4gIElzIGl0IGV4cGVjdGVkIHRoYXQKICAgIHdo YXRldmVyIHJlZ2lzdHJ5IGFzc2lnbnMgdGhlc2UgdmFsdWVzIHdpbGwgYWxzbyBwb3B1 bGF0ZSB0aGUgcmV2ZXJzZQogICAgRE5TIHRyZWU/ICBPciBub3Q/ICAKCigyKSBUaGUg ZG9jdW1lbnQgc2F5czoKCj4gICBHbG9iYWwgSURzIHNob3VsZCBiZSBhc3NpZ25lZCBj ZW50cmFsbHkgYnkgYSBzaW5nbGUgYWxsb2NhdGlvbgo+ICAgYXV0aG9yaXR5IGJlY2F1 c2UgdGhleSBhcmUgcHNldWRvLXJhbmRvbSBhbmQgd2l0aG91dCBhbnkgc3RydWN0dXJl Lgo+ICAgVGhpcyBpcyBlYXNpZXN0IHRvIGFjY29tcGxpc2ggaWYgdGhlcmUgaXMgYSBz aW5nbGUgc291cmNlIGZvciB0aGUKPiAgIGFzc2lnbm1lbnRzLgoKICAgIFRoaXMgd291 bGQgYXBwZWFyIHRvIGJlIGluY29tcGF0aWJsZSB3aXRoIHRoZSBJQU5BIGNvbnNpZGVy YXRpb25zCiAgICBzZWN0aW9uIHRoYXQgc2F5czoKCj4gICBJZiBkZWVtZWQKPiAgIGFw cHJvcHJpYXRlLCB0aGUgYXV0aG9yaXR5IG1heSBhbHNvIGNvbnNpc3Qgb2YgbXVsdGlw bGUgb3JnYW5pemF0aW9ucwo+CiAgIHBlcmZvcm1pbmcgdGhlIGF1dGhvcml0eSBkdXRp ZXMuCgogICAgVG8gYXZvaWQgYSBzaXR1YXRpb24gd2hlcmUgYSBzaW5nbGUgZW50aXR5 IGNhbiByZXF1ZXN0IGEgbGFyZ2UgbnVtYmVyCiAgICBvZiBsb2NhbCBwcmVmaXhlcyBh bmQgYWdncmVnYXRlIHRoZW0sIGl0IGlzbid0IHN0cmljdGx5IG5lY2Vzc2FyeSB0aGF0 CiAgICB0aGUgYWRkcmVzc2VzIGJlIGFsbG9jYXRlZCBmcm9tIGEgc2luZ2xlIHBvb2wu ICBJZiB0aGVyZSB3ZXJlIHNldmVyYWwKICAgIHBvb2xzIChmb3IgZGlmZmVyZW50IGdl b2dyYXBoaWNhbCByZWdpb25zLCBmb3IgZXhhbXBsZSkgcmFuZG9tCiAgICBhbGxvY2F0 aW9ucyBmcm9tIG9uZSBvZiB0aG9zZSBwb29scyB3b3VsZCBhY2hpZXZlIHRoZSBzYW1l IHJlc3VsdC4KCigzKSBUaGUgZG9jdW1lbnQgYWxzbyBzYXlzOgoKPiAgIFRoZSByZXF1 aXJlbWVudHMgZm9yIGNlbnRyYWxseSBhc3NpZ25lZCBnbG9iYWwgSUQgYWxsb2NhdGlv bnMgYXJlOgo+Cj4gICAgICAtIEF2YWlsYWJsZSB0byBhbnlvbmUgaW4gYW4gdW5iaWFz ZWQgbWFubmVyLgo+ICAgICAgLSBQZXJtYW5lbnQgd2l0aCBubyBwZXJpb2RpYyBmZWVz LgoKICAgIEl0IHNlZW1zIHN0cmFuZ2UgdG8gc2F5IHRoYXQgdGhlcmUgY2FuIGJlIG5v IHBlcmlvZGljIGZlZXMgd2hlbiB0aGUKICAgIGRvY3VtZW50IGRvZXNuJ3QgbWVudGlv biBmZWVzIGFueXdoZXJlIGVsc2UuLi4gIFBlcmhhcHMgdGhpcyBpcyBhCiAgICBsZWZ0 b3ZlciBmcm9tIHByZXZpb3VzIHZlcnNpb25zIG9mIHRoZSBkb2N1bWVudCB0aGF0IGRp ZCBpbmNsdWRlIGEgZmVlCiAgICBzdHJ1Y3R1cmU/Cgo+ICAgICAgLSBBbGxvY2F0aW9u IG9uIGEgcGVybWFuZW50IGJhc2lzLCB3aXRob3V0IGFueSBuZWVkIGZvciByZW5ld2Fs Cj4gICAgICAgIGFuZCB3aXRob3V0IGFueSBwcm9jZWR1cmUgZm9yIGRlLWFsbG9jYXRp b24uCj4gICAgICAtIFByb3ZpZGUgbWVjaGFuaXNtcyB0aGF0IHByZXZlbnQgaG9hcmRp bmcgb2YgdGhlc2UgYWxsb2NhdGlvbnMuCj4gICAgICAtIFRoZSBvd25lcnNoaXAgb2Yg ZWFjaCBpbmRpdmlkdWFsIGFsbG9jYXRpb24gc2hvdWxkIGJlIHByaXZhdGUsCj4gICAg ICAgIGJ1dCBzaG91bGQgYmUgZXNjcm93ZWQuCgogICAgSSBhbSBub3Qgc3VyZSB0aGF0 IHJlcXVpcmluZyBhIHBlcm1hbmVudCBlc2Nyb3cgaXMgY29uc2lzdGVudCB3aXRoIHRo ZQogICAgaWRlYSB0aGF0IHRoZXJlIHdpbGwgYmUgbm8gb25nb2luZyByZXZlbnVlIHN0 cmVhbSAoaS5lLiBwZXJpb2RpYyBmZWVzKQogICAgYXNzb2NpYXRlZCB3aXRoIGFuIGFk ZHJlc3MuCgooNCkgVGhlIGFsZ29yaXRobSBmb3IgcmFuZG9tIG51bWJlciBnZW5lcmF0 aW9uIGlzOgoKPjMuMi4zICBTYW1wbGUgQ29kZSBmb3IgUHNldWRvLVJhbmRvbSBHbG9i YWwgSUQgQWxnb3JpdGhtCj4KPiAgIFRoZSBhbGdvcml0aG0gZGVzY3JpYmVkIGJlbG93 IGlzIGludGVuZGVkIHRvIGJlIHVzZWQgZm9yIGNlbnRyYWxseQo+ICAgYW5kIGxvY2Fs bHkgYXNzaWduZWQgR2xvYmFsIElEcy4gIEluIGVhY2ggY2FzZSB0aGUgcmVzdWx0aW5n IGdsb2JhbAo+ICAgSUQgd2lsbCBiZSB1c2VkIGluIHRoZSBhcHByb3ByaWF0ZSBwcmVm aXggYXMgZGVmaW5lZCBpbiBzZWN0aW9uIDMuMi4KPgo+ICAgICAxKSBPYnRhaW4gdGhl IGN1cnJlbnQgdGltZSBvZiBkYXkgaW4gNjQtYml0IE5UUCBmb3JtYXQgW05UUF0uCj4g ICAgIDIpIE9idGFpbiBhbiBFVUktNjQgaWRlbnRpZmllciBmcm9tIHRoZSBzeXN0ZW0g cnVubmluZyB0aGlzCj4gICAgICAgIGFsZ29yaXRobS4gIElmIGFuIEVVSS02NCBkb2Vz IG5vdCBleGlzdCwgb25lIGNhbiBiZSBjcmVhdGVkIGZyb20KPiAgICAgICAgYSA0OC1i aXQgTUFDIGFkZHJlc3MgYXMgc3BlY2lmaWVkIGluIFtBRERBUkNIXS4gIElmIGFuIEVV SS02NAo+ICAgICAgICBjYW5ub3QgYmUgb2J0YWluZWQgb3IgY3JlYXRlZCwgYSBzdWl0 YWJseSB1bmlxdWUgaWRlbnRpZmllciwKPiAgICAgICAgbG9jYWwgdG8gdGhlIG5vZGUs IHNob3VsZCBiZSB1c2VkIChlLmcuIHN5c3RlbSBzZXJpYWwgbnVtYmVyKS4KPiAgICAg MykgQ29uY2F0ZW5hdGUgdGhlIHRpbWUgb2YgZGF5IHdpdGggdGhlIHN5c3RlbS1zcGVj aWZpYyBpZGVudGlmaWVyCj4gICAgICAgIGNyZWF0aW5nIGEga2V5Lgo+ICAgICA0KSBD b21wdXRlIGFuIE1ENSBkaWdlc3Qgb24gdGhlIGtleSBhcyBzcGVjaWZpZWQgaW4gW01E NURJR10uCj4gICAgIDUpIFVzZSB0aGUgbGVhc3Qgc2lnbmlmaWNhbnQgNDAgYml0cyBh cyB0aGUgR2xvYmFsIElELgo+Cj4gICBUaGlzIGFsZ29yaXRobSB3aWxsIHJlc3VsdCBp biBhIGdsb2JhbCBJRCB0aGF0IGlzIHJlYXNvbmFibHkgdW5pcXVlCj4gICBhbmQgY2Fu IGJlIHVzZWQgYXMgYSBHbG9iYWwgSUQuCgogICAgQXJlIHlvdSBpbnRlbmRpbmcgdGhh dCBjZW50cmFsbHkgYXNzaWduZWQgYWRkcmVzc2VzIHdpbGwgYWxsIGJlCiAgICBnZW5l cmF0ZWQgdXNpbmcgdGhlIEVVSS02NCBhZGRyZXNzIG9mIGEgc2VydmVyIGF0IHRoZSBj ZW50cmFsaXplZAogICAgcmVnaXN0cmF0aW9uIGF1dGhvcml0eT8gIFdoYXQgYWZmZWN0 IHdvdWxkIHRoaXMgaGF2ZSBvbiB0aGUgcmFuZG9tbmVzcwogICAgb2YgdGhlc2UgYWxs b2NhdGlvbnMsIGFuZCBkb2VzIHRoYXQgbWF0dGVyPwoKRURJVE9SSUFMIENPTU1FTlRT Cgo+ICAgICAgLSBBbGxvd3Mgc2l0ZXMgdG8gYmUgY29tYmluZWQgb3IgcHJpdmF0ZWx5 IGludGVyY29ubmVjdGVkIHdpdGhvdXQKPiAgICAgICAgY3JlYXRpbmcgYW55IGFkZHJl c3MgY29uZmxpY3RzIG9yIHJlcXVpcmUgcmVudW1iZXJpbmcgb2YKPiAgICAgICAgaW50 ZXJmYWNlcyB1c2luZyB0aGVzZSBwcmVmaXhlcy4KCnMvcmVxdWlyZS9yZXF1aXJpbmcK Cj4gICBTaXRlIGJvcmRlciByb3V0ZXJzIGFuZCBmaXJld2FsbHMgc2hvdWxkIG5vdCBm b3J3YXJkIGFueSBwYWNrZXRzIHdpdGgKPiAgIExvY2FsIElQdjYgc291cmNlIG9yIGRl c3RpbmF0aW9uIGFkZHJlc3NlcyBvdXRzaWRlIG9mIHRoZSBzaXRlIHVubGVzcwo+ICAg dGhleSBoYXZlIGJlZW4gZXhwbGljaXRseSBjb25maWd1cmVkIHdpdGggcm91dGluZyBp bmZvcm1hdGlvbiBhYm91dAo+ICAgb3RoZXIgTG9jYWwgSVB2NiBwcmVmaXhlcy4gIAoK cy9vdGhlci8vICA/PwoKPjE0LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCkRpZCB5b3Ug cmVhbGx5IG1hbmFnZSB0byBnZXQgdGhyb3VnaCB0aGlzIGVudGlyZSBkb2N1bWVudCB3 aXRob3V0CnJlcXVpcmluZyBhbnkgcmVmZXJlbmNlIChub3JtYXRpdmUgb3IgaW5mb3Jt YXRpdmUpIHRvIHRoZSBTY29wZWQKQWRkcmVzcyBBcmNoaXRlY3R1cmU/ICBJIHNlZW0g dG8gcmVjYWxsIHNvbWUgbWVudGlvbiBvZiBsaW5rLWxvY2FsCmFkZHJlc3NlcywgZm9y IGV4YW1wbGUuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKZHJhZnQtaWV0 Zi1pcHY2LXVuaXF1ZS1sb2NhbC1hZGRyLTAzLnR4dCAgICAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgMTRdCgwKSU5URVJORVQtRFJBRlQgICAgIFVuaXF1ZSBMb2NhbCBJUHY2 IFVuaWNhc3QgQWRkcmVzc2VzICAgICBGZWJydWFyeSAyMDA0CgoKMTYuMCBDaGFuZ2Ug TG9nCgogICBEcmFmdCA8ZHJhZnQtaWV0Zi1pcHY2LXVuaXF1ZS1sb2NhbC1hZGRyLTAz LnR4dD4KCiAgICAgIG8gUmVtb3ZlZCByZXF1aXJlbWVudCBvZiBhIGZlZSBwZXIgY2Vu dHJhbCBhbGxvY2F0aW9uIGFuZCB1cGRhdGVkCiAgICAgICAgSUFOQSBjb25zaWRlcmF0 aW9ucyB0byByZWZsZWN0IHRoaXMuICBSZXdyb3RlIHRleHQgdG8gZm9jdXMgb24KICAg ICAgICB0aGUgcmVxdWlyZW1lbnQgdG8gYXZvaWQgaG9hcmRpbmcgb2YgYWxsb2NhdGlv bnMuCiAgICAgIG8gQ2hhbmdlZCAiZmlsdGVyaW5nIiBhbmQgImJsYWNrIGhvbGUgcm91 dGVzIiB0byAicmVqZWN0IiByb3V0ZXMuCiAgICAgIG8gQ2hhbmdlZCB1cHBlcnMgY2Fz ZSByZXF1aXJlbWVudHMgKGkuZS4sIE1VU1QsIFNIT1VMRCwgZXRjLikgdG8KICAgICAg ICBsb3dlciBjYXNlIGluIHNlY3Rpb25zIGdpdmluZyBvcGVyYXRpb25hbCBhZHZpY2Uu CiAgICAgIG8gUmVtb3ZlZCBwYXJhZ3JhcGggbWVudGlvbmluZyAiTXVsdGljYXN0IERO UyIuCiAgICAgIG8gVmFyaW91cyBlZGl0b3JpYWwgY2hhbmdlcy4KCiAgIERyYWZ0IDxk cmFmdC1pZXRmLWlwdjYtdW5pcXVlLWxvY2FsLWFkZHItMDIudHh0PgoKICAgICAgbyBS ZW1vdmVkIG1lbnRpb24gb2YgMTAgZXVybyBjaGFyZ2UgYW5kIGNoYW5nZWQgdGV4dCBp biBzZWN0aW9uCiAgICAgICAgMy4yLjEgYW5kIElBTkEgY29uc2lkZXJhdGlvbnMgdG8g cmVzdGF0ZSB0aGUgcmVxdWlyZW1lbnQgZm9yIGxvdwogICAgICAgIGNvc3QgYWxsb2Nh dGlvbnMgYW5kIGFkZGVkIHNwZWNpZmljIHJlcXVpcmVtZW50IHRvIHByZXZlbnQKICAg ICAgICBob3JkaW5nLgogICAgICBvIEFkZGVkIG5lZWQgdG8gc2VuZCBJQ01QdjYgZGVz dGluYXRpb24gdW5yZWFjaGFibGUgbWVzc2FnZXMgaWYKICAgICAgICBwYWNrZXRzIGFy ZSBmaWx0ZXJlZCBvciBkcm9wcGVkIGF0IHNpdGUgYm91bmRhcmllcy4KICAgICAgbyBD aGFuZ2VkIGZvcm1hdCBzZWN0aW9uIHRvIGxpc3QgcHJlZml4IHNpemVzIGFuZCBkZWZp bml0aW9uLCBhbmQKICAgICAgICBjaGFuZ2VkIGRpc2N1c3Npb24gb2YgcHJlZml4IHNp emVzIHRvIG5ldyBiYWNrZ3JvdW5kIHNlY3Rpb24uCiAgICAgIG8gVmFyaW91cyBlZGl0 b3JpYWwgY2hhbmdlcy4KCiAgIERyYWZ0IDxkcmFmdC1pZXRmLWlwdjYtdW5pcXVlLWxv Y2FsLWFkZHItMDEudHh0PgoKICAgICAgbyBSZW1vdmVkIGV4YW1wbGUgb2YgUElSIGFz IGFuIGV4YW1wbGUgb2YgYW4gYWxsb2NhdGlvbiBhdXRob3JpdHkKICAgICAgICBhbmQg Y2xhcmlmaWVkIHRoZSB0ZXh0IHRoYXQgdGhlIElBTkEgc2hvdWxkIGRlbGVnYXRlIHRo ZQogICAgICAgIGNlbnRyYWxseSBhc3NpZ25lZCBwcmVmaXggdG8gYW4gYWxsb2NhdGlv biBhdXRob3JpdHkuCiAgICAgIG8gQ2hhbmdlZCBzYW1wbGUgY29kZSBmb3IgZ2VuZXJh dGluZyBwc2V1ZG8gcmFuZG9tIEdsb2JhbCBJRHMgdG8KICAgICAgICBub3QgcmVxdWly ZSBhbnkgaHVtYW4gaW5wdXQuICBDaGFuZ2VzIGZyb20gdXNpbmcgYmlydGhkYXkgdG8K ICAgICAgICB1bmlxdWUgdG9rZW4gKGUuZy4sIEVVSS02NCwgc2VyaWFsIG51bWJlciwg ZXRjLikgIGF2YWlsYWJsZSBvbgogICAgICAgIG1hY2hpbmUgcnVubmluZyB0aGUgYWxn b3JpdGhtLgogICAgICBvIEFkZGVkIGEgbmV3IHNlY3Rpb24gYW5hbHl6aW5nIHRoZSB1 bmlxdWVuZXNzIHByb3BlcnRpZXMgb2YgdGhlCiAgICAgICAgcHNldWRvIHJhbmRvbSBu dW1iZXIgYWxnb3JpdGhtLgogICAgICBvIEFkZGVkIHRleHQgdG8gcmVjb21tZW5kIHRo YXQgY2VudHJhbGx5IGFzc2lnbmVkIGxvY2FsIGFkZHJlc3NlcwogICAgICAgIGJlIHVz ZWQgZm9yIHNpdGUgcGxhbm5pbmcgZXh0ZW5zaXZlIGludGVyLXNpdGUgY29tbXVuaWNh dGlvbi4KICAgICAgbyBDbGFyaWZpZWQgdGhhdCBkb21haW4gYm9yZGVyIHJvdXRlcnMg c2hvdWxkIGZvbGxvdyBzaXRlIGJvcmRlcgogICAgICAgIHJvdXRlciByZWNvbW1lbmRh dGlvbnMuCiAgICAgIG8gQ2xhcmlmaWVkIHRoYXQgQUFBQSBETlMgcmVjb3JkcyBzaG91 bGQgbm90IGJlIGluc3RhbGxlZCBpbiB0aGUKICAgICAgICBnbG9iYWwgRE5TLgogICAg ICBvIFNldmVyYWwgZWRpdG9yaWFsIGNoYW5nZXMuCgogICBEcmFmdCA8ZHJhZnQtaWV0 Zi1pcHY2LXVuaXF1ZS1sb2NhbC1hZGRyLTAwLnR4dD4KCiAgICAgIG8gQ2hhbmdlZCBm aWxlIG5hbWUgdG8gYmVjb21lIGFuIElQdjYgdy5nLiBncm91cCBkb2N1bWVudC4KICAg ICAgbyBDbGFyaWZpZWQgbGFuZ3VhZ2UgaW4gUm91dGluZyBhbmQgRmlyZXdhbGwgc2Vj dGlvbnMuCgoKCmRyYWZ0LWlldGYtaXB2Ni11bmlxdWUtbG9jYWwtYWRkci0wMy50eHQg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE1XQoMCklOVEVSTkVULURSQUZUICAg ICBVbmlxdWUgTG9jYWwgSVB2NiBVbmljYXN0IEFkZHJlc3NlcyAgICAgRmVicnVhcnkg MjAwNAoKCiAgICAgIG8gU2V2ZXJhbCBlZGl0b3JpYWwgY2hhbmdlcy4KCiAgIERyYWZ0 IDxkcmFmdC1oaW5kZW4taXB2Ni1nbG9iYWwtbG9jYWwtYWRkci0wMi50eHQ+CgogICAg ICBvIENoYW5nZWQgdGl0bGUgYW5kIG5hbWUgb2YgYWRkcmVzc2VzIGRlZmluZWQgaW4g dGhpcyBkb2N1bWVudCB0bwogICAgICAgICJVbmlxdWUgTG9jYWwgSVB2NiBVbmljYXN0 IEFkZHJlc3NlcyIgd2l0aCBhYmJyZXZpYXRpb24gb2YKICAgICAgICAiTG9jYWwgSVB2 NiBhZGRyZXNzZXMiLgogICAgICBvIFNldmVyYWwgZWRpdG9yaWFsIGNoYW5nZXMuCgog ICBEcmFmdCA8ZHJhZnQtaGluZGVuLWlwdjYtZ2xvYmFsLWxvY2FsLWFkZHItMDEudHh0 PgoKICAgICAgbyBBZGRlZCBzZWN0aW9uIG9uIHNjb3BlIGRlZmluaXRpb24gYW5kIHVw ZGF0ZWQgYXBwbGljYXRpb24KICAgICAgICByZXF1aXJlbWVudCBzZWN0aW9uLgogICAg ICBvIENsYXJpZmllZCB0aGF0LCBieSBkZWZhdWx0LCB0aGUgc2NvcGUgb2YgdGhlc2Ug YWRkcmVzc2VzIGlzCiAgICAgICAgZ2xvYmFsLgogICAgICBvIFJlbnVtYmVyZWQgc2Vj dGlvbnMgYW5kIGdlbmVyYWwgdGV4dCBpbXByb3ZlbWVudHMKICAgICAgbyBSZW1vdmVk IHJlc2VydmVkIGdsb2JhbCBJRCB2YWx1ZXMKICAgICAgbyBBZGRlZCBwc2V1ZG8gY29k ZSBmb3IgbG9jYWwgYWxsb2NhdGlvbiBzdWJtaXR0ZWQgYnkgQnJpYW4KICAgICAgICBI YWJlcm1hbiBhbmQgYWRkZWQgaGltIGFzIGFuIGF1dGhvci4KICAgICAgbyBTcGxpdCBH bG9iYWwgSUQgdmFsdWVzIGludG8gY2VudHJhbGx5IGFzc2lnbmVkIGFuZCBsb2NhbAog ICAgICAgIGFzc2lnbm1lbnRzIGFuZCBhZGRlZCB0ZXh0IHRvIGRlc2NyaWJlIGxvY2Fs IGFzc2lnbm1lbnRzCgogICBEcmFmdCA8ZHJhZnQtaGluZGVuLWlwdjYtZ2xvYmFsLWxv Y2FsLWFkZHItMDAudHh0PgoKICAgICAgbyBJbml0aWFsIERyYWZ0CgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKZHJhZnQtaWV0Zi1pcHY2LXVuaXF1ZS1sb2NhbC1hZGRyLTAz LnR4dCAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgo= --============_-1132844589==_D============-- --============_-1132844589==_============-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Mar 14 21:35:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19826 for ; Sun, 14 Mar 2004 21:35:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2hwx-0008HR-QI for ipv6-archive@odin.ietf.org; Sun, 14 Mar 2004 21:35:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F2ZV7O031828 for ipv6-archive@odin.ietf.org; Sun, 14 Mar 2004 21:35:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2hwx-0008HG-Gt for ipv6-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 21:35:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19788 for ; Sun, 14 Mar 2004 21:35:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2hwu-0004IU-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 21:35:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2hvy-00049t-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 21:34:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2hv6-00041h-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 21:33:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2huX-0007vc-HW; Sun, 14 Mar 2004 21:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2hu6-0007tT-Tr for ipv6@optimus.ietf.org; Sun, 14 Mar 2004 21:32:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19621 for ; Sun, 14 Mar 2004 21:32:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2hu4-0003tR-00 for ipv6@ietf.org; Sun, 14 Mar 2004 21:32:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2htC-0003mi-00 for ipv6@ietf.org; Sun, 14 Mar 2004 21:31:39 -0500 Received: from smtp.exodus.net ([66.35.230.237] helo=smtp02-w.exodus.net) by ietf-mx with esmtp (Exim 4.12) id 1B2hsY-0003e1-00 for ipv6@ietf.org; Sun, 14 Mar 2004 21:30:59 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i2ENcOEv000650 for ; Sun, 14 Mar 2004 17:38:29 -0600 Received: from [192.168.2.2] (unverified [24.61.30.237]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Sun, 14 Mar 2004 18:30:10 -0800 Mime-Version: 1.0 X-Sender: margaret@thingmagic.com@ms101.mail1.com Message-Id: Date: Sun, 14 Mar 2004 21:29:59 -0500 To: ipv6@ietf.org From: Margaret Wasserman Subject: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Apparently there are some people in the IETF who use mail readers that cannot handle standard text attachments. For those people, here is a resend of the e-mail I sent earlier with the attachment included in-line. Sorry for the duplication. Hi All, I've completed my AD evaluation of draft-ietf-ipv6-unique-local-addr-03.txt. My comments (attached below) include a few substantive issues that I would like to discuss with the WG before sending this draft to IETF last call. Thoughts? I have also included a few non-blocking editorial comments that should be addresses in the next revision, if any. Margaret SUBSTANTIVE ISSUES: (1) This draft doesn't mention the reverse DNS tree. Is it expected that whatever registry assigns these values will also populate the reverse DNS tree? Or not? (2) The document says: > Global IDs should be assigned centrally by a single allocation > authority because they are pseudo-random and without any structure. > This is easiest to accomplish if there is a single source for the > assignments. This would appear to be incompatible with the IANA considerations section that says: > If deemed > appropriate, the authority may also consist of multiple organizations > performing the authority duties. To avoid a situation where a single entity can request a large number of local prefixes and aggregate them, it isn't strictly necessary that the addresses be allocated from a single pool. If there were several pools (for different geographical regions, for example) random allocations from one of those pools would achieve the same result. (3) The document also says: > The requirements for centrally assigned global ID allocations are: > > - Available to anyone in an unbiased manner. > - Permanent with no periodic fees. It seems strange to say that there can be no periodic fees when the document doesn't mention fees anywhere else... Perhaps this is a leftover from previous versions of the document that did include a fee structure? > - Allocation on a permanent basis, without any need for renewal > and without any procedure for de-allocation. > - Provide mechanisms that prevent hoarding of these allocations. > - The ownership of each individual allocation should be private, > but should be escrowed. I am not sure that requiring a permanent escrow is consistent with the idea that there will be no ongoing revenue stream (i.e. periodic fees) associated with an address. (4) The algorithm for random number generation is: >3.2.3 Sample Code for Pseudo-Random Global ID Algorithm > > The algorithm described below is intended to be used for centrally > and locally assigned Global IDs. In each case the resulting global > ID will be used in the appropriate prefix as defined in section 3.2. > > 1) Obtain the current time of day in 64-bit NTP format [NTP]. > 2) Obtain an EUI-64 identifier from the system running this > algorithm. If an EUI-64 does not exist, one can be created from > a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 > cannot be obtained or created, a suitably unique identifier, > local to the node, should be used (e.g. system serial number). > 3) Concatenate the time of day with the system-specific identifier > creating a key. > 4) Compute an MD5 digest on the key as specified in [MD5DIG]. > 5) Use the least significant 40 bits as the Global ID. > > This algorithm will result in a global ID that is reasonably unique > and can be used as a Global ID. Are you intending that centrally assigned addresses will all be generated using the EUI-64 address of a server at the centralized registration authority? What affect would this have on the randomness of these allocations, and does that matter? EDITORIAL COMMENTS > - Allows sites to be combined or privately interconnected without > creating any address conflicts or require renumbering of > interfaces using these prefixes. s/require/requiring > Site border routers and firewalls should not forward any packets with > Local IPv6 source or destination addresses outside of the site unless > they have been explicitly configured with routing information about > other Local IPv6 prefixes. s/other// ?? >14.1 Normative References Did you really manage to get through this entire document without requiring any reference (normative or informative) to the Scoped Address Architecture? I seem to recall some mention of link-local addresses, for example. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Mar 14 23:46:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23907 for ; Sun, 14 Mar 2004 23:46:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2jyu-00088C-AV for ipv6-archive@odin.ietf.org; Sun, 14 Mar 2004 23:45:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F4jeVY031250 for ipv6-archive@odin.ietf.org; Sun, 14 Mar 2004 23:45:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2jyu-00087x-5P for ipv6-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 23:45:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23869 for ; Sun, 14 Mar 2004 23:45:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2jys-0003CS-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 23:45:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2jxy-00035m-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 23:44:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2jxg-0002yi-00 for ipv6-web-archive@ietf.org; Sun, 14 Mar 2004 23:44:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2jxJ-0007su-M6; Sun, 14 Mar 2004 23:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2jww-0007rc-7Y for ipv6@optimus.ietf.org; Sun, 14 Mar 2004 23:43:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23711 for ; Sun, 14 Mar 2004 23:43:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2jwt-0002xG-00 for ipv6@ietf.org; Sun, 14 Mar 2004 23:43:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2jw0-0002qT-00 for ipv6@ietf.org; Sun, 14 Mar 2004 23:42:41 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1B2jvM-0002jQ-00 for ipv6@ietf.org; Sun, 14 Mar 2004 23:42:01 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 14 Mar 2004 20:41:34 -0800 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 14 Mar 2004 20:41:24 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 14 Mar 2004 20:41:28 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 14 Mar 2004 20:41:29 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 14 Mar 2004 20:41:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Unique local & DNS (was: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt+ Date: Sun, 14 Mar 2004 20:41:26 -0800 Message-ID: Thread-Topic: Unique local & DNS (was: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt+ thread-index: AcQKNhJS2WW6X8ZuQ/Gn0moA+GWOzQAD7AbQ From: "Christian Huitema" To: "Margaret Wasserman" , X-OriginalArrivalTime: 15 Mar 2004 04:41:27.0881 (UTC) FILETIME=[C779A390:01C40A47] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In her review of "draft-ietf-ipv6-unique-local-addr-03.txt", Margaret raises an excellent point: =20 > (1) This draft doesn't mention the reverse DNS tree. Is it expected that > whatever registry assigns these values will also populate the reverse > DNS tree? Or not? The registration process could conceivably populate the reverse DNS tree, but that would only be a partial solution: the draft also defines random prefixes that don't need to be registered. Also, there is no requirement that the networks numbered with these unique local addresses be accessible to DNS resolvers on the Internet. We may however want some kind of "theory of operation". When a network is numbered using unique local addresses, hosts in that network will want to resolve addresses to names. There are 2 possible solutions: 1) Add specific knowledge of this reverse tree to the DNS servers in the unique-local-addressed site, 2) Perform reverse name resolution by asking the host itself, sending either a host information query or an LLMNR PTR request to the IPv6 address being resolved. The first solution is similar to the "dual face DNS" deployments common in organization networks, and should probably be the normal case. It does not require registration in the ip6.arpa tree. It does however require some coordination between DNS servers of unique-local-addressed sites when these sites establish a back-door connection. This coordination could be facilitated if we used a conventional host identifier for "the DNS server within a uniquely addressed site". We generally shied away from the second solution, and generally from using the host identification query to provide reverse mappings. Using LLMNR does make sense when LLMNR is also used as the primary name resolution service within the unique-local-addressed site. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 15 01:27:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27784 for ; Mon, 15 Mar 2004 01:27:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2lYc-0006XD-AH for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 01:26:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F6Qc1g025113 for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 01:26:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2lYb-0006Wy-HK for ipv6-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 01:26:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27747 for ; Mon, 15 Mar 2004 01:26:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2lYY-0000XI-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 01:26:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2lXZ-0000QF-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 01:25:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2lWb-0000KI-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 01:24:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2lW5-0006F4-UK; Mon, 15 Mar 2004 01:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2lVh-0006EP-TX for ipv6@optimus.ietf.org; Mon, 15 Mar 2004 01:23:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27674 for ; Mon, 15 Mar 2004 01:23:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2lVe-0000Dg-00 for ipv6@ietf.org; Mon, 15 Mar 2004 01:23:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2lUh-00006t-00 for ipv6@ietf.org; Mon, 15 Mar 2004 01:22:35 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2lU5-0007fs-00 for ipv6@ietf.org; Mon, 15 Mar 2004 01:21:57 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2F6LFQ27170; Mon, 15 Mar 2004 08:21:15 +0200 Date: Mon, 15 Mar 2004 08:21:15 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: Margaret Wasserman , Subject: Re: Unique local & DNS (was: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt+ In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Sun, 14 Mar 2004, Christian Huitema wrote: > We generally shied away from the second solution, and generally from > using the host identification query to provide reverse mappings. Using > LLMNR does make sense when LLMNR is also used as the primary name > resolution service within the unique-local-addressed site. Using LLMNR makes no sense in the generic case; at least the name says "link-local" and the case where the site using local addresses would be restricted to single link is not generic enough. -- 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 exim@www1.ietf.org Mon Mar 15 03:14:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14035 for ; Mon, 15 Mar 2004 03:14:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2nEB-0005Yi-2g for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 03:13:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F8DdZN021368 for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 03:13:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2nEA-0005YZ-FG for ipv6-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 03:13:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14017 for ; Mon, 15 Mar 2004 03:13:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2nE8-0004gX-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 03:13:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2nDA-0004aE-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 03:12:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2nCO-0004Uf-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 03:11:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2nBf-0005CU-Pm; Mon, 15 Mar 2004 03:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2nBH-0005Bj-LC for ipv6@optimus.ietf.org; Mon, 15 Mar 2004 03:10:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13959 for ; Mon, 15 Mar 2004 03:10:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2nBD-0004OU-00 for ipv6@ietf.org; Mon, 15 Mar 2004 03:10:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2nAL-0004Is-00 for ipv6@ietf.org; Mon, 15 Mar 2004 03:09:42 -0500 Received: from imhotep.hursley.ibm.com ([195.212.14.170] helo=mail-gw2.hursley.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1B2n9W-00045g-00 for ipv6@ietf.org; Mon, 15 Mar 2004 03:08:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B2n8z-00025G-00; Mon, 15 Mar 2004 08:08:17 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B2n8z-00025B-00; Mon, 15 Mar 2004 08:08:17 +0000 Received: from zurich.ibm.com (sig-9-145-143-4.de.ibm.com [9.145.143.4]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2F88GF101022; Mon, 15 Mar 2004 08:08:17 GMT Message-ID: <4055648E.AA0E0D09@zurich.ibm.com> Date: Mon, 15 Mar 2004 09:08:46 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Margaret Wasserman CC: ipv6@ietf.org Subject: Re: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Margaret Wasserman wrote: ... > SUBSTANTIVE ISSUES: > > (1) This draft doesn't mention the reverse DNS tree. Is it expected that > whatever registry assigns these values will also populate the reverse > DNS tree? Or not? I think it is better to leave this question for a separate document (which certainly needs to be written). I don't think we should delay the present document for this. > > (2) The document says: > > > Global IDs should be assigned centrally by a single allocation > > authority because they are pseudo-random and without any structure. > > This is easiest to accomplish if there is a single source for the > > assignments. > > This would appear to be incompatible with the IANA considerations > section that says: > > > If deemed > > appropriate, the authority may also consist of multiple organizations > > performing the authority duties. > > To avoid a situation where a single entity can request a large number > of local prefixes and aggregate them, it isn't strictly necessary that > the addresses be allocated from a single pool. If there were several > pools (for different geographical regions, for example) random > allocations from one of those pools would achieve the same result. Yes. I suggest rewriting the first extract as: Global IDs should be assigned under the authority of a single allocation organization because they are pseudo-random and without any structure. This is easiest to accomplish if there is a single authority for the assignments. > > (3) The document also says: > > > The requirements for centrally assigned global ID allocations are: > > > > - Available to anyone in an unbiased manner. > > - Permanent with no periodic fees. > > It seems strange to say that there can be no periodic fees when the > document doesn't mention fees anywhere else... Perhaps this is a > leftover from previous versions of the document that did include a fee > structure? No, I think it is a principle and a directive to the IANA that we should keep. > > - Allocation on a permanent basis, without any need for renewal > > and without any procedure for de-allocation. > > - Provide mechanisms that prevent hoarding of these allocations. > > - The ownership of each individual allocation should be private, > > but should be escrowed. > > I am not sure that requiring a permanent escrow is consistent with the > idea that there will be no ongoing revenue stream (i.e. periodic fees) > associated with an address. But it's a matter of principle. If the IANA really thinks this is an issue, it's for them to say so, not us. > > (4) The algorithm for random number generation is: > > >3.2.3 Sample Code for Pseudo-Random Global ID Algorithm > > > > The algorithm described below is intended to be used for centrally > > and locally assigned Global IDs. In each case the resulting global > > ID will be used in the appropriate prefix as defined in section 3.2. > > > > 1) Obtain the current time of day in 64-bit NTP format [NTP]. > > 2) Obtain an EUI-64 identifier from the system running this > > algorithm. If an EUI-64 does not exist, one can be created from > > a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 > > cannot be obtained or created, a suitably unique identifier, > > local to the node, should be used (e.g. system serial number). > > 3) Concatenate the time of day with the system-specific identifier > > creating a key. > > 4) Compute an MD5 digest on the key as specified in [MD5DIG]. > > 5) Use the least significant 40 bits as the Global ID. > > > > This algorithm will result in a global ID that is reasonably unique > > and can be used as a Global ID. > > Are you intending that centrally assigned addresses will all be > generated using the EUI-64 address of a server at the centralized > registration authority? What affect would this have on the randomness > of these allocations, and does that matter? Actually the randomness doesn't matter much - we need enough randomness to ensure that people don't imagine these things aggregate, but there is no need for a mathematically "good" randomness. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 15 04:28:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17054 for ; Mon, 15 Mar 2004 04:28:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2oO6-0001ae-G7 for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 04:27:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F9Rw2O006106 for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 04:27:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2oO5-0001aL-Mx for ipv6-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 04:27:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16988 for ; Mon, 15 Mar 2004 04:27:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2oO2-0006f8-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 04:27:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2oN2-0006SJ-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 04:26:53 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B2oLu-0006D6-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 04:25:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B2oLw-0004AM-Ak for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 04:25:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2oKy-0000uU-2K; Mon, 15 Mar 2004 04:24:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2o5P-0008D1-1c for ipv6@optimus.ietf.org; Mon, 15 Mar 2004 04:08:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15736 for ; Mon, 15 Mar 2004 04:08:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2o5M-0003eT-00 for ipv6@ietf.org; Mon, 15 Mar 2004 04:08:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2o4N-0003Vt-00 for ipv6@ietf.org; Mon, 15 Mar 2004 04:07:36 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1B2o3P-0003Dk-00 for ipv6@ietf.org; Mon, 15 Mar 2004 04:06:35 -0500 Received: from ssprunk (ip144.post-vineyard.dfw.ygnition.net [66.135.181.144]) by ns2.sea (8.12.11/8.12.5) with SMTP id i2F95uos015231; Mon, 15 Mar 2004 01:05:57 -0800 Message-ID: <006201c40a6c$baf59960$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Brian E Carpenter" , "Margaret Wasserman" Cc: References: <4055648E.AA0E0D09@zurich.ibm.com> Subject: Re: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt Date: Mon, 15 Mar 2004 02:57:42 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Brian E Carpenter" > Margaret Wasserman wrote: > ... > > SUBSTANTIVE ISSUES: > > > > (1) This draft doesn't mention the reverse DNS tree. Is it expected that > > whatever registry assigns these values will also populate the reverse > > DNS tree? Or not? > > I think it is better to leave this question for a separate document (which > certainly needs to be written). I don't think we should delay the present > document for this. I think this revolves around a basic question of whether information about centrally-assigned local prefixes should be available to third parties. If so -- and that is my preference -- then WHOIS information should be provided and DNS delegations should be available, though not mandatory. Optional global DNS delegations may be beneficial to those using local addresses to communicate privately between organizations because it can remove the need for split DNS. > Yes. I suggest rewriting the first extract as: > > Global IDs should be assigned under the authority of a single allocation > organization because they are pseudo-random and without any structure. > This is easiest to accomplish if there is a single authority for the > assignments. This wording still doesn't seem consistent with the possibility of having multiple central authorities. If we are going to allow IANA the discretion to assign multiple allocators, then we need to specify how that will be handled, i.e. either assigning sub-prefixes to each authority or requiring real-time checking between authorities to prevent collisions. > > It seems strange to say that there can be no periodic fees when the > > document doesn't mention fees anywhere else... Perhaps this is a > > leftover from previous versions of the document that did include a fee > > structure? > > No, I think it is a principle and a directive to the IANA that we should > keep. Agreed. Perhaps we should emphasize the permanent (i.e. rent-free) nature of these allocations earlier in the draft so this statement doesn't seem out of place? > > I am not sure that requiring a permanent escrow is consistent with the > > idea that there will be no ongoing revenue stream (i.e. periodic fees) > > associated with an address. > > But it's a matter of principle. If the IANA really thinks this is an issue, > it's for them to say so, not us. This is more of a business concern than a technical one, which seems outside the IETF's purview. Maybe under IANA considerations we could add a statement about how IANA should require a prospective allocation authority present how it can fund indefinite operation from one-time fees? As has been discussed, any competent accountant can figure how to determine a one-time fee that equates to indefinitely recurring fees. It might be desirable for IANA/ISOC/whoever to set up a permanent trust which receives one-time allocation fees and pays recurring fees (from interest) to the actual allocation authority; such trust could also be responsible for the escrow of registrations. This would protect against bankruptcy of (or subsequent change in) the particular allocation authority. I'm not sure this level of detail belongs in the draft, but this is the model I had in mind. > > Are you intending that centrally assigned addresses will all be > > generated using the EUI-64 address of a server at the centralized > > registration authority? What affect would this have on the randomness > > of these allocations, and does that matter? > > Actually the randomness doesn't matter much - we need enough > randomness to ensure that people don't imagine these things aggregate, > but there is no need for a mathematically "good" randomness. It's possible that the generation method could be bottlenecked by the rate of timestamp changes if centrally-assigned prefixes become very popular. Since the centrally-assigned half of the address space doesn't need the level of collision prevention that the locally-assigned half does, could we change this from a MUST to a SHOULD for the former? Any pseudo-random algorithm should be sufficient for a central authority, provided it gives no potential for aggregation. 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 exim@www1.ietf.org Mon Mar 15 04:34:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17352 for ; Mon, 15 Mar 2004 04:34:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2oTg-0002B9-Ek for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 04:33:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2F9XijG008369 for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 04:33:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2oTe-0002Au-Ef for ipv6-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 04:33:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17346 for ; Mon, 15 Mar 2004 04:33:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2oTb-0007VE-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 04:33:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2oSi-0007PP-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 04:32:45 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B2oSQ-0007Il-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 04:32:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B2oSQ-0004LK-MR for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 04:32:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2oS3-0001pa-07; Mon, 15 Mar 2004 04:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2oRp-0001op-40 for ipv6@optimus.ietf.org; Mon, 15 Mar 2004 04:31:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17296 for ; Mon, 15 Mar 2004 04:31:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2oRm-0007Hn-00 for ipv6@ietf.org; Mon, 15 Mar 2004 04:31:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2oR4-0007BA-00 for ipv6@ietf.org; Mon, 15 Mar 2004 04:31:03 -0500 Received: from imhotep.hursley.ibm.com ([195.212.14.170] helo=mail-gw2.hursley.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1B2oQG-0006yD-00 for ipv6@ietf.org; Mon, 15 Mar 2004 04:30:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B2oPn-0006NO-00; Mon, 15 Mar 2004 09:29:43 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1B2oPn-0006NJ-00; Mon, 15 Mar 2004 09:29:43 +0000 Received: from zurich.ibm.com (sig-9-145-143-4.de.ibm.com [9.145.143.4]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i2F9TgF94010; Mon, 15 Mar 2004 09:29:42 GMT Message-ID: <405577A3.E3836826@zurich.ibm.com> Date: Mon, 15 Mar 2004 10:30:11 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Stephen Sprunk CC: Margaret Wasserman , ipv6@ietf.org Subject: Re: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt References: <4055648E.AA0E0D09@zurich.ibm.com> <006201c40a6c$baf59960$6401a8c0@ssprunk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit in line... Stephen Sprunk wrote: > > Thus spake "Brian E Carpenter" > > Margaret Wasserman wrote: > > ... > > > SUBSTANTIVE ISSUES: > > > > > > (1) This draft doesn't mention the reverse DNS tree. Is it expected > that > > > whatever registry assigns these values will also populate the > reverse > > > DNS tree? Or not? > > > > I think it is better to leave this question for a separate document (which > > certainly needs to be written). I don't think we should delay the present > > document for this. > > I think this revolves around a basic question of whether information about > centrally-assigned local prefixes should be available to third parties. If > so -- and that is my preference -- then WHOIS information should be provided > and DNS delegations should be available, though not mandatory. Optional > global DNS delegations may be beneficial to those using local addresses to > communicate privately between organizations because it can remove the need > for split DNS. > > > Yes. I suggest rewriting the first extract as: > > > > Global IDs should be assigned under the authority of a single allocation > > organization because they are pseudo-random and without any structure. > > This is easiest to accomplish if there is a single authority for the > > assignments. > > This wording still doesn't seem consistent with the possibility of having > multiple central authorities. If we are going to allow IANA the discretion > to assign multiple allocators, then we need to specify how that will be > handled, i.e. either assigning sub-prefixes to each authority or requiring > real-time checking between authorities to prevent collisions. Send text? I meant mine to say that the authority (IANA) is unique - that doesn't preclude (or require) sub delegation. > > > > It seems strange to say that there can be no periodic fees when the > > > document doesn't mention fees anywhere else... Perhaps this is a > > > leftover from previous versions of the document that did include a > fee > > > structure? > > > > No, I think it is a principle and a directive to the IANA that we should > > keep. > > Agreed. Perhaps we should emphasize the permanent (i.e. rent-free) nature > of these allocations earlier in the draft so this statement doesn't seem out > of place? > > > > I am not sure that requiring a permanent escrow is consistent with > the > > > idea that there will be no ongoing revenue stream (i.e. periodic > fees) > > > associated with an address. > > > > But it's a matter of principle. If the IANA really thinks this is an > issue, > > it's for them to say so, not us. > > This is more of a business concern than a technical one, which seems outside > the IETF's purview. Maybe under IANA considerations we could add a > statement about how IANA should require a prospective allocation authority > present how it can fund indefinite operation from one-time fees? As has > been discussed, any competent accountant can figure how to determine a > one-time fee that equates to indefinitely recurring fees. > > It might be desirable for IANA/ISOC/whoever to set up a permanent trust > which receives one-time allocation fees and pays recurring fees (from > interest) to the actual allocation authority; such trust could also be > responsible for the escrow of registrations. This would protect against > bankruptcy of (or subsequent change in) the particular allocation authority. > I'm not sure this level of detail belongs in the draft, but this is the > model I had in mind. That certainly doesn't belong in an IETF document. But saying "no recurring fee" seems to me to be something we *can* say. And that's the text that went through WG last call. Brian > > > > Are you intending that centrally assigned addresses will all be > > > generated using the EUI-64 address of a server at the centralized > > > registration authority? What affect would this have on the > randomness > > > of these allocations, and does that matter? > > > > Actually the randomness doesn't matter much - we need enough > > randomness to ensure that people don't imagine these things aggregate, > > but there is no need for a mathematically "good" randomness. > > It's possible that the generation method could be bottlenecked by the rate > of timestamp changes if centrally-assigned prefixes become very popular. > Since the centrally-assigned half of the address space doesn't need the > level of collision prevention that the locally-assigned half does, could we > change this from a MUST to a SHOULD for the former? Any pseudo-random > algorithm should be sufficient for a central authority, provided it gives no > potential for aggregation. > > 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 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 15 10:24:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03061 for ; Mon, 15 Mar 2004 10:24:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2twl-00046N-Ez for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 10:24:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FFO7pi015759 for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 10:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2twl-00045y-96 for ipv6-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 10:24:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02996 for ; Mon, 15 Mar 2004 10:24:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2twj-0006FY-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 10:24:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2tvm-00068E-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 10:23:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2tvL-00060u-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 10:22:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tuk-0003PR-Go; Mon, 15 Mar 2004 10:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tuh-0003O3-If for ipv6@optimus.ietf.org; Mon, 15 Mar 2004 10:21:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02724 for ; Mon, 15 Mar 2004 10:21:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2tuf-000607-00 for ipv6@ietf.org; Mon, 15 Mar 2004 10:21:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2ttl-0005tw-00 for ipv6@ietf.org; Mon, 15 Mar 2004 10:21:02 -0500 Received: from web80513.mail.yahoo.com ([66.218.79.83]) by ietf-mx with smtp (Exim 4.12) id 1B2tt2-0005g7-00 for ipv6@ietf.org; Mon, 15 Mar 2004 10:20:16 -0500 Message-ID: <20040315151941.210.qmail@web80513.mail.yahoo.com> Received: from [63.197.18.101] by web80513.mail.yahoo.com via HTTP; Mon, 15 Mar 2004 07:19:41 PST Date: Mon, 15 Mar 2004 07:19:41 -0800 (PST) From: Fred Templin Subject: Re: Unique local & DNS (was: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt+ To: Christian Huitema , Margaret Wasserman , ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-40222091-1079363981=:99314" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 --0-40222091-1079363981=:99314 Content-Type: text/plain; charset=us-ascii Christian, Christian Huitema wrote:We generally shied away from the second solution, and generally from using the host identification query to provide reverse mappings. Is "host identification query" == "Node Information Queries" here? Also, what about other non-DNS naming services that can be deployed within a site/organization? E.g., the Sun Yellow Pages (I guess it's called NIS now?) and the naming service developed by Project Athena at MIT back in the 1980's (not sure on the name of this one, but "Hessiod" rings a bell) still widely used by site administrators? (Feeling a bit like Rip Van Winkle waking up from a 15-yr slumber wrt this technology space...) Fred osprey67@yahoo.com --0-40222091-1079363981=:99314 Content-Type: text/html; charset=us-ascii
Christian,
 
Christian Huitema <huitema@windows.microsoft.com> wrote:
We generally shied away from the second solution, and generally from
using the host identification query to provide reverse mappings.
 
Is "host identification query" == "Node Information Queries" here?
 
Also, what about other non-DNS naming services that can be deployed
within a site/organization? E.g., the Sun Yellow Pages (I guess it's called
NIS now?) and the naming service developed by Project Athena at MIT
back in the 1980's (not sure on the name of this one, but "Hessiod" rings
a bell) still widely used by site administrators? (Feeling a bit like Rip Van
Winkle waking up from a 15-yr slumber wrt this technology space...)
 
Fred
--0-40222091-1079363981=:99314-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 15 13:12:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14136 for ; Mon, 15 Mar 2004 13:12:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wZQ-0006zD-9t for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 13:12:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FICCxJ026851 for ipv6-archive@odin.ietf.org; Mon, 15 Mar 2004 13:12:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wZQ-0006z0-35 for ipv6-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 13:12:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14109 for ; Mon, 15 Mar 2004 13:12:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wZO-00023T-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 13:12:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wYS-000200-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 13:11:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2wXs-0001ww-00 for ipv6-web-archive@ietf.org; Mon, 15 Mar 2004 13:10:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wXO-0006Kd-MF; Mon, 15 Mar 2004 13:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wWT-0006Cs-Qw for ipv6@optimus.ietf.org; Mon, 15 Mar 2004 13:09:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13837 for ; Mon, 15 Mar 2004 13:09:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wWR-0001s5-00 for ipv6@ietf.org; Mon, 15 Mar 2004 13:09:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wVe-0001pM-00 for ipv6@ietf.org; Mon, 15 Mar 2004 13:08:18 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1B2wUo-0001ly-00 for ipv6@ietf.org; Mon, 15 Mar 2004 13:07:27 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2FI7Qwr010080 for ; Mon, 15 Mar 2004 11:07:26 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUM00MCHQCDLX@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 15 Mar 2004 11:07:26 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUM00FDZQCD46@mail.sun.net> for ipv6@ietf.org; Mon, 15 Mar 2004 11:07:25 -0700 (MST) Date: Mon, 15 Mar 2004 10:07:23 -0800 From: Alain Durand Subject: Re: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt In-reply-to: <006201c40a6c$baf59960$6401a8c0@ssprunk> To: Stephen Sprunk Cc: ipv6@ietf.org, Brian E Carpenter , Margaret Wasserman Message-id: <9C0F03A6-76AB-11D8-9F71-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4055648E.AA0E0D09@zurich.ibm.com> <006201c40a6c$baf59960$6401a8c0@ssprunk> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Mar 15, 2004, at 12:57 AM, Stephen Sprunk wrote: > Thus spake "Brian E Carpenter" >> Margaret Wasserman wrote: >> ... >>> SUBSTANTIVE ISSUES: >>> >>> (1) This draft doesn't mention the reverse DNS tree. Is it expected > that >>> whatever registry assigns these values will also populate the > reverse >>> DNS tree? Or not? >> >> I think it is better to leave this question for a separate document >> (which >> certainly needs to be written). I don't think we should delay the >> present >> document for this. > > I think this revolves around a basic question of whether information > about > centrally-assigned local prefixes should be available to third > parties. If > so -- and that is my preference -- then WHOIS information should be > provided > and DNS delegations should be available, though not mandatory. > Optional > global DNS delegations may be beneficial to those using local > addresses to > communicate privately between organizations because it can remove the > need > for split DNS. I too would like to see the reverse tree DNS being delegated. However, as there is no structure, the entire /8 to /48 address space would have to be within one single zone... I'm afraid we are going to create a monster zone that will be very difficult to sign with DNSsec. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 16 08:32:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29988 for ; Tue, 16 Mar 2004 08:32:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EfT-0007bp-0T for ipv6-archive@odin.ietf.org; Tue, 16 Mar 2004 08:31:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GDVcQQ029243 for ipv6-archive@odin.ietf.org; Tue, 16 Mar 2004 08:31:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EfS-0007ba-Ol for ipv6-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 08:31:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29915 for ; Tue, 16 Mar 2004 08:31:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EfR-0003NJ-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 08:31:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3EeR-0003Gu-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 08:30:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3EdV-0003Be-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 08:29:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ecw-0007Mx-0o; Tue, 16 Mar 2004 08:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ebz-0007Ls-15 for ipv6@optimus.ietf.org; Tue, 16 Mar 2004 08:28:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29812 for ; Tue, 16 Mar 2004 08:28:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Ebx-00032v-00 for ipv6@ietf.org; Tue, 16 Mar 2004 08:28:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Eaz-0002xT-00 for ipv6@ietf.org; Tue, 16 Mar 2004 08:27:01 -0500 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1B3EaW-0002qi-00 for ipv6@ietf.org; Tue, 16 Mar 2004 08:26:32 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1B3Ea9-0007GG-00; Tue, 16 Mar 2004 13:26:09 +0000 Date: Tue, 16 Mar 2004 13:26:09 +0000 To: Alain Durand Cc: Stephen Sprunk , ipv6@ietf.org, Brian E Carpenter , Margaret Wasserman Subject: Re: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt Message-ID: <20040316132609.GA3439@fysh.org> References: <4055648E.AA0E0D09@zurich.ibm.com> <006201c40a6c$baf59960$6401a8c0@ssprunk> <9C0F03A6-76AB-11D8-9F71-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C0F03A6-76AB-11D8-9F71-00039376A6AA@sun.com> User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Alain Durand wrote: >I too would like to see the reverse tree DNS being delegated. However, >as there is no >structure, the entire /8 to /48 address space would have to be within >one single zone... There is structure within the domain name segment between /8 and /48 -- it's a sequence of ten DNS labels, not just one. Zone cuts can be introduced at any level to split the job up. -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 16 16:14:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24988 for ; Tue, 16 Mar 2004 16:14:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lt6-0003ju-Jj for ipv6-archive@odin.ietf.org; Tue, 16 Mar 2004 16:14:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GLECVx014370 for ipv6-archive@odin.ietf.org; Tue, 16 Mar 2004 16:14:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lt6-0003jd-Bf for ipv6-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 16:14:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24960 for ; Tue, 16 Mar 2004 16:14:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Lt4-0001UJ-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 16:14:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Ls3-0001Ln-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 16:13:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Lqw-0001Cn-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 16:11:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lq4-0003Jd-MY; Tue, 16 Mar 2004 16:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Lp4-0003Bl-PS for ipv6@optimus.ietf.org; Tue, 16 Mar 2004 16:10:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24726 for ; Tue, 16 Mar 2004 16:09:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Lp3-0000yy-00 for ipv6@ietf.org; Tue, 16 Mar 2004 16:10:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Lo9-0000ub-00 for ipv6@ietf.org; Tue, 16 Mar 2004 16:09:05 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1B3Lnn-0000pQ-00 for ipv6@ietf.org; Tue, 16 Mar 2004 16:08:44 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2GL8hwr019390 for ; Tue, 16 Mar 2004 14:08:43 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUO00GANTEI6P@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Tue, 16 Mar 2004 14:08:43 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUO00COCTEHE1@mail.sun.net> for ipv6@ietf.org; Tue, 16 Mar 2004 14:08:42 -0700 (MST) Date: Tue, 16 Mar 2004 13:08:41 -0800 From: Alain Durand Subject: Re: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt In-reply-to: <20040316132609.GA3439@fysh.org> To: Zefram Cc: Margaret Wasserman , IPv6 Mailing List Message-id: <1A11E62A-778E-11D8-9F71-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4055648E.AA0E0D09@zurich.ibm.com> <006201c40a6c$baf59960$6401a8c0@ssprunk> <9C0F03A6-76AB-11D8-9F71-00039376A6AA@sun.com> <20040316132609.GA3439@fysh.org> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Mar 16, 2004, at 5:26 AM, Zefram wrote: > Alain Durand wrote: >> I too would like to see the reverse tree DNS being delegated. However, >> as there is no >> structure, the entire /8 to /48 address space would have to be within >> one single zone... > > There is structure within the domain name segment between /8 and /48 > -- it's a sequence of ten DNS labels, not just one. Zone cuts can be > introduced at any level to split the job up. If you cut at /8, the zone is too big. if you cut at /48, there are too many zones. Where do you cut? - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 16 18:13:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03978 for ; Tue, 16 Mar 2004 18:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Nk0-0008Ax-Ek for ipv6-archive@odin.ietf.org; Tue, 16 Mar 2004 18:12:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GNCuFo031419 for ipv6-archive@odin.ietf.org; Tue, 16 Mar 2004 18:12:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Nk0-0008AY-8U for ipv6-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 18:12:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03861 for ; Tue, 16 Mar 2004 18:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Njx-0001Mo-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 18:12:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Nig-0001At-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 18:11:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3Nho-00011B-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 18:10:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3Nhm-0001yp-Jq for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 18:10:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NhE-00075x-BR; Tue, 16 Mar 2004 18:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3NgJ-0006sS-5q for ipv6@optimus.ietf.org; Tue, 16 Mar 2004 18:09:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03385 for ; Tue, 16 Mar 2004 18:09:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3NgG-0000sZ-00 for ipv6@ietf.org; Tue, 16 Mar 2004 18:09:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3NfZ-0000nM-00 for ipv6@ietf.org; Tue, 16 Mar 2004 18:08:22 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1B3Nek-0000gs-00 for ipv6@ietf.org; Tue, 16 Mar 2004 18:07:30 -0500 Received: from ssprunk (ip144.post-vineyard.dfw.ygnition.net [66.135.181.144]) by ns2.sea (8.12.11/8.12.5) with SMTP id i2GN6sCW026594; Tue, 16 Mar 2004 15:06:54 -0800 Message-ID: <049b01c40bab$60a389a0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Alain Durand" , "Zefram" Cc: "Margaret Wasserman" , "IPv6 Mailing List" References: <4055648E.AA0E0D09@zurich.ibm.com> <006201c40a6c$baf59960$6401a8c0@ssprunk> <9C0F03A6-76AB-11D8-9F71-00039376A6AA@sun.com> <20040316132609.GA3439@fysh.org> <1A11E62A-778E-11D8-9F71-00039376A6AA@sun.com> Subject: Re: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt Date: Tue, 16 Mar 2004 17:05:31 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Alain Durand" > On Mar 16, 2004, at 5:26 AM, Zefram wrote: > > Alain Durand wrote: > >> I too would like to see the reverse tree DNS being delegated > >> However, as there is no structure, the entire /8 to /48 address > >> space would have to be within one single zone... > > > > There is structure within the domain name segment between /8 and /48 > > -- it's a sequence of ten DNS labels, not just one. Zone cuts can be > > introduced at any level to split the job up. > > If you cut at /8, the zone is too big. if you cut at /48, there are too > many zones. > Where do you cut? If you need AXFR and standard BIND code, then /8 /18 /28 and /38 zones are logical; just create the necessary cascading zones (if any) when new assignments are made. Yes, this creates tons of sparsely populated zones, but that's a weak point of BIND (and probably not envisioned by DNS' designers way back when). However, since there's no structure to these assignments, it seems more logical to hack up BIND or some other server to handle the unusually sparse namespace in a more appropriate manner. Presumably these servers would synchronize via means other than AXFR. 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 exim@www1.ietf.org Wed Mar 17 03:35:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25416 for ; Wed, 17 Mar 2004 03:35:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WVM-0006bD-Op for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 03:34:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H8YO0Z025362 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 03:34:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WVK-0006ah-9p for ipv6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 03:34:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25407 for ; Wed, 17 Mar 2004 03:34:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3WVI-0001am-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:34:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3WUQ-0001Ue-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:33:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3WU0-0001O7-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WS8-0006B4-0F; Wed, 17 Mar 2004 03:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WRL-0005zO-2m for ipv6@optimus.ietf.org; Wed, 17 Mar 2004 03:30:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25190 for ; Wed, 17 Mar 2004 03:30:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3WRI-00013p-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:30:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3WQL-0000wz-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:29:14 -0500 Received: from postfix.informatik.uni-bonn.de ([131.220.8.4]) by ietf-mx with esmtp (Exim 4.12) id 1B3WPQ-0000mO-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:28:16 -0500 X-IAI-Env-From: : [131.220.4.211] Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by postfix.informatik.uni-bonn.de (Postfix) with ESMTP id 88BFD5C85D; Wed, 17 Mar 2004 09:27:46 +0100 (MET) (envelope-from ignatios@newton.cs.uni-bonn.de) (envelope-to VARIOUS) (2) (internal use: ta=0, tu=1, te=0, am=-, au=-) Received: from newton.cs.uni-bonn.de (newton.cs.uni-bonn.de [131.220.4.212]) by theory.cs.uni-bonn.de (8.12.9/8.12.9) with SMTP id i2H8Rk8s028819; Wed, 17 Mar 2004 09:27:46 +0100 (MET) Received: (from ignatios@newton.cs.uni-bonn.de) by newton.cs.uni-bonn.de (mini_sendmail/1.3.2 21nov2002 nb4 7oct2003); Wed, 17 Mar 2004 09:27:46 CET (sender ignatios@newton.cs.uni-bonn.de) Date: Wed, 17 Mar 2004 09:27:46 +0100 From: Ignatios Souvatzis To: ipv6@ietf.org Cc: Fred Templin Subject: Re: Unique local & DNS (was: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt+ Message-ID: <20040317082746.GA15459@cs.uni-bonn.de> Reply-To: ipv6@ietf.org References: <20040315151941.210.qmail@web80513.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <20040315151941.210.qmail@web80513.mail.yahoo.com> User-Agent: Mutt/1.4.1i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Fred, > Also, what about other non-DNS naming services that can be deployed > within a site/organization? E.g., the Sun Yellow Pages (I guess it's call= ed > NIS now?) We don't confess it in public, and we block all RPC requests at our border routers, but some of us do. > and the naming service developed by Project Athena at MIT > back in the 1980's (not sure on the name of this one, but "Hessiod" rings > a bell) I'm not from Athens, but AFAIK,=20 HESIOD uses DNS ... it packs more information than host information into DN= S. > still widely used by site administrators? (Feeling a bit like Rip Van > Winkle waking up from a 15-yr slumber wrt this technology space...) hehe. -is --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBQFgL/TCn4om+4LhpAQHgTgf/R84ZxwcR7yHRNNk2YbAniAIZdD3NeXVQ Prc4Na8MTCYNUeceZdS4XbwB8nW1rIvYRJKVEFpVnmcHUopnZDpKEpF/uAMuha6p +n9Pese6fB/Xpo/toLd95IYFhTU/rNSa7OilHaQvGe5oA7rl2JCRHNMz2LhqZxCE xplcm1u4fpMKYKu4cMKKvtmptdSwMMz7/dT7e2gmV2DgBO03ptaira4m79yCU4O/ K6UqwwpXDPtH5TsU/FpxJ6FhNA0+XM/EToSc7/TkX33JeSx4Zgo3XwUe2gCDOU5d ZlUA41SCaV42edtun/ShUMn8TzwFsMLmPnL2EJcnnyT4+ie7QAGbjQ== =rdIS -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 17 03:44:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25820 for ; Wed, 17 Mar 2004 03:44:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WeU-00088R-L2 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 03:44:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H8hepj031255 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 03:43:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WeI-000878-Jz for ipv6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 03:43:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25773 for ; Wed, 17 Mar 2004 03:43:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3We1-0002cd-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:43:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3WdB-0002Vv-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:42:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3WcG-0002PS-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:41:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Wbp-0007Zm-L4; Wed, 17 Mar 2004 03:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Wb3-0007Rx-Pg for ipv6@optimus.ietf.org; Wed, 17 Mar 2004 03:40:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25645 for ; Wed, 17 Mar 2004 03:40:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Wb0-0002GH-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:40:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Wa2-0002A8-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:39:15 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B3WZA-0001zB-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:38:20 -0500 content-class: urn:content-classes:message Subject: RE: Multiple DRs on a link Date: Wed, 17 Mar 2004 03:37:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Multiple DRs on a link Thread-Index: AcQL+mkjDFOUdM3bRvC2mwMiI5TrrQAANHuQ From: "Soliman Hesham" To: "Pascal Thubert (pthubert)" , "Jari Arkko" Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > =3D> There are many different reasons. I sent a verly long > > email about this to nemo (monet back then). One simple > > scenario is that you might be walking around with a PAN > > that happens to have 2 MRs on a single link (e.g. a laptop > > and a mobile phone). The two MRs could share the same ingress > > link and have different egress links. For instance your laptop > > might have a WLAN card and your mobile might have a cellular > > interface. Once you walk into an airport lounge or starbucks > > you'll suddenly have a multihomed PAN. By definition, each MR > > must have a separate home prefix. So each will advertise > > a different prefix on the ingress side. >=20 > Hi Hesham: >=20 > I fail to understand the "by definition" here. Nemo does not=20 > prevent 2 > different MRs from registering the same MNP. It's like=20 > multiple parallel > routes. What's not duplicated is the Home address... In=20 > fact, I proposed > a test to check that both registrations actually end up in a=20 > same link, > otherwise there's a problem equivalent to the DAD problem in=20 > MIP6. Not > much success on that proposal, though =3D> Hmm, that's interesting. I must have missed that in the spec. So, my concern is similar to yours, how does the HA check whether the MRs are in the same place?? Seems like a dangerous feature to have. I'm surprised this wasn't discussed during LC. Hesham=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 17 07:50:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04054 for ; Wed, 17 Mar 2004 07:50:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aV5-00075n-UU for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 07:50:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HCoNBM027262 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 07:50:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aV5-00075d-O0 for ipv6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 07:50:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04005 for ; Wed, 17 Mar 2004 07:50:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aV5-0007No-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 07:50:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aU7-0007FT-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 07:49:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3aTC-00077C-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 07:48:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aQs-0006d8-17; Wed, 17 Mar 2004 07:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aQO-0006cC-3e for ipv6@optimus.ietf.org; Wed, 17 Mar 2004 07:45:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03758 for ; Wed, 17 Mar 2004 07:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aQN-0006lX-00 for ipv6@ietf.org; Wed, 17 Mar 2004 07:45:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aPQ-0006fF-00 for ipv6@ietf.org; Wed, 17 Mar 2004 07:44:33 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3aP6-0006Yp-00; Wed, 17 Mar 2004 07:44:13 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2004 04:48:32 +0000 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2HCh7iZ001361; Wed, 17 Mar 2004 13:43:08 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Mar 2004 12:43:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FW: Multiple DRs on a link Date: Wed, 17 Mar 2004 12:43:37 -0000 Message-ID: Thread-Topic: [nemo] FW: Multiple DRs on a link Thread-Index: AcQL+mkjDFOUdM3bRvC2mwMiI5TrrQAANHuQAAgt2pAAADCxUA== From: "Pascal Thubert \(pthubert\)" To: "IETF NEMO WG" Cc: , X-OriginalArrivalTime: 17 Mar 2004 12:43:37.0780 (UTC) FILETIME=[77DD6740:01C40C1D] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > -----Original Message----- > From: Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: mercredi 17 mars 2004 09:38 > To: Pascal Thubert (pthubert); Jari Arkko > Cc: ipv6@ietf.org > Subject: RE: Multiple DRs on a link > > > > =3D> There are many different reasons. I sent a verly long > > email about this to nemo (monet back then). One simple > > scenario is that you might be walking around with a PAN > > that happens to have 2 MRs on a single link (e.g. a laptop > > and a mobile phone). The two MRs could share the same ingress > > link and have different egress links. For instance your laptop > > might have a WLAN card and your mobile might have a cellular > > interface. Once you walk into an airport lounge or starbucks > > you'll suddenly have a multihomed PAN. By definition, each MR > > must have a separate home prefix. So each will advertise > > a different prefix on the ingress side. > > > > Hi Hesham: > > > > I fail to understand the "by definition" here. Nemo does not > > prevent 2 > > different MRs from registering the same MNP. It's like > > multiple parallel > > routes. What's not duplicated is the Home address... In > > fact, I proposed > > a test to check that both registrations actually end up in a > > same link, > > otherwise there's a problem equivalent to the DAD problem in > > MIP6. Not > > much success on that proposal, though > > =3D> Hmm, that's interesting. I must have missed that in the > spec. So, my concern is similar to yours, how does the HA > check whether the MRs are in the same place?? Seems like > a dangerous feature to have. I'm surprised this wasn't discussed > during LC. > Well, Nemo requires that some authorization be run, that's not described in the spec. Such a test could take place there, or the authorization could bar a second registration for a same prefix, I guess. Pascal -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 17 11:46:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19680 for ; Wed, 17 Mar 2004 11:46:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3eAC-0004dm-AN for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 11:45:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HGiqFf017754 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 11:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3e9x-0004bH-5U for ipv6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 11:44:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19057 for ; Wed, 17 Mar 2004 11:44:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3e9h-0001H2-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 11:44:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3e6x-0000XO-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 11:41:45 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3e4e-0007aQ-01 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 11:39:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3dvf-0003KB-En for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 11:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dtu-00037f-7p; Wed, 17 Mar 2004 11:28:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dtG-00035q-2y for ipv6@optimus.ietf.org; Wed, 17 Mar 2004 11:27:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17085 for ; Wed, 17 Mar 2004 11:27:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3dtF-0005M2-00 for ipv6@ietf.org; Wed, 17 Mar 2004 11:27:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3dsK-0005FO-00 for ipv6@ietf.org; Wed, 17 Mar 2004 11:26:36 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1B3drx-000598-00 for ipv6@ietf.org; Wed, 17 Mar 2004 11:26:14 -0500 Received: from ssprunk (ip144.post-vineyard.dfw.ygnition.net [66.135.181.144]) by ns2.sea (8.12.11/8.12.5) with SMTP id i2HGPcrG031431 for ; Wed, 17 Mar 2004 08:25:42 -0800 Message-ID: <009e01c40c3c$7e956eb0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "IETF IPv6 WG" Subject: ASN-based prefixes for leaf ASes Date: Wed, 17 Mar 2004 10:21:12 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm starting here with the posit that the global routing table will contain at least one prefix (/48 or shorter in the case of IPv6) from each ASN. Obviously if this doesn't hold, the following discussion isn't valid... Leaf ASes in the IPv6 world are expected to get a /48 prefix allocation (from an RIR) as they do in the IPv4 world. Given the size of a /48, it's reasonable to expect the vast majority of these ASes will only need a single prefix for IPv6, whereas in IPv4 they might have hundreds. Since these ASes already have an ASN and only need a single prefix, it seems logical to assign a prefix to each AS based on their ASN. This would reduce pressure on the "normal" prefix allocation process used by non-leaf ASes. In fact, a "normal" prefix need only be allocated to a leaf AS when they demonstrate that their ASN-based prefix has been fully utilized or bona fide technical reasons why the AS cannot use a single prefix. A non-leaf AS may (?) use ASN-based addresses for their internal use, but must not assign any such addresses to customers. To reduce advertisements, non-leaf ASes may choose not to use their ASN-based prefix and instead give themselves an internal allocation from one of their "normal" prefixes. Given the number of 16-bit ASNs currently assigned, it seems reasonable to assume an extension to 32-bit ASNs will occur within the lifetime of IPv6. Thus, a single /16 prefix for all ASN-based allocations would be required. The largest problem I see with this is that ASNs are permanently assigned, or at least so far no recovery process is defined and no rent is charged. This means that ASN-based allocations would be similarly permanent. This might be good or bad depending on your view of the RIRs. Thoughts? 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 exim@www1.ietf.org Wed Mar 17 11:46:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19808 for ; Wed, 17 Mar 2004 11:46:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3eAB-0004df-VQ for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 11:45:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HGiqXU017747 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 11:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3e9w-0004bD-Da for ipv6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 11:44:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19051 for ; Wed, 17 Mar 2004 11:44:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3e9g-0001GV-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 11:44:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3e6w-0000Wv-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 11:41:43 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3e4e-0007YW-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 11:39:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3dvb-0003K9-B6 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 11:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dtk-00037L-Py; Wed, 17 Mar 2004 11:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dtF-00035l-HX for ipv6@optimus.ietf.org; Wed, 17 Mar 2004 11:27:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17082 for ; Wed, 17 Mar 2004 11:27:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3dtE-0005Lx-00 for ipv6@ietf.org; Wed, 17 Mar 2004 11:27:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3dsJ-0005FG-00 for ipv6@ietf.org; Wed, 17 Mar 2004 11:26:36 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1B3drv-00058q-00 for ipv6@ietf.org; Wed, 17 Mar 2004 11:26:11 -0500 Received: from ssprunk (ip144.post-vineyard.dfw.ygnition.net [66.135.181.144]) by ns2.sea (8.12.11/8.12.5) with SMTP id i2HGPcrE031431; Wed, 17 Mar 2004 08:25:39 -0800 Message-ID: <009d01c40c3c$7cef86e0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Christian Huitema" , "Margaret Wasserman" , References: Subject: Re: Unique local & DNS (was: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt+ Date: Wed, 17 Mar 2004 09:59:34 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Christian Huitema" > In her review of "draft-ietf-ipv6-unique-local-addr-03.txt", Margaret > raises an excellent point: > > > (1) This draft doesn't mention the reverse DNS tree. Is it expected > > that whatever registry assigns these values will also populate the > > reverse DNS tree? Or not? > > The registration process could conceivably populate the reverse DNS > tree, but that would only be a partial solution: the draft also defines > random prefixes that don't need to be registered. Also, there is no > requirement that the networks numbered with these unique local addresses > be accessible to DNS resolvers on the Internet. At a minimum, being present in the global DNS should be at the option of the allocatee. Until a viable solution is found for non-registered prefixes, this might be given as an advantage of using a registered prefix. While I don't think it's particularly elegant, it might work to designate a "well known" anycast DNS server address within each local prefix. This wouldn't require any registration in the global DNS for any type of local prefix. > We may however want some kind of "theory of operation". When a network > is numbered using unique local addresses, hosts in that network will > want to resolve addresses to names. There are 2 possible solutions: > > 1) Add specific knowledge of this reverse tree to the DNS servers in the > unique-local-addressed site, While this should be sufficient for isolated sites, this doesn't scale when multiple sites interconnect (privately) using local addresses. Presence in the global DNS (if desired) or a well-known anycast removes the need for special local configuration. > 2) Perform reverse name resolution by asking the host itself, sending > either a host information query or an LLMNR PTR request to the IPv6 > address being resolved. I don't know anything about LLMNR and so can't comment if this is workable. 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 exim@www1.ietf.org Wed Mar 17 12:22:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23320 for ; Wed, 17 Mar 2004 12:22:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ejJ-0000Ag-33 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 12:21:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HHL2ZK000590 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 12:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3eiq-00008e-JN for ipv6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 12:20:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23213 for ; Wed, 17 Mar 2004 12:20:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3eia-00004Q-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 12:20:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ehd-0007hg-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 12:19:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3egg-0007Xd-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 12:18:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3eg7-00085q-P6; Wed, 17 Mar 2004 12:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3eg0-00083E-Rs for ipv6@optimus.ietf.org; Wed, 17 Mar 2004 12:17:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23015 for ; Wed, 17 Mar 2004 12:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3efz-0007PG-00 for ipv6@ietf.org; Wed, 17 Mar 2004 12:17:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3eew-0007HP-00 for ipv6@ietf.org; Wed, 17 Mar 2004 12:16:51 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3ee8-00072w-00 for ipv6@ietf.org; Wed, 17 Mar 2004 12:16:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2HHFFm13405; Wed, 17 Mar 2004 19:15:15 +0200 Date: Wed, 17 Mar 2004 19:15:15 +0200 (EET) From: Pekka Savola To: Stephen Sprunk cc: IETF IPv6 WG Subject: Re: ASN-based prefixes for leaf ASes In-Reply-To: <009e01c40c3c$7e956eb0$6401a8c0@ssprunk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 17 Mar 2004, Stephen Sprunk wrote: > Thoughts? Been there, done that, gotten flamed about it :-). draft-savola-multi6-asn-pi-01.txt (Well, I don't like that proposition either..) p.s. the correct forum may be multi6. -- 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 exim@www1.ietf.org Wed Mar 17 15:38:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05715 for ; Wed, 17 Mar 2004 15:38:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hnK-0000bE-Ny for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 15:37:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HKbgRR002301 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 15:37:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hnK-0000ax-5u for ipv6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 15:37:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05676 for ; Wed, 17 Mar 2004 15:37:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hnI-0004z9-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 15:37:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hmL-0004ri-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 15:36:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3hlO-0004kZ-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 15:35:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hkl-00009x-Ti; Wed, 17 Mar 2004 15:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hkY-00008D-VQ for ipv6@optimus.ietf.org; Wed, 17 Mar 2004 15:34:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05547 for ; Wed, 17 Mar 2004 15:34:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hkS-0004dV-00 for ipv6@ietf.org; Wed, 17 Mar 2004 15:34:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hje-0004Wp-00 for ipv6@ietf.org; Wed, 17 Mar 2004 15:33:55 -0500 Received: from farside.isc.org ([204.152.187.5]) by ietf-mx with esmtp (Exim 4.12) id 1B3hiw-0004Ln-00 for ipv6@ietf.org; Wed, 17 Mar 2004 15:33:10 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id BBB76A83E for ; Wed, 17 Mar 2004 20:32:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i2HKWWqW031648; Thu, 18 Mar 2004 07:32:32 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200403172032.i2HKWWqW031648@drugs.dv.isc.org> To: "Stephen Sprunk" Cc: "Christian Huitema" , "Margaret Wasserman" , ipv6@ietf.org From: Mark Andrews Subject: Re: Unique local & DNS (was: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt+ In-reply-to: Your message of "Wed, 17 Mar 2004 09:59:34 MDT." <009d01c40c3c$7cef86e0$6401a8c0@ssprunk> Date: Thu, 18 Mar 2004 07:32:32 +1100 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > Thus spake "Christian Huitema" > > In her review of "draft-ietf-ipv6-unique-local-addr-03.txt", Margaret > > raises an excellent point: > > > > > (1) This draft doesn't mention the reverse DNS tree. Is it expected > > > that whatever registry assigns these values will also populate the > > > reverse DNS tree? Or not? > > > > The registration process could conceivably populate the reverse DNS > > tree, but that would only be a partial solution: the draft also defines > > random prefixes that don't need to be registered. Also, there is no > > requirement that the networks numbered with these unique local addresses > > be accessible to DNS resolvers on the Internet. > > At a minimum, being present in the global DNS should be at the option of the > allocatee. Until a viable solution is found for non-registered prefixes, > this might be given as an advantage of using a registered prefix. Well non-registered addresses are not guarenteed to be unique. We should be recommending that *every* recursive nameserver, not just where locals addresses are in use, be configured with a empty zone (SOA and NS only) for the /8. This will prevent the root and ip6.arpa servers having to deal with all the requests that would otherwise come to them. If a non-unique local addresses are in use it can have delegations in this zone. > While I don't think it's particularly elegant, it might work to designate a > "well known" anycast DNS server address within each local prefix. This > wouldn't require any registration in the global DNS for any type of local > prefix. > > > We may however want some kind of "theory of operation". When a network > > is numbered using unique local addresses, hosts in that network will > > want to resolve addresses to names. There are 2 possible solutions: > > > > 1) Add specific knowledge of this reverse tree to the DNS servers in the > > unique-local-addressed site, > > While this should be sufficient for isolated sites, this doesn't scale when > multiple sites interconnect (privately) using local addresses. Presence in > the global DNS (if desired) or a well-known anycast removes the need for > special local configuration. > > > 2) Perform reverse name resolution by asking the host itself, sending > > either a host information query or an LLMNR PTR request to the IPv6 > > address being resolved. > > I don't know anything about LLMNR and so can't comment if this is workable. > > 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 > -------------------------------------------------------------------- -- 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 exim@www1.ietf.org Wed Mar 17 17:27:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12359 for ; Wed, 17 Mar 2004 17:27:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3jV6-0002a3-Rh for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 17:27:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HMR0EG009913 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 17:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3jV6-0002Zo-F6 for ipv6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 17:27:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12352 for ; Wed, 17 Mar 2004 17:26:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3jV4-00065T-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 17:26:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3jU3-0005xj-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 17:25:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3jTZ-0005qH-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 17:25:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3jTB-0002EE-Qn; Wed, 17 Mar 2004 17:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3jT1-0002Df-Ai for ipv6@optimus.ietf.org; Wed, 17 Mar 2004 17:24:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12273 for ; Wed, 17 Mar 2004 17:24:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3jSz-0005pN-00 for ipv6@ietf.org; Wed, 17 Mar 2004 17:24:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3jS7-0005iq-00 for ipv6@ietf.org; Wed, 17 Mar 2004 17:23:55 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1B3jRI-0005Uf-00 for ipv6@ietf.org; Wed, 17 Mar 2004 17:23:04 -0500 Received: from ssprunk (ip144.post-vineyard.dfw.ygnition.net [66.135.181.144]) by ns2.sea (8.12.11/8.12.5) with SMTP id i2HMMWGD001283; Wed, 17 Mar 2004 14:22:33 -0800 Message-ID: <003d01c40c6e$58357210$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Mark Andrews" Cc: "Christian Huitema" , "Margaret Wasserman" , References: <200403172032.i2HKWWqW031648@drugs.dv.isc.org> Subject: Re: Unique local & DNS (was: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt+ Date: Wed, 17 Mar 2004 16:19:09 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Mark Andrews" > > At a minimum, being present in the global DNS should be at the option > > of the allocatee. Until a viable solution is found for non-registered > > prefixes, this might be given as an advantage of using a registered prefix. > > Well non-registered addresses are not guarenteed to be unique. "Until" should probably be "unless". > We should be recommending that *every* recursive nameserver, not > just where locals addresses are in use, be configured with a empty zone > (SOA and NS only) for the /8. This will prevent the root and ip6.arpa > servers having to deal with all the requests that would otherwise come to > them. While undoubtedly ideal, I don't trust a million local DNS admins around the world to all get this right. For example, this should be done for RFC1918 addresses as well, yet the volume of bogus reverse queries hitting the roots was still substantial enough IANA resorted to lamely delegating the zones. It'll probably end up happening to FD00::/8 as well. > If a non-unique local addresses are in use it can have delegations > in this zone. Of course. 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 exim@www1.ietf.org Thu Mar 18 03:56:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27988 for ; Thu, 18 Mar 2004 03:56:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tK2-0004Eh-K5 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 03:56:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I8uEIv016283 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 03:56:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tK1-0004EX-Vd for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 03:56:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27935 for ; Thu, 18 Mar 2004 03:56:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3tJz-0001Gm-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 03:56:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3tJ1-00017s-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 03:55:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3tI4-0000zG-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 03:54:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tGw-0003nU-O4; Thu, 18 Mar 2004 03:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3tGH-0003jL-7C for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 03:52:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27792 for ; Thu, 18 Mar 2004 03:52:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3tGE-0000ko-00 for ipv6@ietf.org; Thu, 18 Mar 2004 03:52:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3tFH-0000df-00 for ipv6@ietf.org; Thu, 18 Mar 2004 03:51:20 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3tEr-0000VS-00 for ipv6@ietf.org; Thu, 18 Mar 2004 03:50:54 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2I8oLY27064; Thu, 18 Mar 2004 10:50:21 +0200 Date: Thu, 18 Mar 2004 10:50:21 +0200 (EET) From: Pekka Savola To: ipv6@ietf.org cc: skylane@etri.re.kr, Subject: simpler prefix delegation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, This started from me looking at draft-bykim-ipv6-hpd-01.txt, what it was before that, DHCPv6 + PD, a few proposals at v6ops for integrated prefix delegation, etc.. -- I couldn't help thinking, "there must be an easier way to delegate an IPv6 prefix in the simplest setups (e.g., when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way too heavy-weight". This is where I got. Thoughts appreciated. Problems with the spec (draft-bykim-ipv6-hpd-01.txt) ---------------------- I think this is a useful continuation of Brian/Jim's Automatic Prefix Delegation work. All the problems in the world are not necessarily solved by DHCPv6... so I think developing an extremely simple PD protocol could be very useful. The applicability area I see for this are the cases where DHCPv6 is not being used, especially when the ISP wants to offer IPv6 support very simply, using a tunnel. However, this document goes into a bit too complex direction. There are multiple problems with the approach as-is: - Why use PrefixCnt, and not PrefixLen when sending the Delegator Query? The most important thing is the length of the desired prefix, not the number of them, after all. The whole PrefixCnt thing seems fishy to me, all in all -- the same information can be obtained by using an appropriate PrefixLen! - Similarly, PrefixDiff doesn't seem to be all that useful. - CGA security does not work unless you use Signature options from SEND as well, so that can be scrapped. - 2 roundtrips are needed, with 4 different messages to get a prefix: a bit too many for my taste. - The draft makes confusion about "built-in routing". That sort of thing is integrated with prefix delegation in any case: you can't have it without -- as static routes are set in any case. This seems unnecessary to mention here. - The scope is not clear; why would one need hierarchical prefix delegation where one would not use routing? That is, if one gets a /64, it cannot be delegated (in a meaningful way) forward. If one gets a /48 (e.g., on a home network), why would one need to delegate it forward -- are there routers there, requesting smaller prefixes -- I hope not! And in an Enterprise, you want to set this up manually in any case. So the whole hierarchical part appears to be really fishy, and should be removed unless clear justification is found. So -- I think think the spec has suffered from a serious feature creep, with little regard to the actual user needs. But, I'd still propose to go forward with this (or another document, started from scratch), in an entirely different format and design tradeoffs, as described below. I could write it, but I would prefer if someone else wanted to work on this (too many things in progress at the moment.) Current model is basically like: -------------------------------- 1. Delegator Query, looking up the delegators and signalling the number of prefixes solicited (no prefix length?). 2. Response w/ nmber of prefixes and prefix len difference (how?) 3. Prefix Request to request prefixes (not telling which) 4. Response w/ prefix delegated Return: prefix returned message -- replied with prefix returned. Renewal: renewal message. As you see, there are a lot of different messages, with different subcodes: really difficult to understand.. Proposal -------- Instead, use Neighbor Discovery messages rather than directly putting them on top of ICMPv6. This gives the benefit of being able to use all the functions of SEND without any specification, as SEND only protects neighbor discovery messages (and all of them, if you just plug in the signatures etc!). [[ the features in double brackets are ones that could be easily added, but IMHO I'm not sure whether that is worth the effort. ]] Now, the messages could be like: Prefix Solicitation: sent to "all-prefix-delegators" link-local multicast address or a unicast address (learned using means outside the scope of this memo; but link local) * addresses checked to be link-local, TTL=255. (same for all the messages.) * Includes PrefixLen field, indicating the preference for the prefix length * Includes a "Test" flag: if given, the routers does not actually delegate the prefix, only show which prefix they would have given. (This can be used to pick among the routers, as well as learn which kind of prefixes/lengths they would be giving. But the point is that if there are multiple routers which are willing to give you a prefix, why not get prefix from each unless explicitly desiring otherwise?) * Includes a "No Refresh" flag: if given, do not refresh the existing prefixes, but allocate new ones; the old ones continue to be used. If not given, refresh the old prefixes (if delegated) or allocate new ones (if no existing delegation). * [[ no PrefixCnt field, as this seems unnecessary -- just use PrefixLen or ask again -- but could be plugged in later if deemed necessary ]] * [[ no authentication/user identification options; authentication is assumed to be obtained on the link layer. However, it is possible to include Authentication type and length fields (1 octet each) which can be used to piggyback different kinds of authentication information, later on if needed. Authentication could also be done with SEND. ]] * [[ one could have "reverse DNS delegation requested" flag here as well, with an option which could encode DNS server address(es), but I don't think that's really important for mainstream use.]] Prefix Delegation: sent to the unicast link-local address of solicitor * includes Test flag, to indicate whether delegation was really done * [[ could also have reverse DNS delegated flag, as described above, but IMHO doesn't seem to be really important for now.]] * includes the prefix(es) delegated to the user. [[ each prefix could have a lifetime as well; lifetime of zero means "not specified" -- no refreshing is needed as long as NUD works. If lifetime not specified, the lifetime of RAs on downstream interfaces SHOULD NOT be greater than 7200 seconds. ]] [[ Prefix Maintenance: miscellaneous messages * code 0: return the prefix; used by the solicitor to give back a prefix, either when ceasing to use it or when refusing the prefix delegation. ]] -- could be used for serious DoS unless authenticated. The solicititor SHOULD run NUD on the interface. If NUD fails to the routers which have delegated prefix(es), MAY send a Prefix Solicitation message with "No Refresh" not set (to know whether the delegation exists; if it doesn't, to get a new one). If some other indication has been received that the interface has went up/down, may similarly re-initiate the procedure. Would this seem to make sense? This also fulfills the prefix delegation requirements draft's requirements pretty well AFAICS. -- 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 exim@www1.ietf.org Thu Mar 18 06:47:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04530 for ; Thu, 18 Mar 2004 06:47:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vzZ-0005Th-Mi for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 06:47:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IBlH65021048 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 06:47:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vzZ-0005TO-Dx for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 06:47:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04498 for ; Thu, 18 Mar 2004 06:47:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vzV-0006Yl-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 06:47:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vyX-0006QG-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 06:46:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3vxX-0006De-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 06:45:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vwP-00052q-OX; Thu, 18 Mar 2004 06:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3vvh-00051V-MB for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 06:43:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04304 for ; Thu, 18 Mar 2004 06:43:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vvd-00060u-00 for ipv6@ietf.org; Thu, 18 Mar 2004 06:43:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3vuf-0005tV-00 for ipv6@ietf.org; Thu, 18 Mar 2004 06:42:13 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3vtg-0005gd-00 for ipv6@ietf.org; Thu, 18 Mar 2004 06:41:12 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2IBeTq29718; Thu, 18 Mar 2004 13:40:29 +0200 Date: Thu, 18 Mar 2004 13:40:29 +0200 (EET) From: Pekka Savola To: Shin Miyakawa cc: ipv6@ietf.org, , Subject: Re: simpler prefix delegation In-Reply-To: <20040318.184737.71091593.miyakawa@nttv6.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 18 Mar 2004, Shin Miyakawa wrote: > > when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way > > too heavy-weight". > > "way too Heavy Weight" is not well-defined. > Please explain a bit more how you decide this. Pekka ? > > When we dicuss about measurement, we should be mathematical. > Otherwise it sounds just a feeling or myth which > leads us to just a superstition. > > In this case, the information carried by the protocol > - either DHCP format or whatever - is essentially the same; > just a prefix information which is about 128bits + prefix length. > Therefore the volume of the bits are also not so different in either case. There are many kinds of complexity / "heavy-weight": - specification complexity (how long the specs are, how difficul to understand, etc.) -- DHCPv6 + PD: ~120 pages. - implementation complexity (how many lines of code, any particularly difficult issues, etc.) -- DHCPv6: dozens? of thousands - requirements from the system (how does the mechanism interface with the routers, access databases, etc. -- e.g., do you need to have v6 support in RADIUS databases, do you need to have customer information stored there, how is that communicated to the router or the DHCPv6 server): It appears as if DHCPv6 has non-trivial set-up complexity. - the overhead in the messages (added bytes in all or some of the packets): not much, unless you run PPP like described e.g. in draft-shirasaki-dualstack-service-03.txt - the number of messages (how many packets (and how big) needed: DHCPv6 request at least two roundtrips (4 messages), if PPP is used, even more. It should be obvious that there is a significant difference here. The critical questions, of course are: - is the difference significant enough (in any specific scenario) - if yes, does it make sense to have another solution for some specific scenarios (whether commonplace or not) > When I started the work of prefix delegation several years ago, > Steve Deering told me that ICMP and RA are very fundamental so we > should keep those as simple as possible. Well, I think we're discussing a very fundamental issue; it's IMHO much more non-sensical to invent new protocols just because we can. > Lastly, Let us recall very important fact which is that we should > not have many options or protocols for the same purpose. These IMHO serve slightly different purposes. DHCPv6 provides you with a complex solution that works every time (well, on public LANs setting up the key management is a mess); this proposal is aimed at the simpler setups where the complexity is unnecessary and redundant. In such scenarios, DHCPv6 is more likely than not even used (e.g., with IPv6-over-IPv4 configured tunnels) -- and should not be required (IMHO, of course). Let me ask another question: would you rather have proxy-ND for /64 prefixes or a simple (non-DHCPv6) prefix delegation for /48's? -- 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 exim@www1.ietf.org Thu Mar 18 07:00:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05041 for ; Thu, 18 Mar 2004 07:00:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3wCJ-00068z-GC for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 07:00:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IC0RnK023610 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 07:00:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3wCJ-00068j-Ad for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 07:00:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05000 for ; Thu, 18 Mar 2004 07:00:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3wCF-0000KL-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 07:00:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3wBI-0000Cp-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 06:59:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3wAj-00005h-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 06:58:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3w9x-0005m3-LS; Thu, 18 Mar 2004 06:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3w9F-0005kM-Vp for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 06:57:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04886 for ; Thu, 18 Mar 2004 06:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3w9B-0007mb-00 for ipv6@ietf.org; Thu, 18 Mar 2004 06:57:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3w8F-0007ga-00 for ipv6@ietf.org; Thu, 18 Mar 2004 06:56:15 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3w7M-0007U7-00 for ipv6@ietf.org; Thu, 18 Mar 2004 06:55:20 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2IBsnM29865; Thu, 18 Mar 2004 13:54:49 +0200 Date: Thu, 18 Mar 2004 13:54:49 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: ipv6@ietf.org Subject: ND-proxy applicability and loop-prevention In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, We've discussed ND-proxy applicability in home networks for "informal prefix sharing" (see draft-ietf-v6ops-unmaneval-01.txt). I thought it might be good idea to try to move some of the discussion on IPv6 WG list where ND-proxy is being specified. Below... On Tue, 16 Mar 2004, Erik Nordmark wrote: [Erik quoting me:] > > Another angle here is how are you going to deal with the case where > > you have to have stacked gateways. E.g., the home gateway is doing > > prefix delegation, and advertising /64's on its links. One of the > > nodes at home is also a router, and behind it is a host. How do you > > get v6 to that host behind the node? That's a very common scenario > > today. I think it in most cases you could probably move that node to > > the same link, but in some cases (e.g., mismatching media) it might > > not be possible. > [...] > The solution you want in this space is something which allows plug&play of > the devices that glue together the stacking. And since you don't know how > the customer will plug things together, I think you must deal with loops. I have a fundamental disagreement with this. Any scenario where you would plug these in any other mode than in series should be strictly out of scope. IMHO, we don't want to deal with that. If the user plugs three ND-proxies in a triangle or two (or more) ND-proxies in a loop, the everything breaks -- and the customer fixes the set-up or calls someone to fix it. Immediate failure, immediate fix. I see no problem with this. As it is, ND-proxy should never be enabled by default in any case. > It is true that ndproxy as written can handle this, but it handles > it by running IEEE 802.1D spanning tree protocol over all media - including > non-IEEE 802 media - without specifying the details of how to carry IEEE 802 > bridge PDUs over Avian Carriers, bluetooth, etc. > That doesn't seem like the best approach. > An approach like draft-perlman-zerouter-rbridge-00.txt, which builds > a (very thin) overlay above the link layer between the rbridges look > a lot more interesting to me; no need to carry bridge PDUs around etc. No comment about this because I strongly believe we should get rid of the whole IEEE 802.1D spanning tree protocol hack from the protocol in the first place. -- 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 exim@www1.ietf.org Thu Mar 18 07:58:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07537 for ; Thu, 18 Mar 2004 07:58:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3x6R-0002KL-Od for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 07:58:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ICwR8F008939 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 07:58:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3x6R-0002K6-I0 for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 07:58:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07517 for ; Thu, 18 Mar 2004 07:58:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3x6Q-00007L-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 07:58:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3x5Y-0007nC-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 07:57:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3x4l-0007g9-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 07:56:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3x3A-0001qS-MI; Thu, 18 Mar 2004 07:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3x2T-0001ol-6H for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 07:54:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07312 for ; Thu, 18 Mar 2004 07:54:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3x2S-0007Of-00 for ipv6@ietf.org; Thu, 18 Mar 2004 07:54:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3x1W-0007Hs-00 for ipv6@ietf.org; Thu, 18 Mar 2004 07:53:23 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B3x0a-00075X-00 for ipv6@ietf.org; Thu, 18 Mar 2004 07:52:24 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 Mar 2004 04:58:29 -0800 X-BrightmailFiltered: true 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 i2ICpoU7012925; Thu, 18 Mar 2004 07:51:51 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-38.cisco.com [10.86.240.38]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGW61080; Thu, 18 Mar 2004 07:51:48 -0500 (EST) Message-Id: <4.3.2.7.2.20040318065445.02a03e88@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Mar 2004 07:51:46 -0500 To: Pekka Savola From: Ralph Droms Subject: Re: simpler prefix delegation Cc: Shin Miyakawa , ipv6@ietf.org, , , Erik.Nordmark@sun.com In-Reply-To: References: <20040318.184737.71091593.miyakawa@nttv6.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Pekka, We have some experience with the DHCPv6 spec that is useful in evaluating its complexity. There are roughly 6-10 full implementations of DHCPv6, including prefix delegation, address assignment and stateless. We performed interoperability testing of 6 or so implementations last year at TAHI and Connectathon. I summarized the test results in an I-D (which has since expired). We discovered no show-stopper interoperability problems with the implementations under test. There were 10 or 12 less significant problems that were easily fixed with clarifications to the spec. I think these interoperability results compare very favorably with initial testing of most IETF specs. We were able to integrate those fixes into the spec before it was published as RFC 3315. I received no complaints from any of the implementors that the spec was "too complicated" or "too heavyweight". I infer from these results that the spec is readable and useful as the basis for an implementation. I also point out that, depending on how you read the requirements, the DHCPv6 spec could advance to Draft Standard today, as we have demonstrated interoperability among multiple, independently developed implementations based on RFC3315. Here's a complete CLI for configuring the Cicso DHCPv6 server in IOS (note that this implementation in IOS resides in routers and does not require a separate server): (1) ipv6 local pool cpepref 3FFE:501:1000::/44 48 (2) ipv6 dhcp pool cpepool prefix-delegation pool cpepref dns-server 2002:1:1:11::1 dns-server 2002:1:1:11::2 domain-name cisco.com domain-name eng.cisco.com (3) interface FastEthernet0/0 ipv6 dhcp server cpepool The CLI sets up a pool of prefixes for delegation(1), associates the prefix pool with other DHCPv6 server configuration information (2) and enables the server on an interface (3). In this example, there is no customer identification or authentication (which is optional). It's hard to imagine a simpler interface... - Ralph At 01:40 PM 3/18/2004 +0200, Pekka Savola wrote: >On Thu, 18 Mar 2004, Shin Miyakawa wrote: > > > when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way > > > too heavy-weight". > > > > "way too Heavy Weight" is not well-defined. > > Please explain a bit more how you decide this. Pekka ? > > > > When we dicuss about measurement, we should be mathematical. > > Otherwise it sounds just a feeling or myth which > > leads us to just a superstition. > > > > In this case, the information carried by the protocol > > - either DHCP format or whatever - is essentially the same; > > just a prefix information which is about 128bits + prefix length. > > Therefore the volume of the bits are also not so different in either > case. > >There are many kinds of complexity / "heavy-weight": > > - specification complexity (how long the specs are, how difficul to >understand, etc.) -- DHCPv6 + PD: ~120 pages. > > - implementation complexity (how many lines of code, any particularly >difficult issues, etc.) -- DHCPv6: dozens? of thousands > > - requirements from the system (how does the mechanism interface with >the routers, access databases, etc. -- e.g., do you need to have v6 >support in RADIUS databases, do you need to have customer information >stored there, how is that communicated to the router or the DHCPv6 >server): It appears as if DHCPv6 has non-trivial set-up complexity. > > - the overhead in the messages (added bytes in all or some of the >packets): not much, unless you run PPP like described e.g. in >draft-shirasaki-dualstack-service-03.txt > > - the number of messages (how many packets (and how big) needed: >DHCPv6 request at least two roundtrips (4 messages), if PPP is used, >even more. > >It should be obvious that there is a significant difference here. > >The critical questions, of course are: > - is the difference significant enough (in any specific scenario) > - if yes, does it make sense to have another solution for some > specific scenarios (whether commonplace or not) > > > When I started the work of prefix delegation several years ago, > > Steve Deering told me that ICMP and RA are very fundamental so we > > should keep those as simple as possible. > >Well, I think we're discussing a very fundamental issue; it's IMHO >much more non-sensical to invent new protocols just because we can. > > > Lastly, Let us recall very important fact which is that we should > > not have many options or protocols for the same purpose. > >These IMHO serve slightly different purposes. DHCPv6 provides you >with a complex solution that works every time (well, on public LANs >setting up the key management is a mess); this proposal is aimed at >the simpler setups where the complexity is unnecessary and redundant. >In such scenarios, DHCPv6 is more likely than not even used (e.g., >with IPv6-over-IPv4 configured tunnels) -- and should not be required >(IMHO, of course). > >Let me ask another question: would you rather have proxy-ND for /64 >prefixes or a simple (non-DHCPv6) prefix delegation for /48's? > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 18 08:15:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08325 for ; Thu, 18 Mar 2004 08:15:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xLz-0003p0-To for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 08:14:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IDEVvX014684 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 08:14:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xLz-0003ol-NI for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 08:14:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08303 for ; Thu, 18 Mar 2004 08:14:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xLy-00024y-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:14:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xL3-0001xS-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:13:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3xKL-0001pp-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:12:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xJZ-0003IF-Rb; Thu, 18 Mar 2004 08:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xIv-0003HO-Rp for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 08:11:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08164 for ; Thu, 18 Mar 2004 08:11:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xIu-0001hD-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:11:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xI7-0001b2-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:10:31 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3xHa-0001SV-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:09:58 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 05:14:39 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2ID8uiZ008797; Thu, 18 Mar 2004 14:08:56 +0100 (MET) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA21281; Thu, 18 Mar 2004 13:08:57 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Cc: ipv6@ietf.org, skylane@etri.re.kr, Subject: Re: simpler prefix delegation References: From: Ole Troan Date: Thu, 18 Mar 2004 13:08:57 +0000 In-Reply-To: (Pekka Savola's message of "Thu, 18 Mar 2004 10:50:21 +0200 (EET)") Message-ID: <7t5oequs3o6.fsf@mrwint.cisco.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Pekka, > This started from me looking at draft-bykim-ipv6-hpd-01.txt, what it > was before that, DHCPv6 + PD, a few proposals at v6ops for integrated > prefix delegation, etc.. -- I couldn't help thinking, "there must be > an easier way to delegate an IPv6 prefix in the simplest setups (e.g., > when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way > too heavy-weight". I disagree that DHCPv6 too heavy-weight (whatever that means). Haberman's ICMP prefix delegation draft initiated the IPv6 W.G's work on prefix delegation. it pretty soon became clear that we were reinventing DHCP, so instead of developing a new DHCP lookalike, we decided to reuse the existing DHCP infrastructure instead. if I understand you correctly you want to specify a separate protocol which handles prefix delegation in a restricted setup. how is the requesting router going to determine which prefix delegation protocol to use? can you auto-detect that the user setup is suitable for the 'simple' protocol? as an implementor I find that implementing only one protocol to solve a problem is less complex and results in a less heavyweight implementation, than having to implement two protocols... /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 18 08:43:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10215 for ; Thu, 18 Mar 2004 08:43:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xnB-0006Th-Q1 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 08:42:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IDgbuD024895 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 08:42:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xnB-0006TS-Jo for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 08:42:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10181 for ; Thu, 18 Mar 2004 08:42:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xnA-0006Ud-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:42:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xmI-0006Ks-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:41:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3xlS-0006CD-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:40:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xkg-0005w3-7C; Thu, 18 Mar 2004 08:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xk4-0005ue-Nx for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 08:39:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09974 for ; Thu, 18 Mar 2004 08:39:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xk3-0005zt-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:39:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xj9-0005sa-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:38:27 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xiN-0005eL-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:37:40 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2IDatm31549; Thu, 18 Mar 2004 15:36:55 +0200 Date: Thu, 18 Mar 2004 15:36:55 +0200 (EET) From: Pekka Savola To: Ole Troan cc: ipv6@ietf.org, , , Subject: Re: simpler prefix delegation In-Reply-To: <7t5oequs3o6.fsf@mrwint.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Reponding to both you and Ralph. [Ralph:] ..... > The CLI sets up a pool of prefixes for delegation(1), associates the prefix > pool with other DHCPv6 server configuration information (2) and enables the > server on an interface (3). In this example, there is no customer > identification or authentication (which is optional). It's hard to imagine > a simpler interface... Yep -- the _interface_ can't be much simpler than that. It can be set-up easily. Then why again do we need 120+ pages, dozens of thousands of lines of codes, at least 4 messages, etc.etc. to accomplish all this? This is a very simple case, solved with *very* simple means! On Thu, 18 Mar 2004, Ole Troan wrote: > Haberman's ICMP prefix delegation draft initiated the IPv6 W.G's work > on prefix delegation. it pretty soon became clear that we were > reinventing DHCP, so instead of developing a new DHCP lookalike, we > decided to reuse the existing DHCP infrastructure instead. That was probably based on the premise that it would have had to re-implement everything that DHCP could provide. I don't make that assumption. Maybe the simple solution could be used in all the configured tunnel cases now, and 50-90% of xDSL access cases; but someone is bound to figure out uses for which one might desire something like DHCPv6 PD. I have no objection to that :). > if I understand you correctly you want to specify a separate protocol > which handles prefix delegation in a restricted setup. how is the > requesting router going to determine which prefix delegation protocol > to use? can you auto-detect that the user setup is suitable for the > 'simple' protocol? For the requestor, it doesn't really matter. If you implement both, you just run them in whichever order you want. If you get a prefix, you don't try with the other protocol. The point is to support the case if the delegator would only support one protocol (possibly the "simpler" one), not both. > as an implementor I find that implementing only one protocol to > solve a problem is less complex and results in a less heavyweight > implementation, than having to implement two protocols... If everyone would implement the more complex protocol, possibly. Of course, the question is -- why should everyone implement a complex protocol if they only need a very small part of it which can stand easily on its own? This is a similar argument to the "DNS resolver discovery" in some way, but more urgent in the sense that on dual-stack systems you don't need to discover IPv6 DNS resolver, but you still need the prefix :-). -- 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 exim@www1.ietf.org Thu Mar 18 08:57:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11047 for ; Thu, 18 Mar 2004 08:57:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3y0e-0007cY-OM for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 08:56:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IDuW74029288 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 08:56:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3y0e-0007cJ-FO for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 08:56:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11033 for ; Thu, 18 Mar 2004 08:56:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3y0d-0000mk-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:56:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xzd-0000f4-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:55:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3xz8-0000Y9-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:54:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xyD-0007He-Gc; Thu, 18 Mar 2004 08:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xxa-0007Gg-Lw for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 08:53:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10907 for ; Thu, 18 Mar 2004 08:53:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xxZ-0000NT-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:53:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xwp-0000GY-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:52:35 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3xvr-00001Y-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:51:35 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2004 05:56:16 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2IDoWiZ022310; Thu, 18 Mar 2004 14:50:33 +0100 (MET) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA22972; Thu, 18 Mar 2004 13:50:22 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Cc: ipv6@ietf.org, , , Subject: Re: simpler prefix delegation References: From: Ole Troan Date: Thu, 18 Mar 2004 13:50:22 +0000 In-Reply-To: (Pekka Savola's message of "Thu, 18 Mar 2004 15:36:55 +0200 (EET)") Message-ID: <7t5brmus1r5.fsf@mrwint.cisco.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Pekka, > [Ralph:] > ..... >> The CLI sets up a pool of prefixes for delegation(1), associates the prefix >> pool with other DHCPv6 server configuration information (2) and enables the >> server on an interface (3). In this example, there is no customer >> identification or authentication (which is optional). It's hard to imagine >> a simpler interface... > > Yep -- the _interface_ can't be much simpler than that. It can be > set-up easily. Then why again do we need 120+ pages, dozens of > thousands of lines of codes, at least 4 messages, etc.etc. to > accomplish all this? DHCPv6 supports a two message exchange. > This is a very simple case, solved with *very* simple means! >> Haberman's ICMP prefix delegation draft initiated the IPv6 W.G's work >> on prefix delegation. it pretty soon became clear that we were >> reinventing DHCP, so instead of developing a new DHCP lookalike, we >> decided to reuse the existing DHCP infrastructure instead. > > That was probably based on the premise that it would have had to > re-implement everything that DHCP could provide. I don't make that > assumption. no, it was made on the assumption that the protocol would have to fulfill the requirements as stated in the requirements document. can you please specify exactly what you want to simplify? it is hard to argue against vague statements like 'complex' and 'heavyweight'... /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 18 09:00:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11287 for ; Thu, 18 Mar 2004 09:00:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3y3a-00084P-GP for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 08:59:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IDxYcB031015 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 08:59:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3y3a-00084A-7o for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 08:59:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11229 for ; Thu, 18 Mar 2004 08:59:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3y3Y-0001Bm-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:59:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3y2b-000145-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:58:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3y1m-0000wu-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 08:57:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3y17-0007dE-CR; Thu, 18 Mar 2004 08:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3y0U-0007br-Vq for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 08:56:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11021 for ; Thu, 18 Mar 2004 08:56:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3y0T-0000lP-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:56:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xzU-0000do-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:55:21 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1B3xya-0000QQ-00 for ipv6@ietf.org; Thu, 18 Mar 2004 08:54:24 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i2IDrKS8000952; Thu, 18 Mar 2004 14:53:21 +0100 Received: from alcatel.fr ([172.25.81.180]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004031814531480:4109 ; Thu, 18 Mar 2004 14:53:14 +0100 Message-ID: <4059A9CB.1060106@alcatel.fr> Date: Thu, 18 Mar 2004 14:53:15 +0100 From: Laurent.Clevy@alcatel.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: ipv6@ietf.org, skylane@etri.re.kr, erik.nordmark@sun.com, Olivier =?iso-8859-1?Q?Marc=E9?= Subject: Re: simpler prefix delegation References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/18/2004 14:53:15, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 03/18/2004 14:53:20 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, We are working on the subject since last year and have a first prototype that does prefix delegation and global=20 address configuration on a simple IPv6 network. Here follows some thoughts that could help, I hope. Pekka Savola wrote: >Hi, > >This started from me looking at draft-bykim-ipv6-hpd-01.txt, what it >was before that, DHCPv6 + PD, a few proposals at v6ops for integrated >prefix delegation, etc.. -- I couldn't help thinking, "there must be >an easier way to delegate an IPv6 prefix in the simplest setups (e.g., >when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way >too heavy-weight". > >This is where I got. Thoughts appreciated. > >Problems with the spec (draft-bykim-ipv6-hpd-01.txt) >---------------------- > >I think this is a useful continuation of Brian/Jim's Automatic Prefix >Delegation work. All the problems in the world are not necessarily solved >by DHCPv6... so I think developing an extremely simple PD protocol could be >very useful. The applicability area I see for this are the cases where >DHCPv6 is not being used, especially when the ISP wants to offer IPv6 >support very simply, using a tunnel. > >However, this document goes into a bit too complex direction. There are >multiple problems with the approach as-is: > > - Why use PrefixCnt, and not PrefixLen when sending the Delegator Query? = >The most important thing is the length of the desired prefix, not the numb= er >of them, after all. The whole PrefixCnt thing seems fishy to me, all in a= ll >-- the same information can be obtained by using an appropriate PrefixLen! > > =20 > How a delegator has to allocate address space is a key point IHMO. A Delegator has to split a unique and large address space into several=20 smaller ones. And this address small can be used in two ways: - link numbering - sub-delegation the right to sub-delegate a given prefix could be allowed by a delegator=20 to a requetor, or not: only for link-numbering. to avoid the usage of all the address space of delegated prefix very=20 quickly. > - Similarly, PrefixDiff doesn't seem to be all that useful. > > =20 > how the prefix length is raising represents how fast the address space=20 is used from the root router to leaf routers. > - CGA security does not work unless you use Signature options from SEND as >well, so that can be scrapped. > > - 2 roundtrips are needed, with 4 different messages to get a prefix: a b= it >too many for my taste. > > =20 > Finding a delegator is different from retrieving a prefix. Like finding=20 the authority and the resource. I think is interesting to dissociate the 2 tasks, for example to be able to retrieve prefixes from 2 different delegators. > - The draft makes confusion about "built-in routing". That sort of thing >is integrated with prefix delegation in any case: you can't have it without >-- as static routes are set in any case. This seems unnecessary to mention >here. > > - The scope is not clear; why would one need hierarchical prefix >delegation where one would not use routing? That is, if one gets a /64, it >cannot be delegated (in a meaningful way) forward. If one gets a /48 (e.g= ., >on a home network), why would one need to delegate it forward -- are there >routers there, requesting smaller prefixes -- I hope not! And in an >Enterprise, you want to set this up manually in any case. So the whole >hierarchical part appears to be really fishy, and should be removed unless >clear justification is found. > > =20 > I see in HPD a simple way to have unique and global subnet values based=20 on a global initial prefix. And when link numbering is well done, resulting propagated routes can=20 be minimized. >So -- I think think the spec has suffered from a serious feature creep, wi= th >little regard to the actual user needs. > >But, I'd still propose to go forward with this (or another document, start= ed >from scratch), in an entirely different format and design tradeoffs, as >described below.=20 > >I could write it, but I would prefer if someone else wanted to work on >this (too many things in progress at the moment.) > >Current model is basically like: >-------------------------------- > > 1. Delegator Query, looking up the delegators and signalling the number of > prefixes solicited (no prefix length?). > 2. Response w/ nmber of prefixes and prefix len difference (how?) > 3. Prefix Request to request prefixes (not telling which) > 4. Response w/ prefix delegated=20 > >Return: prefix returned message -- replied with prefix returned. > >Renewal: renewal message. > >As you see, there are a lot of different messages, with different subcodes: >really difficult to understand.. > > =20 > I think the approach is good, even using another link-local messaging, we thought of course about using ND and SEND to secure the Delegator=20 claimed role. >Proposal >-------- > >Instead, use Neighbor Discovery messages rather than directly putting them >on top of ICMPv6. This gives the benefit of being able to use all the >functions of SEND without any specification, as SEND only protects neighbor >discovery messages (and all of them, if you just plug in the signatures et= c!). > >[[ the features in double brackets are ones that could be easily=20 >added, but IMHO I'm not sure whether that is worth the effort. ]] > >Now, the messages could be like: > > =20 > I think a first step could be to find a trusted Delegator, to avoid abuse of a malicious prefix provider node (using SEND and=20 signature ND option). > Prefix Solicitation: sent to "all-prefix-delegators" link-local multicast >address or a unicast address (learned using means outside the scope of this >memo; but link local) > * addresses checked to be link-local, TTL=3D255. (same for all the >messages.) > * Includes PrefixLen field, indicating the preference for the prefix > length > * Includes a "Test" flag: if given, the routers does not > actually delegate the prefix, only show which prefix they would have > given. (This can be used to pick among the routers, as well as learn > which kind of prefixes/lengths they would be giving. But the point is > that if there are multiple routers which are willing to give you a pr= efix, > why not get prefix from each unless explicitly desiring otherwise?) > * Includes a "No Refresh" flag: if given, do not refresh the existing > prefixes, but allocate new ones; the old ones continue to be used. If > not given, refresh the old prefixes (if delegated) or allocate new on= es > (if no existing delegation). > * [[ no PrefixCnt field, as this seems unnecessary -- just use=20 > PrefixLen or ask again -- but could be plugged > in later if deemed necessary ]] > * [[ no authentication/user identification options; authentication=20 > is assumed to be obtained > on the link layer. However, it is possible to include Authentication > type and length fields (1 octet each) which can be used to piggyback > different kinds of authentication information, later on if needed. > Authentication could also be done with SEND. ]] > * [[ one could have "reverse DNS delegation requested" flag here as wel= l, > with an option which could encode DNS server address(es), but I don't > think that's really important for mainstream use.]] > > =20 > > Prefix Delegation: sent to the unicast link-local address of solicitor > * includes Test flag, to indicate whether delegation was really done > * [[ could also have reverse DNS delegated flag, as described above, but > IMHO doesn't seem to be really important for now.]] > * includes the prefix(es) delegated to the user. > > [[ each prefix could have a > lifetime as well; lifetime of zero means "not specified" -- no > refreshing is needed as long as NUD works. If lifetime not > specified, the lifetime of RAs on downstream interfaces SHOULD NOT be > greater than 7200 seconds. ]] > >[[ Prefix Maintenance: miscellaneous messages > * code 0: return the prefix; used by the solicitor to give back a prefi= x, > either when ceasing to use it or when refusing the prefix delegatio= n. >]] -- could be used for serious DoS unless authenticated. > >The solicititor SHOULD run NUD on the interface. If NUD fails to the >routers which have delegated prefix(es), MAY send a Prefix >Solicitation message with "No Refresh" not set (to know whether the >delegation exists; if it doesn't, to get a new one). If some other >indication has been received that the interface has went up/down, may >similarly re-initiate the procedure. > >Would this seem to make sense? This also fulfills the prefix delegation >requirements draft's requirements pretty well AFAICS. > > =20 > to go further until link numebering, and to avoid to much prefixes usage on the same link, our experiment showed that a link prefix "negociation" is useful. Hope the propositions above could help. I'm adding a big Thanks to APD and HPD authors for their work on the=20 problem. Regards, Laurent Cl=E9vy --=20 Laurent Cl=E9vy =20 Alcatel CIT, R&I Voice: +33 (0)1 69 63 18 34 Route de Nozay Fax : +33 (0)1 69 63 13 59 91460 Marcoussis mailto:Laurent.Clevy@alcatel.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 18 09:30:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13384 for ; Thu, 18 Mar 2004 09:30:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yXJ-00021c-FD for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 09:30:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IEUHmp007751 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 09:30:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yXI-00020w-N4 for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 09:30:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13289 for ; Thu, 18 Mar 2004 09:30:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yXH-0005QX-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 09:30:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yWK-0005DB-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 09:29:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3yVA-0004yA-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 09:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yU9-0001Tg-Qt; Thu, 18 Mar 2004 09:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yTu-0001T2-Qe for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 09:26:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12757 for ; Thu, 18 Mar 2004 09:26:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yTt-0004gY-00 for ipv6@ietf.org; Thu, 18 Mar 2004 09:26:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ySr-0004Tb-00 for ipv6@ietf.org; Thu, 18 Mar 2004 09:25:42 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yRs-0004BH-00 for ipv6@ietf.org; Thu, 18 Mar 2004 09:24:40 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2IEO0332209; Thu, 18 Mar 2004 16:24:00 +0200 Date: Thu, 18 Mar 2004 16:24:00 +0200 (EET) From: Pekka Savola To: Ole Troan cc: ipv6@ietf.org, , , Subject: Re: simpler prefix delegation In-Reply-To: <7t5brmus1r5.fsf@mrwint.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 18 Mar 2004, Ole Troan wrote: > >> Haberman's ICMP prefix delegation draft initiated the IPv6 W.G's work > >> on prefix delegation. it pretty soon became clear that we were > >> reinventing DHCP, so instead of developing a new DHCP lookalike, we > >> decided to reuse the existing DHCP infrastructure instead. > > > > That was probably based on the premise that it would have had to > > re-implement everything that DHCP could provide. I don't make that > > assumption. > > no, it was made on the assumption that the protocol would have to > fulfill the requirements as stated in the requirements document. What I proposed does this; let's see: 3.1 Number and Length of Delegated Prefixes ==> fills all three requirements. 3.2 Use of Delegated Prefixes in Customer Network ==> fills both requirements. 3.3 Static and Dynamic Assignment The prefix delegation mechanism should allow for long-lived static pre-assignment of prefixes and for automated, possibly short-lived on-demand dynamic assignment of prefixes to a customer. ==> both allowed. (The former obviously requires configuration, but this is no different from DHCPv6.) The short-lived delegation case may profit from the lifetime associated with the prefix. 3.4 Policy-based Assignment The prefix delegation mechanism should allow for the use of policy in assigning prefixes to a customer. For example, the customer's identity and type of subscribed service may be used to determine the address block from which the customer's prefix is selected, and the length of the prefix assigned to the customer. ==> policy is outside the scope of the proposal, but this is a "should" so it fulfills the requirements even as-is. Obviously, this is supported if a database or similar includes notion of policy in terms of customer interfaces (or the like), or if you use the authentication/user identification option. 3.5 Security and Authentication The prefix delegation mechanism must provide for reliable authentication of the identity of the customer to which the prefixes are to be assigned, and must provide for reliable, secure transmission of the delegated prefixes to the customer. ==> yes (incoming interface or other customer identification, SEND, or the authentication/identification option), yes (SEND). 3.6 Accounting ==> yes. 3.7 Hardware technology Considerations The prefix delegation mechanism should work on any hardware technology and should be hardware technology independent. The mechanism must work on shared links. The mechanism should work with all hardware technologies either with an authentication mechanism or without, but ISPs would like to take advantage of the hardware technology's authentication mechanism if it exists. ==> yes; yes for shared links (requires authentication in some means as above; equally problematic with DHCPv6); yes. So, it seems all the requirements are fulfilled, with much lower amount of complexity. > can you please specify exactly what you want to simplify? it is hard > to argue against vague statements like 'complex' and 'heavyweight'... I want to simplify the protocol, for the protocol to be simple and easy to understand, and trivial to implement. DHCPv6 PD spec is about 20 pages long; that is one primer: the whole protocol should be no longer than that. Of course, all of this is a moot point if the consensus is that full DHCPv6 must be implemented by every box (especially if it could be used as a router); but I don't think such exists. -- 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 exim@www1.ietf.org Thu Mar 18 10:31:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19727 for ; Thu, 18 Mar 2004 10:31:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zUZ-0005zm-QH for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 10:31:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IFVVZ6023042 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 10:31:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zUY-0005zZ-PX for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 10:31:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19622 for ; Thu, 18 Mar 2004 10:31:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zUW-0005q2-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 10:31:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zSd-0005XX-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 10:29:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3zRg-0005Op-01 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 10:28:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3zI5-0005yB-It for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 10:18:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zG8-00025N-Os; Thu, 18 Mar 2004 10:16:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3zEz-0001rA-Lf for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 10:15:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17992 for ; Thu, 18 Mar 2004 10:15:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zEx-0004eh-00 for ipv6@ietf.org; Thu, 18 Mar 2004 10:15:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3zEC-0004bm-00 for ipv6@ietf.org; Thu, 18 Mar 2004 10:14:37 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3zDM-0004Rr-00 for ipv6@ietf.org; Thu, 18 Mar 2004 10:13:45 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2IFD2g00930; Thu, 18 Mar 2004 17:13:02 +0200 Date: Thu, 18 Mar 2004 17:13:02 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: ipv6@ietf.org, Ole Troan , , Subject: Re: simpler prefix delegation In-Reply-To: <4.3.2.7.2.20040318093441.029eb910@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 18 Mar 2004, Ralph Droms wrote: > Is there interest in expending any more of the IETF's resources > reopening a problem for which we have rough consensus on a solution, > published specifications and running code? You say that carefully, but still giving an impression as if rough consensus had been gauged that only one solution would be specified -- otherwise there would not be "reopening" the problem. That has never been even raised (AFAIR); I'd certainly have objected. The fact that there is a solution out there, which fits the needs of some users, does not mean that there can not (or should not) be a different kind of solution which would seem to be much more appropriate in some other scenarios or for some other users. -- 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 exim@www1.ietf.org Thu Mar 18 13:06:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27910 for ; Thu, 18 Mar 2004 13:06:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41tS-0003aD-4v for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 13:05:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2II55jq013644 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 13:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41t1-0003Wx-7I for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 13:04:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27844 for ; Thu, 18 Mar 2004 13:04:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B41si-0007e5-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 13:04:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B41rp-0007an-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 13:03:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B41r4-0007Xo-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 13:02:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41qE-00038R-7K; Thu, 18 Mar 2004 13:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41oo-00032V-9r for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 13:00:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27741 for ; Thu, 18 Mar 2004 13:00:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B41oi-0007Sb-00 for ipv6@ietf.org; Thu, 18 Mar 2004 13:00:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B41ns-0007Qv-00 for ipv6@ietf.org; Thu, 18 Mar 2004 12:59:37 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1B41my-0007OS-00 for ipv6@ietf.org; Thu, 18 Mar 2004 12:58:40 -0500 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id i2IHvVO28070; Thu, 18 Mar 2004 09:57:31 -0800 (PST) From: Bill Manning Message-Id: <200403181757.i2IHvVO28070@boreas.isi.edu> Subject: Re: ASN-based prefixes for leaf ASes To: pekkas@netcore.fi (Pekka Savola) Date: Thu, 18 Mar 2004 09:57:31 -0800 (PST) Cc: stephen@sprunk.org (Stephen Sprunk), ipv6@ietf.org (IETF IPv6 WG) In-Reply-To: from "Pekka Savola" at Mar 17, 2004 07:15:15 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ISI-4.27.7-MailScanner: Found to be clean X-MailScanner-From: bmanning Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % On Wed, 17 Mar 2004, Stephen Sprunk wrote: % > Thoughts? % Been there, done that, gotten flamed about it :-). Not flamed, simply pointed out that this was the method used and documented for preliminary IPv6 address delegations ... before the creation of the 6bone. The expectation was/is that the RIRs should be setting prefix delegation policies and the IETF should work on protocols. % % draft-savola-multi6-asn-pi-01.txt % (Well, I don't like that proposition either..) % p.s. the correct forum may be multi6. Actually, the correct forum would be the RIR public policy mtgs. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 18 15:22:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06332 for ; Thu, 18 Mar 2004 15:22:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B441G-0001Ef-JE for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 15:21:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IKLYot004743 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 15:21:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B441G-0001EQ-D0 for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 15:21:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06279 for ; Thu, 18 Mar 2004 15:21:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B441F-0000mB-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 15:21:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B440J-0000iT-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 15:20:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B43zT-0000eb-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 15:19:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43ws-0007qz-ED; Thu, 18 Mar 2004 15:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yrs-0004ZD-Ny for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 09:51:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15050 for ; Thu, 18 Mar 2004 09:51:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yrq-0000nK-00 for ipv6@ietf.org; Thu, 18 Mar 2004 09:51:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yqz-0000du-00 for ipv6@ietf.org; Thu, 18 Mar 2004 09:50:38 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1B3yq0-0000UB-00 for ipv6@ietf.org; Thu, 18 Mar 2004 09:49:36 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Mar 2004 15:49:20 +0100 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 Subject: RE: simpler prefix delegation Date: Thu, 18 Mar 2004 15:49:20 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC21857B3@ftrdmel3.rd.francetelecom.fr> Thread-Topic: simpler prefix delegation Thread-Index: AcQM9TFBu0PbP5+DTYqVRHPv+0gLOAAAV/0w From: "BINET David FTRD/DMI/CAE" To: "Pekka Savola" , "Ole Troan" Cc: , , , X-OriginalArrivalTime: 18 Mar 2004 14:49:20.0501 (UTC) FILETIME=[32170A50:01C40CF8] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Actually, I do not understand very well why we need a new prefix delegation mechanism. The assumptions to justify such work are the complexity of DHCPv6-PD protocol and the fact that all the problems in the world are not necessarily solved by DHCPv6 but I do not see in the thread some real reasons to undertake the specification of a new mechanism for one purpose. If the DHCPv6-PD specification is too "heavy", even if it was not necessarly the point of view of implementors according to Ralph's message, I think it would be better to try to simplify the protocol than specifying a new protocol that will cause some interaction problems since customers, ISPs and vendors will have to deal with two mechanisms for one purpose. David > -----Message d'origine----- > De : ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]De la=20 > part de Pekka > Savola > Envoye : jeudi 18 mars 2004 15:24 > A : Ole Troan > Cc : ipv6@ietf.org; rdroms@cisco.com; skylane@etri.re.kr; > erik.nordmark@sun.com > Objet : Re: simpler prefix delegation >=20 >=20 > On Thu, 18 Mar 2004, Ole Troan wrote: > > >> Haberman's ICMP prefix delegation draft initiated the=20 > IPv6 W.G's work > > >> on prefix delegation. it pretty soon became clear that we were > > >> reinventing DHCP, so instead of developing a new DHCP=20 > lookalike, we > > >> decided to reuse the existing DHCP infrastructure instead. > > > > > > That was probably based on the premise that it would have had to=20 > > > re-implement everything that DHCP could provide. I don't=20 > make that=20 > > > assumption. =20 > >=20 > > no, it was made on the assumption that the protocol would have to > > fulfill the requirements as stated in the requirements document. >=20 > What I proposed does this; let's see: >=20 > 3.1 Number and Length of Delegated Prefixes >=20 > =3D=3D> fills all three requirements. >=20 > 3.2 Use of Delegated Prefixes in Customer Network >=20 > =3D=3D> fills both requirements. >=20 > 3.3 Static and Dynamic Assignment >=20 > The prefix delegation mechanism should allow for long-lived static > pre-assignment of prefixes and for automated, possibly short-lived > on-demand dynamic assignment of prefixes to a customer. >=20 > =3D=3D> both allowed. (The former obviously requires configuration, = but=20 > this is no different from DHCPv6.) The short-lived delegation case=20 > may profit from the lifetime associated with the prefix. >=20 > 3.4 Policy-based Assignment >=20 > The prefix delegation mechanism should allow for the use=20 > of policy in > assigning prefixes to a customer. For example, the customer's > identity and type of subscribed service may be used to=20 > determine the > address block from which the customer's prefix is selected, and the > length of the prefix assigned to the customer. >=20 > =3D=3D> policy is outside the scope of the proposal, but this is a > "should" so it fulfills the requirements even as-is. Obviously, this > is supported if a database or similar includes notion of policy in > terms of customer interfaces (or the like), or if you use the > authentication/user identification option. >=20 > 3.5 Security and Authentication >=20 > The prefix delegation mechanism must provide for reliable > authentication of the identity of the customer to which=20 > the prefixes > are to be assigned, and must provide for reliable, secure > transmission of the delegated prefixes to the customer. >=20 > =3D=3D> yes (incoming interface or other customer identification,=20 > SEND, or=20 > the authentication/identification option), yes (SEND). >=20 > 3.6 Accounting >=20 > =3D=3D> yes. >=20 > 3.7 Hardware technology Considerations >=20 > The prefix delegation mechanism should work on any hardware > technology and should be hardware technology independent. The > mechanism must work on shared links. The mechanism should=20 > work with > all hardware technologies either with an authentication=20 > mechanism or > without, but ISPs would like to take advantage of the hardware > technology's authentication mechanism if it exists. >=20 > =3D=3D> yes; yes for shared links (requires authentication in some = means=20 > as above; equally problematic with DHCPv6); yes. >=20 > So, it seems all the requirements are fulfilled, with much lower=20 > amount of complexity. >=20 > > can you please specify exactly what you want to simplify? it is hard > > to argue against vague statements like 'complex' and=20 > 'heavyweight'... >=20 > I want to simplify the protocol, for the protocol to be simple and > easy to understand, and trivial to implement. DHCPv6 PD spec is about > 20 pages long; that is one primer: the whole protocol should be no > longer than that. >=20 > Of course, all of this is a moot point if the consensus is that full > DHCPv6 must be implemented by every box (especially if it could be > used as a router); but I don't think such exists. >=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 >=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 exim@www1.ietf.org Thu Mar 18 18:10:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15219 for ; Thu, 18 Mar 2004 18:10:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B46dz-0001hu-Tt for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 18:09:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IN9h6J006552 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 18:09:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B46dz-0001hP-Jc for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 18:09:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15169 for ; Thu, 18 Mar 2004 18:09:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B46dw-0005kj-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 18:09:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B46dB-0005i4-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 18:08:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B46cX-0005ej-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 18:08:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B46aQ-000820-DR; Thu, 18 Mar 2004 18:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B46a8-0007w1-RV for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 18:05:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14706 for ; Thu, 18 Mar 2004 18:05:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B46a5-0005VA-00 for ipv6@ietf.org; Thu, 18 Mar 2004 18:05:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B46ZA-0005SF-00 for ipv6@ietf.org; Thu, 18 Mar 2004 18:04:45 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1B46YX-0005Pg-00 for ipv6@ietf.org; Thu, 18 Mar 2004 18:04:05 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2IN45wr026765 for ; Thu, 18 Mar 2004 16:04:05 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HUS0064FO2SQQ@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Thu, 18 Mar 2004 16:04:05 -0700 (MST) Received: from [192.168.1.100] ([66.93.39.75]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HUS0067IO2RXQ@mail.sun.net> for ipv6@ietf.org; Thu, 18 Mar 2004 16:04:04 -0700 (MST) Date: Thu, 18 Mar 2004 15:04:03 -0800 From: Alain Durand Subject: Re: simpler prefix delegation In-reply-to: <0AAF93247C75E3408638B965DEE11A7006477E0B@i2km41-ukdy.domain1.systemhost.net> To: matthew.ford@bt.com Cc: ipv6@ietf.org, erik.nordmark@Sun.COM, skylane@etri.re.kr, ot@cisco.com, pekkas@netcore.fi, rdroms@cisco.com Message-id: <8D01F956-7930-11D8-B301-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <0AAF93247C75E3408638B965DEE11A7006477E0B@i2km41-ukdy.domain1.systemhost.net> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Mar 18, 2004, at 8:47 AM, matthew.ford@bt.com wrote: > On 18 March 2004, Pekka Savola wrote: >> >> The fact that there is a solution out there, which fits the >> needs of some users, does not mean that there can not (or >> should not) be a different kind of solution which would seem >> to be much more appropriate in some other scenarios or for >> some other users. > > As I've said before in reference to the recursive name server discovery > discussion, I don't believe it benefits the network operations > community > to have multiple solutions to these kind of requirements. Neither does it benefit the implementor community which then does not know what to implement, nor how to make all the alternative solution works together. So unless someone can come with a better reason than 'I do not like to read the DHCPv6 spec because it is 120 pages long', please let's stick to one solution and move on to try to solve other still unresolved issues. - Alain. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 18 19:13:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18789 for ; Thu, 18 Mar 2004 19:13:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B47dU-0000TR-Jw for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 19:13:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J0DGbQ001815 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 19:13:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B47dU-0000TC-FF for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 19:13:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18766 for ; Thu, 18 Mar 2004 19:13:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B47dT-0002GV-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 19:13:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B47cO-00029R-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 19:12:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B47bS-00023c-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 19:11:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B47ZN-0008FD-Nt; Thu, 18 Mar 2004 19:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B47ZF-0008Ej-FB for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 19:08:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18454 for ; Thu, 18 Mar 2004 19:08:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B47ZC-0001uG-00 for ipv6@ietf.org; Thu, 18 Mar 2004 19:08:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B47YS-0001rA-00 for ipv6@ietf.org; Thu, 18 Mar 2004 19:08:05 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1B47Xr-0001l5-00 for ipv6@ietf.org; Thu, 18 Mar 2004 19:07:27 -0500 Received: from txc.com ([172.17.0.173]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id i2J06t006166; Thu, 18 Mar 2004 19:06:55 -0500 Message-ID: <405A399E.5040609@txc.com> Date: Thu, 18 Mar 2004 19:06:54 -0500 From: srihari varada User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: srihari varada CC: ietf-ppp@merit.edu, ipv6@ietf.org Subject: Re: updates to IPv6 over PPP spec. References: <402A9D53.8020708@txc.com> In-Reply-To: <402A9D53.8020708@txc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear All: Provided below is the *ratified *input received from the IPv6 community on the IPv6 over PPP spec. The modifications will be made as per the recommendations. * Relax the recommendation on the disabling of DAD, if the IPv6CP negotiates interface identifier with the peer "The Duplicate address detection shouldn't be recommended to be disabled, if the IPv6CP negotiates interface identifier with the peer. There is a train of thought that even if the interface identifier is negotiated, DAD is required on, for instance, global unicast address (assuming stateless address autoconfiguration) but not necessarily on Link-local address." * Review and clarify the IPv6 over PPP specification to match the current IPv6 addressing architecture as specified inRFC 3314. * Provide a big picture on how global unicast addresses are obtained to piece different aspects of addressing in an appendix * Identify an exception to consistent reproduction of interface identifier. "The Interface Identifier section should mention an exception (due to the need for privary addresses) to the suggestion of consistent reproduction of the interface identifier -- RFC 2472 states that the interface identifier is suggested to be consistently reproducable across initializations of the IPv6CP finite state machine (see section 4.1). The text should be elaborated to include an exception as identified by the Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (RFC 3041)." * Clarify the use of interface identifier negotiated in IPv6CP in configuring global addresses "One thing related to 2472 came up during the discussions in the run up to RFC 3314. It wasn't clear to all whether a host must use the IID that gets assigned in IPv6CP also to create a global address (stateless) and whether the host must only use that IID to configure global addresses. I believe neither are valid assumptions. Section 4.1 of 2472 says : The interface identifier MUST be unique within the PPP link; i.e. upon completion of the negotiation different Interface-Identifier values are to be selected for the ends of the PPP link. The interface identifier MAY also be unique over a broader scope. In Section 5: The Interface Identifier of IPv6 unicast addresses [6] of a PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP connection setup (see section 4.1). The spec doesn't seem to clarify the issue above unless I've missed something. So it may be a good idea to add some text to one of the above sections such as: It cannot be assumed that a host will use this interface identifier also for configuring global addresses using stateless address autoconfiguration. A host may generate one or more interface identifiers to autoconfigure one or more global addresses on its PPP interface using a method like [RFC3041]." Regards, Srihari Varada -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 19 00:58:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02833 for ; Fri, 19 Mar 2004 00:58:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4D13-000485-To for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 00:57:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J5vv8v015872 for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 00:57:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4D13-00047v-Pe for ipv6-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 00:57:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02817 for ; Fri, 19 Mar 2004 00:57:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4D11-0003aX-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 00:57:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4D05-0003Wx-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 00:56:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4CzO-0003Te-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 00:56:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4CyG-0003jN-RH; Fri, 19 Mar 2004 00:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4CxD-0003fo-KZ for ipv6@optimus.ietf.org; Fri, 19 Mar 2004 00:53:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02682 for ; Fri, 19 Mar 2004 00:53:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4CxA-0003M9-00 for ipv6@ietf.org; Fri, 19 Mar 2004 00:53:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4CwH-0003IZ-00 for ipv6@ietf.org; Fri, 19 Mar 2004 00:53:02 -0500 Received: from [203.197.140.35] (helo=mail.future.futsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1B4CvZ-000396-00 for ipv6@ietf.org; Fri, 19 Mar 2004 00:52:17 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Fri, 19 Mar 2004 11:20:51 +0530 Received: from suvendum (suvendum.future.futsoft.com [10.6.4.104]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i2J5mXb10602 for ; Fri, 19 Mar 2004 11:18:33 +0530 Reply-To: From: "Suvendu M" To: Subject: Deletion of auto configured link local address Date: Fri, 19 Mar 2004 11:19:18 +0530 Message-ID: <000001c40d75$ece9da60$6804060a@future.futsoft.com> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have a doubt regarding deletion of auto configured link local address. We know that whenever a IPv6 node comes it comes up with a link local address (addr1). Now say I manually configure another link local address (addr2) on that interface (its possible if I am not wrong). Now can I delete the auto configured link local address (addr1) ?? Regards Suvendu. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 19 04:18:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23643 for ; Fri, 19 Mar 2004 04:18:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4G8m-0001Og-6q for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 04:18:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J9I8vp005368 for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 04:18:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4G8l-0001OV-Ky for ipv6-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 04:18:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23628 for ; Fri, 19 Mar 2004 04:18:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4G8i-0001pf-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 04:18:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4G7m-0001lJ-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 04:17:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4G72-0001hE-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 04:16:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4G5o-00011y-EQ; Fri, 19 Mar 2004 04:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4G4y-00010A-2G for ipv6@optimus.ietf.org; Fri, 19 Mar 2004 04:14:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23508 for ; Fri, 19 Mar 2004 04:14:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4G4v-0001ZE-00 for ipv6@ietf.org; Fri, 19 Mar 2004 04:14:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4G44-0001Ul-00 for ipv6@ietf.org; Fri, 19 Mar 2004 04:13:17 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1B4G3b-0001Ne-00 for ipv6@ietf.org; Fri, 19 Mar 2004 04:12:47 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2J9C2LF140984; Fri, 19 Mar 2004 09:12:02 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2J9C6ch258486; Fri, 19 Mar 2004 10:12:06 +0100 Received: from zurich.ibm.com (sig-9-145-224-110.de.ibm.com [9.145.224.110]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA56262; Fri, 19 Mar 2004 10:11:48 +0100 Message-ID: <405AA71B.E4EC2537@zurich.ibm.com> Date: Fri, 19 Mar 2004 08:54:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: matthew.ford@bt.com CC: pekkas@netcore.fi, rdroms@cisco.com, ipv6@ietf.org, ot@cisco.com, skylane@etri.re.kr, erik.nordmark@sun.com Subject: Re: simpler prefix delegation References: <0AAF93247C75E3408638B965DEE11A7006477E0B@i2km41-ukdy.domain1.systemhost.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit matthew.ford@bt.com wrote: > > On 18 March 2004, Pekka Savola wrote: > > On Thu, 18 Mar 2004, Ralph Droms wrote: > > > Is there interest in expending any more of the IETF's resources > > > reopening a problem for which we have rough consensus on a > > solution, > > > published specifications and running code? > > > > You say that carefully, but still giving an impression as if > > rough consensus had been gauged that only one solution would > > be specified -- otherwise there would not be "reopening" the > > problem. That has never been even raised (AFAIR); I'd > > certainly have objected. > > > > The fact that there is a solution out there, which fits the > > needs of some users, does not mean that there can not (or > > should not) be a different kind of solution which would seem > > to be much more appropriate in some other scenarios or for > > some other users. > > As I've said before in reference to the recursive name server discovery > discussion, I don't believe it benefits the network operations community > to have multiple solutions to these kind of requirements. The vendor community would probably agree. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 19 04:33:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24250 for ; Fri, 19 Mar 2004 04:33:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4GNK-0002UE-Qh for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 04:33:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J9XAgp009551 for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 04:33:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4GNK-0002Ty-5d for ipv6-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 04:33:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24212 for ; Fri, 19 Mar 2004 04:33:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4GNH-0003Dy-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 04:33:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4GMS-00038o-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 04:32:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4GLV-000340-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 04:31:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4GKJ-00023v-5L; Fri, 19 Mar 2004 04:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4GJm-00022H-VW for ipv6@optimus.ietf.org; Fri, 19 Mar 2004 04:29:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24065 for ; Fri, 19 Mar 2004 04:29:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4GJk-0002qt-00 for ipv6@ietf.org; Fri, 19 Mar 2004 04:29:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4GIj-0002jK-00 for ipv6@ietf.org; Fri, 19 Mar 2004 04:28:26 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1B4GHn-0002Ye-00 for ipv6@ietf.org; Fri, 19 Mar 2004 04:27:28 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2J9QpLF090532; Fri, 19 Mar 2004 09:26:51 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2J9Qtch280412; Fri, 19 Mar 2004 10:26:55 +0100 Received: from zurich.ibm.com (sig-9-145-224-110.de.ibm.com [9.145.224.110]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA36662; Fri, 19 Mar 2004 10:26:48 +0100 Message-ID: <405ABCF5.2002B26A@zurich.ibm.com> Date: Fri, 19 Mar 2004 10:27:17 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Bill Manning CC: Pekka Savola , Stephen Sprunk , IETF IPv6 WG Subject: Re: ASN-based prefixes for leaf ASes References: <200403181757.i2IHvVO28070@boreas.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bill, Bill Manning wrote: > > % On Wed, 17 Mar 2004, Stephen Sprunk wrote: > % > Thoughts? > % Been there, done that, gotten flamed about it :-). > > Not flamed, simply pointed out that this was the method > used and documented for preliminary IPv6 address delegations ... > before the creation of the 6bone. The expectation was/is that > the RIRs should be setting prefix delegation policies and > the IETF should work on protocols. However, that expectation applies to stable, well understood technology. It seems entirely possible that multi6 will come up with a direction that would require some new thinking, and the initial technical discussion of that would belong in the IETF (as was the case for CIDR). But that discussion doesn't belong on this list, and doesn't belong on the multi6 list either, until we have made some architectural progress there. So I think we should just leave it for now... > > % > % draft-savola-multi6-asn-pi-01.txt > % (Well, I don't like that proposition either..) > % p.s. the correct forum may be multi6. > > Actually, the correct forum would be the RIR public policy mtgs. Not yet IMHO, see above. Brian > > --bill > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 19 06:45:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27565 for ; Fri, 19 Mar 2004 06:45:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4IQd-000280-Rv for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 06:44:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JBihfm008180 for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 06:44:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4IQd-00027r-Gm for ipv6-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 06:44:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27468 for ; Fri, 19 Mar 2004 06:44:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4IQY-0007KT-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 06:44:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4IOY-0006z2-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 06:42:37 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B4IMW-0006nn-01 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 06:40:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B4IEm-0006wh-Vx for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 06:32:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4IEM-00015n-E0; Fri, 19 Mar 2004 06:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4IDi-00013f-28 for ipv6@optimus.ietf.org; Fri, 19 Mar 2004 06:31:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27072 for ; Fri, 19 Mar 2004 06:31:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4IDd-0006GS-00 for ipv6@ietf.org; Fri, 19 Mar 2004 06:31:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4ICX-00067K-00 for ipv6@ietf.org; Fri, 19 Mar 2004 06:30:12 -0500 Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx with esmtp (Exim 4.12) id 1B4IAj-0005s9-00 for ipv6@ietf.org; Fri, 19 Mar 2004 06:28:17 -0500 Received: from [IPv6:2001:690:1fff:18:20a:95ff:fef8:39f7] ([IPv6:2001:690:1fff:18:20a:95ff:fef8:39f7]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.12.11/8.12.9) with ESMTP id i2JBSC8K000098 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 19 Mar 2004 12:28:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <103ED93E-7999-11D8-A5D5-000A95B30DD4@uni-muenster.de> Content-Transfer-Encoding: quoted-printable From: Christian Strauf Subject: Re: simpler prefix delegation Date: Fri, 19 Mar 2004 12:32:11 +0100 To: ipv6@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > - implementation complexity (how many lines of code, any particularly > difficult issues, etc.) -- DHCPv6: dozens? of thousands I don't see how this has a practical impact especially in terms of=20 configuration. In all the implementations of DHCPv6 that I encountered,=20= DHCPv6 PD is trivial to set up and to maintain. Concerning RFC3315: I know people who implemented DHCPv6 and the=20 essence of what they told me about the RFC is that, though it is quite=20= a long document, it is indeed very comprehensive, sound, complete and=20 it hardly poses any open questions. > - requirements from the system (how does the mechanism interface with > the routers, access databases, etc. -- e.g., do you need to have v6 > support in RADIUS databases, do you need to have customer information > stored there, how is that communicated to the router or the DHCPv6 > server): It appears as if DHCPv6 has non-trivial set-up complexity. I disagree. Especially upcoming commercial DHCPv6 implementations will=20= have a stress on easy maintenance and interoperability with external=20 customer data sources like databases. And if this infrastructure is=20 present, I can only see advantages in the use of DHCPv6. > Well, I think we're discussing a very fundamental issue; it's IMHO > much more non-sensical to invent new protocols just because we can. True. This is why I think we should stick to DHCPv6 for PD. > the simpler setups where the complexity is unnecessary and redundant. > In such scenarios, DHCPv6 is more likely than not even used (e.g., > with IPv6-over-IPv4 configured tunnels) -- and should not be required > (IMHO, of course). As said before, DHCPv6 for PD is so trivial to configure that I don't=20 see a point in trying to cook up an "easier" solution. It is important to make sure which point of view we're talking about.=20 To a certain extent, DHCPv6 might not make sense for smaller networks=20 (maybe some 30 nodes that connect). But I have no doubt that for bigger=20= networks it definitely presents quite a benefit. So from an enterprise=20= point of view, I don't think anything else than DHCPv6 for PD makes=20 sense. On the contrary, most enterprise site will most likely deploy=20 DHCPv6 anyhow, so maintaining an additional mechanisms would create=20 administrative overhead. Christian -- JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westf=E4lische Wilhelms-Universit=E4t=20 M=FCnster http://www.join.uni-muenster.de Zentrum f=FCr Informationsverarbeitung Team: join@uni-muenster.de R=F6ntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 M=FCnster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83=20= 31653 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 19 08:13:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01857 for ; Fri, 19 Mar 2004 08:13:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JoU-0008CA-IW for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 08:13:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JDDQYW031496 for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 08:13:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JoU-0008Bv-Db for ipv6-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 08:13:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01815 for ; Fri, 19 Mar 2004 08:13:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4JoT-0006SJ-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 08:13:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4JnR-0006N4-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 08:12:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4JmZ-0006IA-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 08:11:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4JmB-0007j7-AQ; Fri, 19 Mar 2004 08:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Jll-0007ic-51 for ipv6@optimus.ietf.org; Fri, 19 Mar 2004 08:10:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01650 for ; Fri, 19 Mar 2004 08:10:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Jlk-0006CU-00 for ipv6@ietf.org; Fri, 19 Mar 2004 08:10:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4JkT-00067n-00 for ipv6@ietf.org; Fri, 19 Mar 2004 08:09:20 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B4Jjq-00063X-00 for ipv6@ietf.org; Fri, 19 Mar 2004 08:08:38 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i2JD8gmm005337 for ; Fri, 19 Mar 2004 06:08:42 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id i2JD8Zxq028550 for ; Fri, 19 Mar 2004 07:08:36 -0600 Received: from motorola.com (10.232.1.134 [10.232.1.134]) by zin05exm02.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.2) id F5D4Y13M; Fri, 19 Mar 2004 18:38:34 +0530 Message-ID: <405AF0CD.8BE5C9A0@motorola.com> Date: Fri, 19 Mar 2004 18:38:29 +0530 From: Bhaskar S Organization: Motorola India Electronics Limited X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Deletion of auto configured link local address] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Suvendu, For eg. on a CISCO router you can use the command ipv6 address link-local for configuring link-local address manually. At a time only one link-local address can be assigned to an interface. When you run this command it will overwrite the auto-generated IPv6 address. I hope this answers your question. Suvendu M wrote: > > Hi, > > I have a doubt regarding deletion of auto configured link local address. We > know that whenever a IPv6 node comes it comes up > with a link local address (addr1). Now say I manually configure another link > local address (addr2) on that interface (its possible if I am not wrong). > Now can I delete the auto configured link local address (addr1) ?? > > Regards > Suvendu. > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Thanks and Regards, Bhaskar S. Ph: +91-80-2601 4089 ************************************************** [ ] General Business Information [x] Motorola Internal Use only [ ] Motorola Confidential Proprietary POPI - A Responsibility we all share ************************************************** -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 19 09:01:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03693 for ; Fri, 19 Mar 2004 09:01:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4KYj-0002Vw-To for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 09:01:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JE1Dxe009664 for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 09:01:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4KYj-0002Vn-PF for ipv6-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 09:01:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03656 for ; Fri, 19 Mar 2004 09:01:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4KYi-0002YJ-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 09:01:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4KXj-0002SY-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 09:00:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4KWl-0002NQ-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 08:59:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4KWc-0002B8-9j; Fri, 19 Mar 2004 08:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4KWX-0002Ag-Ot for ipv6@optimus.ietf.org; Fri, 19 Mar 2004 08:58:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03591 for ; Fri, 19 Mar 2004 08:58:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4KWW-0002Ke-00 for ipv6@ietf.org; Fri, 19 Mar 2004 08:58:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4KVY-0002FX-00 for ipv6@ietf.org; Fri, 19 Mar 2004 08:57:59 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1B4KUe-0002AI-00 for ipv6@ietf.org; Fri, 19 Mar 2004 08:57:00 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:1cd:a55e:4cad:fa70]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 025621521B; Fri, 19 Mar 2004 22:56:53 +0900 (JST) Date: Fri, 19 Mar 2004 22:56:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: Brian Haberman , ipv6@ietf.org Subject: Re: Adopt Address Selection API as a WG document? In-Reply-To: <200403020520.i225KmSj056723@givry.rennes.enst-bretagne.fr> 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Tue, 02 Mar 2004 06:20:48 +0100, >>>>> Francis Dupont said: > The address selection draft authors have asked the WG to adopt > draft-chakrabarti-ipv6-addrselect-api-02.txt as a WG document. Are > there any objections to the group adopting it? As with other API > documents, this would be Informational in nature. > => I have no objection but I have a concern: as I don't expect to > see all applications changed to handle this I am really afraid that > this draft doesn't address the right problem... I agree with Francis here. I won't go into further details, since it would simply be the same discussion I made on this before. (note that I'm not necessarily objecting to making it as a wg document.) 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 exim@www1.ietf.org Fri Mar 19 09:42:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05321 for ; Fri, 19 Mar 2004 09:42:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LCT-0005YP-Bt for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 09:42:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JEgHKa021343 for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 09:42:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LCT-0005YA-5s for ipv6-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 09:42:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05290 for ; Fri, 19 Mar 2004 09:42:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4LCR-00064Q-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 09:42:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4LBc-0005yv-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 09:41:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4LAb-0005sd-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 09:40:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LAK-0005Cz-7s; Fri, 19 Mar 2004 09:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4LAB-0005CF-0y for ipv6@optimus.ietf.org; Fri, 19 Mar 2004 09:39:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05106 for ; Fri, 19 Mar 2004 09:39:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4LA9-0005oX-00 for ipv6@ietf.org; Fri, 19 Mar 2004 09:39:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4L8k-0005j7-00 for ipv6@ietf.org; Fri, 19 Mar 2004 09:38:29 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1B4L8C-0005fK-00 for ipv6@ietf.org; Fri, 19 Mar 2004 09:37:53 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:1cd:a55e:4cad:fa70]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2792615210; Fri, 19 Mar 2004 23:37:52 +0900 (JST) Date: Fri, 19 Mar 2004 23:37:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Suresh Krishnan Cc: Mukesh.Gupta@nokia.com, jari.arkko@kolumbus.fi, , , Subject: Re: ICMPv6 echo reply to multicast packet thread In-Reply-To: References: <7B2A7784F4B7F0409947481F3F3FEF830D8F6B96@eammlex037.lmc.ericsson.se> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Thu, 11 Mar 2004 23:53:05 -0500 (EST), >>>>> Suresh Krishnan said: >> Now, who can tell if multicast echo request is the primary >> multicast debugging mechanism or not ?? > Since there is no alternate mechanism, this has become the primary and > preferred multicast debugging mechanism. If some mechanism is proposed > which is better and is less liable to be misused, it will become the > primary mechanism. The KAME project was working on a multicast traceroute > tool for IPv6 a while ago. I have not personally used it. Probably > Jinmei can comment further on this. Our experimental implementation of multicast traceroute for IPv6 is described in a paper available at the following URL: http://www.isoc.org/isoc/conferences/inet/00/cdproceedings/1c/1c_2.htm But in any event, I don't think it helps this particular discussion. It's just experimental, and I've even never written an I-D on this (partly because the standardization of IPv4 multicast traceroute has been pending). For the original discussion, I agree with Pekka; I prefer to (continue to) allow responding to multicasted echo requests by default, for almost the same reasons he provided. 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 exim@www1.ietf.org Fri Mar 19 11:12:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09689 for ; Fri, 19 Mar 2004 11:12:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Maw-0000wZ-UK for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 11:12:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JGBSoR003613 for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 11:11:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Mag-0000vy-4k for ipv6-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 11:11:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09614 for ; Fri, 19 Mar 2004 11:11:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4MaY-0005ep-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 11:11:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4MZa-0005aL-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 11:10:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4MYx-0005WY-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 11:09:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MYP-0000Yd-PW; Fri, 19 Mar 2004 11:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MXh-0000Xe-I6 for ipv6@optimus.ietf.org; Fri, 19 Mar 2004 11:08:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09545 for ; Fri, 19 Mar 2004 11:08:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4MXe-0005Rj-00 for ipv6@ietf.org; Fri, 19 Mar 2004 11:08:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4MWi-0005Nz-00 for ipv6@ietf.org; Fri, 19 Mar 2004 11:07:16 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1B4MWV-0005Jf-00 for ipv6@ietf.org; Fri, 19 Mar 2004 11:07:03 -0500 Received: from eamrcnt716.exu.ericsson.se (eamrcnt716.exu.ericsson.se [138.85.90.247]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i2JG6QLc006587 for ; Fri, 19 Mar 2004 10:06:26 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt716.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 Mar 2004 10:04:24 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Mar 2004 10:06:30 -0600 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GPWX12H4; Fri, 19 Mar 2004 11:06:28 -0500 Date: Fri, 19 Mar 2004 11:05:26 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: Suvendu M cc: ipv6@ietf.org Subject: Re: Deletion of auto configured link local address In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF830D8F6BD8@eammlex037.lmc.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 19 Mar 2004 16:04:24.0953 (UTC) FILETIME=[D95D9E90:01C40DCB] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Hi Suvendu, See comments inline. Regards Suresh On Fri, 19 Mar 2004, Suvendu M wrote: >Hi, > >I have a doubt regarding deletion of auto configured link local address. We >know that whenever a IPv6 node comes it comes up >with a link local address (addr1). Now say I manually configure another link >local address (addr2) on that interface (its possible if I am not wrong). It is certainly possible but it is not required to be possible. The standards require an interface to have AT LEAST one link local address and having just one satisfies that requirement. There are some platforms such as IOS which will allow you to have only one link local. >Now can I delete the auto configured link local address (addr1) ?? Yes. How you do it depends on your platform. Let's say you were using linux you could use the following commands #ifconfig add #ifconfig del to accomplish what you wanted. > >Regards >Suvendu. > > > >*************************************************************************** >This message is proprietary to Future Software Limited (FSL) >and is intended solely for the use of the individual to whom it >is addressed. It may contain privileged or confidential information >and should not be circulated or used for any purpose other than for >what it is intended. > >If you have received this message in error, please notify the >originator immediately. If you are not the intended recipient, >you are notified that you are strictly prohibited from using, >copying, altering, or disclosing the contents of this message. >FSL accepts no responsibility for loss or damage arising from >the use of the information transmitted by this email including >damage from virus. >*************************************************************************** > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 19 11:20:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10038 for ; Fri, 19 Mar 2004 11:20:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MjC-0001UL-HN for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 11:20:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JGKAfC005721 for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 11:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MjB-0001U1-Uw for ipv6-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 11:20:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09986 for ; Fri, 19 Mar 2004 11:20:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4MjB-0006Ua-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 11:20:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4MiD-0006Nl-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 11:19:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4MhL-0006Gj-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 11:18:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Mh7-000180-Oj; Fri, 19 Mar 2004 11:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4MgM-00015y-J5 for ipv6@optimus.ietf.org; Fri, 19 Mar 2004 11:17:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09860 for ; Fri, 19 Mar 2004 11:17:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4MgL-0006AY-00 for ipv6@ietf.org; Fri, 19 Mar 2004 11:17:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4MfN-00063S-00 for ipv6@ietf.org; Fri, 19 Mar 2004 11:16:13 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1B4Mdg-0005xX-00 for ipv6@ietf.org; Fri, 19 Mar 2004 11:14:28 -0500 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2+0917/8.11.2) id i2JGCnp13620; Fri, 19 Mar 2004 08:12:49 -0800 (PST) From: Bill Manning Message-Id: <200403191612.i2JGCnp13620@boreas.isi.edu> Subject: Re: ASN-based prefixes for leaf ASes To: brc@zurich.ibm.com (Brian E Carpenter) Date: Fri, 19 Mar 2004 08:12:49 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), pekkas@netcore.fi (Pekka Savola), stephen@sprunk.org (Stephen Sprunk), ipv6@ietf.org (IETF IPv6 WG), ppml@arin.net In-Reply-To: <405ABCF5.2002B26A@zurich.ibm.com> from "Brian E Carpenter" at Mar 19, 2004 10:27:17 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ISI-4.27.7-MailScanner: Found to be clean X-MailScanner-From: bmanning Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit % > ... simply pointed out that this was the method % > used and documented for preliminary IPv6 address delegations ... % > before the creation of the 6bone. The expectation was/is that % > the RIRs should be setting prefix delegation policies and % > the IETF should work on protocols. % % However, that expectation applies to stable, well understood technology. % It seems entirely possible that multi6 will come up with a direction % that would require some new thinking, and the initial technical discussion % of that would belong in the IETF (as was the case for CIDR). But that % discussion doesn't belong on this list, and doesn't belong on the % multi6 list either, until we have made some architectural progress there. % So I think we should just leave it for now... sure, fine. Just pointing out the ASN based, prefix assignment hack is -very- old and has been abandoned by the IETF in favor of the processes we currently use. % > % draft-savola-multi6-asn-pi-01.txt % > % (Well, I don't like that proposition either..) % > % p.s. the correct forum may be multi6. % > % > Actually, the correct forum would be the RIR public policy mtgs. % % Not yet IMHO, see above. actually, I think it is imprudent to not include the RIR public policy fourm in any discussions on new address assignment plans. YMMV of course. % Brian % > --bill % Brian E Carpenter % Distinguished Engineer, Internet Standards & Technology, IBM --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 19 16:11:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23028 for ; Fri, 19 Mar 2004 16:11:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RGz-0008SS-Vi for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 16:11:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JLBLkP032506 for ipv6-archive@odin.ietf.org; Fri, 19 Mar 2004 16:11:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RGz-0008SD-Rg for ipv6-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 16:11:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22993 for ; Fri, 19 Mar 2004 16:11:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4RGy-00026U-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 16:11:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4RFz-00020Z-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 16:10:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4RF7-0001uc-00 for ipv6-web-archive@ietf.org; Fri, 19 Mar 2004 16:09:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RDn-0007sM-68; Fri, 19 Mar 2004 16:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RCt-0007bf-Ku for ipv6@optimus.ietf.org; Fri, 19 Mar 2004 16:07:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22697; Fri, 19 Mar 2004 16:07:04 -0500 (EST) Message-Id: <200403192107.QAA22697@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-prefix-delegation-requirement-04.txt Date: Fri, 19 Mar 2004 16:07:04 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Requirements for IPv6 prefix delegation Author(s) : S. Miyakawa, R. Droms Filename : draft-ietf-ipv6-prefix-delegation-requirement-04.txt Pages : 7 Date : 2004-3-18 This document describes requirements about how an IPv6 address prefix should be delegated to an IPv6 subscriber's network (or 'site'). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-prefix-delegation-requirement-04.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-prefix-delegation-requirement-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-18153508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-prefix-delegation-requirement-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-18153508.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Mar 20 00:41:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13692 for ; Sat, 20 Mar 2004 00:41:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ZDq-000196-RH for ipv6-archive@odin.ietf.org; Sat, 20 Mar 2004 00:40:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K5ecDm004401 for ipv6-archive@odin.ietf.org; Sat, 20 Mar 2004 00:40:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ZDq-00018u-AA for ipv6-web-archive@optimus.ietf.org; Sat, 20 Mar 2004 00:40:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13654 for ; Sat, 20 Mar 2004 00:40:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4ZDn-0005NW-00 for ipv6-web-archive@ietf.org; Sat, 20 Mar 2004 00:40:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4ZCp-0005HO-00 for ipv6-web-archive@ietf.org; Sat, 20 Mar 2004 00:39:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4ZBt-0005B3-00 for ipv6-web-archive@ietf.org; Sat, 20 Mar 2004 00:38:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ZBJ-0000nC-R5; Sat, 20 Mar 2004 00:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ZAx-0000gY-DE for ipv6@optimus.ietf.org; Sat, 20 Mar 2004 00:37:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13552 for ; Sat, 20 Mar 2004 00:37:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4ZAu-00054o-00 for ipv6@ietf.org; Sat, 20 Mar 2004 00:37:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4ZA6-0004z5-00 for ipv6@ietf.org; Sat, 20 Mar 2004 00:36:47 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1B4Z9G-0004mv-00 for ipv6@ietf.org; Sat, 20 Mar 2004 00:35:55 -0500 Received: from skylane1 (6ants6.etri.re.kr [129.254.112.240]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id G9YF1CRK; Sat, 20 Mar 2004 14:34:36 +0900 From: "Byung-Yeob Kim" To: "'Brian E Carpenter'" , Cc: , , , , , , "autonet" Subject: RE: simpler prefix delegation Date: Sat, 20 Mar 2004 14:35:21 +0900 Message-ID: <006201c40e3d$23096a30$f070fe81@skylane1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal In-Reply-To: <405AA71B.E4EC2537@zurich.ibm.com> Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Reaching rough consensus? As all of us might know, alternatives to DHCP have always been controversial. Even I admit that DHCPv6 looks good for hierarchical prefix delegation and it is hard to find HDCP-less place, even though some of my colleagues are still frenzy about 1894 Ubiquitous something that includes multiple-level DHCP-LESS routers on Big brother's clothing :) Also I tend to disagree with that 120 pages are too heavy to be implemented. However IMHO, combing with existing stateless auto-configuration, prefix delegation has room for simplification and I don't want to call it a new protocol nor reinventing DHCPv6, rather I'd call it an extension to an existing (say, ICMP or stateless auto-conf you name it.) I thank you for invaluable comments on the draft, especially Pekka Savola and Laurent Cl=E9vy. Opinions will be taken into consideration = on the next draft. If there's anybody want to collaborate please let me know. Weekend! It's a great day for flying, Bob (Byung-yeob) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sat Mar 20 03:50:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02437 for ; Sat, 20 Mar 2004 03:50:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4cAx-0006HM-5F for ipv6-archive@odin.ietf.org; Sat, 20 Mar 2004 03:49:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K8npkM024130 for ipv6-archive@odin.ietf.org; Sat, 20 Mar 2004 03:49:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4cAw-0006H7-Gs for ipv6-web-archive@optimus.ietf.org; Sat, 20 Mar 2004 03:49:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02428 for ; Sat, 20 Mar 2004 03:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4cAu-0000a3-00 for ipv6-web-archive@ietf.org; Sat, 20 Mar 2004 03:49:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4cA3-0000Ud-00 for ipv6-web-archive@ietf.org; Sat, 20 Mar 2004 03:48:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4c9X-0000Ob-00 for ipv6-web-archive@ietf.org; Sat, 20 Mar 2004 03:48:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4c8F-0005oY-2N; Sat, 20 Mar 2004 03:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4c7u-0005ni-GH for ipv6@optimus.ietf.org; Sat, 20 Mar 2004 03:46:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02268 for ; Sat, 20 Mar 2004 03:46:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4c7s-0000Fo-00 for ipv6@ietf.org; Sat, 20 Mar 2004 03:46:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4c6x-0000BI-00 for ipv6@ietf.org; Sat, 20 Mar 2004 03:45:43 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4c6E-00001P-00 for ipv6@ietf.org; Sat, 20 Mar 2004 03:44:58 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2K8iHU03646; Sat, 20 Mar 2004 10:44:17 +0200 Date: Sat, 20 Mar 2004 10:44:17 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: matthew.ford@bt.com, , , , , Subject: Re: simpler prefix delegation In-Reply-To: <405AA71B.E4EC2537@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 19 Mar 2004, Brian E Carpenter wrote: > > As I've said before in reference to the recursive name server discovery > > discussion, I don't believe it benefits the network operations community > > to have multiple solutions to these kind of requirements. > > The vendor community would probably agree. Probably, except for those vendors who would rather not want to be required to implement DHCPv6 for tasks {Foo, Bar, ....}. The question is really whether DHCPv6 is a feasible requirement in *every* scenario where you'd desire prefix delegation, [DNS discovery], and [whatnot]. If there is consensus that the answer is "yes", we can focus the energies elsewhere. But I do not think there is such concensus (even a rough one; even if it might help). -- 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 exim@www1.ietf.org Sun Mar 21 00:27:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12829 for ; Sun, 21 Mar 2004 00:27:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4vUi-0007m2-61 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 00:27:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2L5RWrb029879 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 00:27:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4vUh-0007lq-Mu for ipv6-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 00:27:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12813 for ; Sun, 21 Mar 2004 00:27:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4vUf-0002dF-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 00:27:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4vTs-0002Vk-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 00:26:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4vT0-0002Lz-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 00:25:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4vRT-0006qK-FN; Sun, 21 Mar 2004 00:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4v6z-00052u-9B for ipv6@optimus.ietf.org; Sun, 21 Mar 2004 00:03:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11527 for ; Sun, 21 Mar 2004 00:02:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4v6w-0007Bf-00 for ipv6@ietf.org; Sun, 21 Mar 2004 00:02:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4v6E-000760-00 for ipv6@ietf.org; Sun, 21 Mar 2004 00:02:15 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1B4v4n-0006pe-00 for ipv6@ietf.org; Sun, 21 Mar 2004 00:00:45 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id EBE0F3DA for ; Sun, 21 Mar 2004 00:00:15 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 21 Mar 2004 00:00:15 -0500 Message-Id: <20040321050016.EBE0F3DA@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.07% | 9 | 15.09% | 47703 | pekkas@netcore.fi 8.93% | 5 | 8.50% | 26864 | stephen@sprunk.org 7.14% | 4 | 8.21% | 25960 | brc@zurich.ibm.com 3.57% | 2 | 7.24% | 22885 | margaret@thingmagic.com 5.36% | 3 | 5.35% | 16925 | pthubert@cisco.com 5.36% | 3 | 4.31% | 13626 | alain.durand@sun.com 5.36% | 3 | 4.26% | 13484 | jinmei@isl.rdc.toshiba.co.jp 3.57% | 2 | 4.01% | 12690 | rdroms@cisco.com 3.57% | 2 | 3.76% | 11898 | mark_andrews@isc.org 3.57% | 2 | 3.43% | 10838 | internet-drafts@ietf.org 3.57% | 2 | 2.97% | 9382 | ot@cisco.com 3.57% | 2 | 2.66% | 8404 | bmanning@isi.edu 1.79% | 1 | 4.07% | 12880 | laurent.clevy@alcatel.fr 1.79% | 1 | 2.71% | 8581 | david.binet@francetelecom.com 1.79% | 1 | 2.00% | 6312 | suresh.krishnan@ericsson.ca 1.79% | 1 | 1.92% | 6065 | ipng@uni-muenster.de 1.79% | 1 | 1.89% | 5989 | varada@txc.com 1.79% | 1 | 1.82% | 5767 | huitema@windows.microsoft.com 1.79% | 1 | 1.72% | 5430 | bhaskar.s@motorola.com 1.79% | 1 | 1.63% | 5147 | ignatios@cs.uni-bonn.de 1.79% | 1 | 1.57% | 4977 | sra+ipng@hactrn.net 1.79% | 1 | 1.57% | 4963 | osprey67@yahoo.com 1.79% | 1 | 1.47% | 4641 | miyakawa@nttv6.jp 1.79% | 1 | 1.41% | 4473 | suvendum@future.futsoft.com 1.79% | 1 | 1.40% | 4441 | matthew.ford@bt.com 1.79% | 1 | 1.36% | 4290 | h.soliman@flarion.com 1.79% | 1 | 1.33% | 4192 | skylane@etri.re.kr 1.79% | 1 | 1.23% | 3891 | sra@isc.org 1.79% | 1 | 1.12% | 3529 | zefram@fysh.org --------+------+--------+----------+------------------------ 100.00% | 56 |100.00% | 316227 | 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 exim@www1.ietf.org Sun Mar 21 07:32:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08846 for ; Sun, 21 Mar 2004 07:32:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B527H-0008Vt-6l for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 07:31:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LCVlN6032725 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 07:31:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B527G-0008Vk-Ub for ipv6-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 07:31:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08837 for ; Sun, 21 Mar 2004 07:31:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B527G-0007Nb-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 07:31:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B526d-0007Hi-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 07:31:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5263-00079G-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 07:30:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B525b-0008AU-SM; Sun, 21 Mar 2004 07:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B525S-00089r-4J for ipv6@optimus.ietf.org; Sun, 21 Mar 2004 07:29:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08695 for ; Sun, 21 Mar 2004 07:29:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B525R-00075O-00 for ipv6@ietf.org; Sun, 21 Mar 2004 07:29:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B524U-0006yI-00 for ipv6@ietf.org; Sun, 21 Mar 2004 07:28:54 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B523x-0006pW-00 for ipv6@ietf.org; Sun, 21 Mar 2004 07:28:21 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2004 04:33:27 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2LCRmK2006339 for ; Sun, 21 Mar 2004 04:27:49 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-39.cisco.com [10.86.242.39]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY76596; Sun, 21 Mar 2004 07:27:47 -0500 (EST) Message-Id: <4.3.2.7.2.20040321071819.02964150@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 21 Mar 2004 07:27:45 -0500 To: ipv6@ietf.org From: Ralph Droms Subject: Re: simpler prefix delegation In-Reply-To: References: <7t5brmus1r5.fsf@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 04:24 PM 3/18/2004 +0200, Pekka Savola wrote: >On Thu, 18 Mar 2004, Ole Troan wrote: > > >> Haberman's ICMP prefix delegation draft initiated the IPv6 W.G's work > > >> on prefix delegation. it pretty soon became clear that we were > > >> reinventing DHCP, so instead of developing a new DHCP lookalike, we > > >> decided to reuse the existing DHCP infrastructure instead. > > > > > > That was probably based on the premise that it would have had to > > > re-implement everything that DHCP could provide. I don't make that > > > assumption. > > > > no, it was made on the assumption that the protocol would have to > > fulfill the requirements as stated in the requirements document. > >What I proposed does this; let's see: Let's be clear: Ole did not say anything about whether your proposal does or does not meet the requirements in draft-ietf-ipv6-prefix-delegation-requirement-04.txt. Ole stated that RFC3633 meets those requirements, which it does without requiring that a PD delegating router "re-implement everything that DHCP could provide". - Ralph >[snip] > > can you please specify exactly what you want to simplify? it is hard > > to argue against vague statements like 'complex' and 'heavyweight'... > >I want to simplify the protocol, for the protocol to be simple and >easy to understand, and trivial to implement. DHCPv6 PD spec is about >20 pages long; that is one primer: the whole protocol should be no >longer than that. > >Of course, all of this is a moot point if the consensus is that full >DHCPv6 must be implemented by every box (especially if it could be >used as a router); but I don't think such exists. For clarity, no one has stated (or even suggested) that "DHCPv6 must be implemented by every box". If a vendor wants to make PD available in a product, the vendor implements DHCPv6 PD. If a vendor doesn't think PD will be a selling point in a product, the vendor is free not to implement it. Why would DHCPv6 PD be any different from any other IETF protocol? - Ralph >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Mar 21 10:03:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13807 for ; Sun, 21 Mar 2004 10:03:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B54TV-0001jz-31 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 10:02:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LF2rvk006680 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 10:02:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B54TU-0001ja-TS for ipv6-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 10:02:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13775 for ; Sun, 21 Mar 2004 10:02:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B54TS-0000IJ-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 10:02:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B54SV-0000Bm-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 10:01:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B54SA-00005g-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 10:01:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B54Rj-0008KT-3I; Sun, 21 Mar 2004 10:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B54RO-00084f-K8 for ipv6@optimus.ietf.org; Sun, 21 Mar 2004 10:00:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13692 for ; Sun, 21 Mar 2004 10:00:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B54RM-00002m-00 for ipv6@ietf.org; Sun, 21 Mar 2004 10:00:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B54QQ-0007lT-00 for ipv6@ietf.org; Sun, 21 Mar 2004 09:59:42 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B54Pi-0007c5-00 for ipv6@ietf.org; Sun, 21 Mar 2004 09:58:59 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2LEwHx32208; Sun, 21 Mar 2004 16:58:18 +0200 Date: Sun, 21 Mar 2004 16:58:17 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: ipv6@ietf.org Subject: Re: simpler prefix delegation In-Reply-To: <4.3.2.7.2.20040321071819.02964150@flask.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Sun, 21 Mar 2004, Ralph Droms wrote: > Let's be clear: Ole did not say anything about whether your proposal does or > does not meet the requirements in > draft-ietf-ipv6-prefix-delegation-requirement-04.txt. Right; I noticed this. > Ole stated that > RFC3633 meets those requirements, which it does without requiring that a PD > delegating router "re-implement everything that DHCP could provide". My point was that DHCP also provides N++ other features which are completely unnecessary. The proposal was specificatlly *not* to re-implement everything DHCP is providing. > For clarity, no one has stated (or even suggested) that "DHCPv6 must be > implemented by every box". Obviously -- but looking at the arguments made at different fora, this is more or less the road we're treading. Basically all CPE-grade routers (or nodes which could be used as such, including also most host sytems) need to be able to the receiving end of PD. Include the DNS resolver etc. discovery requirements on the mix and you're pretty close to "implement in every box". > If a vendor wants to make PD available in a product, the vendor > implements DHCPv6 PD. You're equating "vendor wants to provide PD" with "vendor wants to provide PD with DHCPv6". -- 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 exim@www1.ietf.org Sun Mar 21 10:35:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16027 for ; Sun, 21 Mar 2004 10:35:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B54yT-0007kD-MZ for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 10:34:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LFYri4029769 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 10:34:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B54yT-0007k4-5F for ipv6-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 10:34:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15976 for ; Sun, 21 Mar 2004 10:34:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B54yQ-0003ix-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 10:34:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B54xR-0003ci-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 10:33:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B54wp-0003X6-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 10:33:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B54wf-0007KQ-VS; Sun, 21 Mar 2004 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B54wU-0007Jm-VD for ipv6@optimus.ietf.org; Sun, 21 Mar 2004 10:32:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15894 for ; Sun, 21 Mar 2004 10:32:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B54wS-0003WW-00 for ipv6@ietf.org; Sun, 21 Mar 2004 10:32:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B54vY-0003Qw-00 for ipv6@ietf.org; Sun, 21 Mar 2004 10:31:53 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B54v7-0003Ku-00 for ipv6@ietf.org; Sun, 21 Mar 2004 10:31:25 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2004 07:37:04 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2LFUNiZ019384; Sun, 21 Mar 2004 16:30:23 +0100 (MET) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA25104; Sun, 21 Mar 2004 15:30:16 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Cc: Ralph Droms , ipv6@ietf.org Subject: Re: simpler prefix delegation References: From: Ole Troan Date: Sun, 21 Mar 2004 15:30:16 +0000 In-Reply-To: (Pekka Savola's message of "Sun, 21 Mar 2004 16:58:17 +0200 (EET)") Message-ID: <7t5vfkykyk7.fsf@mrwint.cisco.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Pekka, >> Ole stated that RFC3633 meets those requirements, which it does >> without requiring that a PD delegating router "re-implement >> everything that DHCP could provide". > > My point was that DHCP also provides N++ other features which are > completely unnecessary. The proposal was specificatlly *not* to > re-implement everything DHCP is providing. I'm not sure I understand where you're coming from. if you only want to do DHCP PD, then you don't need to implement all those 'completely unnecessary' features. the amount of work required to implement PD using a DHCP based protocol engine versus an ICMP based protocol engine is similar. the benefit of reusing DHCP (ignoring the fact that its already an RFC and has numerous implementation) is that the cost of implementing and deploying all the N++ features (DNS, address assignment, SIP, ...) is much lower. it sounds to me like the motivation here is to avoid DHCP at all cost. I'm certainly not a big fan of DHCP, but I'm pragmatic enough to see that reinventing DHCP just to get a different acronym isn't worth it. /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Mar 21 15:17:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28337 for ; Sun, 21 Mar 2004 15:17:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B59NQ-0004Tm-WB for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 15:16:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LKGur1017212 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 15:16:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B59NQ-0004TX-Pw for ipv6-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 15:16:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28277 for ; Sun, 21 Mar 2004 15:16:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B59NP-0004KO-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 15:16:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B59MO-0004EU-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 15:15:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B59LV-00049r-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 15:14:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B59Kb-0003Vy-HS; Sun, 21 Mar 2004 15:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B59KR-0003QU-KW for ipv6@optimus.ietf.org; Sun, 21 Mar 2004 15:13:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27987 for ; Sun, 21 Mar 2004 15:13:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B59KQ-00044Q-00 for ipv6@ietf.org; Sun, 21 Mar 2004 15:13:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B59JY-00040A-00 for ipv6@ietf.org; Sun, 21 Mar 2004 15:12:57 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1B59J2-0003uH-00 for ipv6@ietf.org; Sun, 21 Mar 2004 15:12:24 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Sun, 21 Mar 2004 12:11:50 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Mar 2004 12:11:53 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 21 Mar 2004 12:11:30 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 21 Mar 2004 12:11:50 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 21 Mar 2004 12:11:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: simpler prefix delegation Date: Sun, 21 Mar 2004 12:11:50 -0800 Message-ID: Thread-Topic: simpler prefix delegation thread-index: AcQPWiHvpkLAan66QpSRBaKMhhrFXQAHCysw From: "Christian Huitema" To: "Ole Troan" , "Pekka Savola" Cc: "Ralph Droms" , X-OriginalArrivalTime: 21 Mar 2004 20:11:51.0762 (UTC) FILETIME=[BF946320:01C40F80] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > the amount of work required to implement PD using a DHCP based > protocol engine versus an ICMP based protocol engine is similar. the > benefit of reusing DHCP (ignoring the fact that its already an RFC and > has numerous implementation) is that the cost of implementing and > deploying all the N++ features (DNS, address assignment, SIP, ...) is > much lower. There are many practical issue with using DHCPV6 for prefix delegation.=20 In many cases, the source of the prefix delegation is not the same as the source of other configuration parameters. If you read the RFC, you have the distinct feeling that one should discover the PD server independently of the other DHCP services. There are good reasons for these being independent: most of the other parameters are essentially stateless, copied from some configuration database, while PD is stateful, possibly made up on the fly by the router managing a subnet. Trying to shove independent assignments into a single provisioning system is bound to cause operational problems. Another practical issue arises when the prefix delegation server is more than one hop away from the router requesting an assignment. The DHCP discovery process relies on a structure of proxies, but there is no guarantee that the proxies will end up sending the request to the desired server. That also will cause operational problems. > it sounds to me like the motivation here is to avoid DHCP at all > cost. I'm certainly not a big fan of DHCP, but I'm pragmatic enough to > see that reinventing DHCP just to get a different acronym isn't worth > it. If we were just speaking about packet encoding, I might agree with you. However, we also have to consider operational issues. For example, the RA based assignment of addresses is vastly more reliable than a DHCP based system, because it only includes 2 parties: host and router; DHCP requires in addition a proxy and a server, and often a network configuration database. We have all witnessed the results: during the typical snafu on the IETF network, IPv6 is up and running because of automatic address configuration, while IPv4 is struggling with a congested DHCP server. So, yes, there is a desire to solve reliability issues that are inherent with the use of DHCP. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Mar 21 16:08:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00505 for ; Sun, 21 Mar 2004 16:08:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5AAt-0001BH-Fx for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 16:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LL83Uk004530 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 16:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5AAs-0001AR-Mh for ipv6-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 16:08:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00330 for ; Sun, 21 Mar 2004 16:08:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5AAq-0003PA-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 16:08:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5A76-0002an-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 16:04:09 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5A5r-0002OU-02 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 16:02:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B59zn-0007iJ-6V for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 15:56:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B59zG-0000IO-B6; Sun, 21 Mar 2004 15:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B59yE-0000GR-AH for ipv6@optimus.ietf.org; Sun, 21 Mar 2004 15:54:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00004 for ; Sun, 21 Mar 2004 15:54:49 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B59y6-0001nm-00 for ipv6@ietf.org; Sun, 21 Mar 2004 15:54:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B59xG-0001k0-00 for ipv6@ietf.org; Sun, 21 Mar 2004 15:53:59 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1B59wn-0001fv-00 for ipv6@ietf.org; Sun, 21 Mar 2004 15:53:29 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2LKrF414921; Sun, 21 Mar 2004 22:53:15 +0200 (EET) X-Scanned: Sun, 21 Mar 2004 22:53:08 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i2LKr8M1021488; Sun, 21 Mar 2004 22:53:08 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00gCFJYr; Sun, 21 Mar 2004 22:53:07 EET 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 i2LKr6F06703; Sun, 21 Mar 2004 22:53:06 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 21 Mar 2004 12:53:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: icmpv6-v3 comments Date: Sun, 21 Mar 2004 14:53:05 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA4015473F9@daebe009.americas.nokia.com> Thread-Topic: icmpv6-v3 comments Thread-Index: AcP+i7TUY7TYxbVrQ2ycow29METNKAIrs1Ow To: , X-OriginalArrivalTime: 21 Mar 2004 20:53:06.0246 (UTC) FILETIME=[827CAE60:01C40F86] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka, Sorry that I am replying to this mail so late ! and Thanks for reviewing the draft thoroughly. Please see my comments inline.. > Process issue: Draft Standard may not refer normatively to > specifications of lower standardization status. See > draft-ymbk-downref-01.txt for a bit of discussion. That is, > IPv6-ADDR, PMTU and IPsec documents are unsuitable for normative > references. So, some wiggling around will be needed.. Well, the draft draft-ymbk-downref-01.txt says=20 =3D=3D=3D=3D In the case of protocols, a reference is normative if it refers to packet formats or other protocol mechanisms that are needed to fully implement the protocol in the current specification. For example, if a protocol relies on IPsec to provide security, one cannot fully implement the protocol without the specification for IPsec also being available; hence, the reference would be normative. =3D=3D=3D=3D As ICMPv6 proposes to use IPsec for security, according to the above paragraph, IPsec documents should be normative. So how do we resolve this ? > =3D=3D> should add IPR and copyright boilerplates at the end. Will do in the next draft. > 2.2 Message Source Address Determination >=20 > A node that sends an ICMPv6 message has to determine both=20 > the Source > and Destination IPv6 Addresses in the IPv6 header before=20 > calculating > the checksum. If the node has more than one unicast=20 > address, it must > choose the Source Address of the message as follows: > [...] >=20 > =3D=3D> should this "must" (and the following statements) be = appropriately > uppercased? Yeah, I think so. Will take care of this in the next draft too. > (c) If the message is a response to a message sent to an address > that does not belong to the node, the Source Address should be > that unicast address belonging to the node that will be most > helpful in diagnosing the error. For example, if the message = is > a response to a packet forwarding action that cannot complete > successfully, the Source Address should be a unicast address > belonging to the interface on which the packet forwarding > failed. >=20 > =3D=3D> not sure if this has been implemented, so the usability=20 > of this generic rule seems questionable. Are you proposing to remove this ? =20 I think, all the implementations use the IP address of the egress=20 interface for the ICMP packet as the source address of the packet. The above paragraph suggests to use the IP address of the interface on which the packet was supposed to be forwarded. Now if we are=20 unable to forward the packet, how would we know which interface it was supposed to go out on :-/ So which IP address should be used in that case ! >=20 > (c) Every ICMPv6 error message (type < 128) includes as much of = the > IPv6 offending (invoking) packet (the packet that caused the =20 > error) as will fit without making the error message packet =20 > exceed the minimum IPv6 MTU [IPv6]. >=20 > =3D=3D> s/includes/MUST include/ ? Will correct this.. > If the reason for the failure to deliver can not be mapped=20 > to any of > the specific codes listed above, the Code field is set to 3. The > example of such cases are inability to resolve the IPv6 destination > address into a corresponding link address, or a=20 > link-specific problem > of some sort. >=20 > =3D=3D> reasons with codes 4, 5, and 6 are below this sentence. =20 > Maybe those > paragraphs should be moved up, earlier in this section, or=20 > the language here > reworded? Actually, I wanted to keep the description of the codes in the numerical order. If this description sounds confusing, could you suggest how to=20 re-word it such that it is clearer without moving the descriptions of=20 4, 5 and 6 before this ? > If the reason for the failure to deliver is that packet with this > source address is not allowed due to ingress or egress filtering > policies, the Code field is set to 5. >=20 > If the reason for the failure to deliver is that the route to the > destination is a reject route, the Code field is set to 6. This = may > occur if the router has been configured to reject all the traffic = for > a specific prefix. >=20 > =3D=3D> as has already been mentioned, these two rules are in fact a = more > specific, more informative subsets of code 1 --=20 > administratively prohibited.=20 > I persnally don't see much of an objection for adding these=20 > codes, but it > would IMHO make useful to spell this out explicitly here. Would it help to add the following text: =3D=3D=3D=3D Codes 5 and 6 are more informative subsets of code 1. Thus code 1 MAY be used in place of code 5 and 6. =3D=3D=3D=3D > It SHOULD be possible for the system administrator to configure a > node to ignore any ICMP messages that are not authenticated using > either the Authentication Header or Encapsulating Security Payload. > Such a switch SHOULD default to allowing unauthenticated messages. >=20 > =3D=3D> has this even been implemented anywhere? could maybe be=20 > deleted? This is completely unpractical, e.g., just consider=20 > PMTU packets -- there is no way you'll ever be able to set=20 > up security associations with everyone in the Internet to be=20 > able to accept the packets :) I completely agree with you that this is unpractical but it does make sense to a completely paranoid administrator. Whoever turns this option ON might not be interested in using PMTU. I don't see any harm in keeping it. We can make it a MAY from SHOULD. What say ?? > [IPv6-ADDR] Hinden, R., S. Deering, "IP Version 6 Addressing > Architecture", RFC2373, July 1998. >=20 > =3D=3D> update. Note that this is not Draft Standard yet. As there = is=20 > nothing in IPv6-ADDR that's required by that spec, it could be=20 > informative as well. Makes sense. I will move this to informative. > [PMTU] McCann, J., S. Deering, J. Mogul, "Path MTU Discovery > for IP version 6", RFC1981, August 1996. >=20 > [IPv6-SA] Kent, S., R. Atkinson, "Security Architecture for the > Internet Protocol", RFC1825, November 1998. >=20 > =3D=3D> These, and IPsec RFCs are PS's at the moment -- can't refer. =20 > IPsec ones are being revised though, if that helps any. As I referred from the draft-ymbk-downref-01.txt, IPsec RFCs should be normative. So what should we do now ? Also should we refer to the old IPsec RFCs or we should refer to the updated ones ? If we want to refer to updated ones, how do we refer to them because they are still drafts. > editorial > --------- >=20 > (f) Finally, in order to limit the bandwidth and forwarding costs =20 > incurred sending ICMPv6 error messages, an IPv6 node=20 > MUST limit=20 > =20 > =3D=3D> s/incurred/incurred by/ Will take care of this in the next rev. Thanks again for reviewing the draft. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Mar 21 21:48:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13893 for ; Sun, 21 Mar 2004 21:48:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5FTS-0002WW-Rk for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 21:47:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M2lY44009699 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 21:47:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5FTS-0002WM-Ky for ipv6-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 21:47:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13866 for ; Sun, 21 Mar 2004 21:47:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5FTP-0001Id-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 21:47:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5FSe-00019C-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 21:46:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5FRT-0000yP-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 21:45:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5FR1-00024J-7D; Sun, 21 Mar 2004 21:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5FQK-00023D-O9 for ipv6@optimus.ietf.org; Sun, 21 Mar 2004 21:44:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13620 for ; Sun, 21 Mar 2004 21:44:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5FQH-0000nw-00 for ipv6@ietf.org; Sun, 21 Mar 2004 21:44:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5FPs-0000gl-00 for ipv6@ietf.org; Sun, 21 Mar 2004 21:43:53 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1B5FOp-0000IC-00 for ipv6@ietf.org; Sun, 21 Mar 2004 21:42:47 -0500 Received: from ssprunk (ip144.post-vineyard.dfw.ygnition.net [66.135.181.144]) by ns2.sea (8.12.11/8.12.5) with SMTP id i2M2g7mV028830; Sun, 21 Mar 2004 18:42:11 -0800 Message-ID: <014701c40fb7$46e1a000$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Bill Manning" Cc: "IETF IPv6 WG" , "ARIN Policy" References: <200403191612.i2JGCnp13620@boreas.isi.edu> Subject: Re: ASN-based prefixes for leaf ASes Date: Sun, 21 Mar 2004 20:34:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Bill Manning" > sure, fine. Just pointing out the ASN based, prefix assignment > hack is -very- old and has been abandoned by the IETF in > favor of the processes we currently use. That doesn't mean abandoning it completely was a good idea. That system also didn't provide a mechanism for non-leaf ASes to get non-ASN-based allocations, which severely limited its scalability. We've jumped from one extreme to the other, when perhaps using both systems in parallel might be most efficient. > % > % draft-savola-multi6-asn-pi-01.txt > % > % (Well, I don't like that proposition either..) > % > % p.s. the correct forum may be multi6. > % > > % > Actually, the correct forum would be the RIR public policy mtgs. > % > % Not yet IMHO, see above. > > actually, I think it is imprudent to not include the > RIR public policy fourm in any discussions on new address > assignment plans. YMMV of course. I agree and invite input from ARIN members. NOTE: Please include in your comments whether you're a leaf or non-leaf AS. 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 exim@www1.ietf.org Mon Mar 22 01:55:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23761 for ; Mon, 22 Mar 2004 01:55:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5JL9-00018i-9W for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 01:55:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M6tF2a004374 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 01:55:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5JL9-00018T-2s for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 01:55:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23753 for ; Mon, 22 Mar 2004 01:55:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5JL5-0005DW-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 01:55:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5JKD-00058T-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 01:54:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5JJe-00053P-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 01:53:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5JIz-0000nT-VS; Mon, 22 Mar 2004 01:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5JIR-0000mZ-EI for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 01:52:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23661 for ; Mon, 22 Mar 2004 01:52:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5JIO-0004wl-00 for ipv6@ietf.org; Mon, 22 Mar 2004 01:52:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5JHX-0004qh-00 for ipv6@ietf.org; Mon, 22 Mar 2004 01:51:31 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1B5JH6-0004jR-00 for ipv6@ietf.org; Mon, 22 Mar 2004 01:51:05 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0FE7E15210; Mon, 22 Mar 2004 15:50:59 +0900 (JST) Date: Mon, 22 Mar 2004 15:50:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: ipv6@ietf.org, Ole Troan , , , Pekka Savola Subject: Re: simpler prefix delegation In-Reply-To: <4.3.2.7.2.20040318093441.029eb910@flask.cisco.com> References: <7t5brmus1r5.fsf@mrwint.cisco.com> <4.3.2.7.2.20040318093441.029eb910@flask.cisco.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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Thu, 18 Mar 2004 09:45:12 -0500, >>>>> Ralph Droms said: > For the IPv6 WG - let's cut to the chase. Is there interest in expending > any more of the IETF's resources reopening a problem for which we > have rough consensus on a solution, published specifications and running > code? We have lots of important problems that have *no* solution, yet; > let's move on to those problems and start deploying the solutions we already > have completed. I basically agree, especially in that this thread won't be productive enough to spend everyone's energy. Just to state my own opinions on some discussion points: - whether (implementing) DHCPv6 is too complex for the purpose of prefix delegation. I'm reluctant to have this discussion, since this kind of discussion often tends to be a subjective one. I personally don't think the spec is "too" complex from my experience of reviewing and implementing the document, but it would be difficult to prove my impression. For example, I needed three days to implement (an initial version) the prefix delegation mechanism using the "IA" based resource management, which corresponds to the core part of the DHCPv6 specification. Two weeks later (since then I had made some bug fixes and additional features to the initial implementation), I confirmed the interoperability of the implementation with several other vendors. Can this fact be a proof that the specification is "not to complex to implement"? May be not, particularly for those who do believe the complexity from the beginning... I also know several vendors that provide "cheap" CPE devices, including Yamaha, 6Wind and Allied Telesis (some of them may not be popular outside Japan), have implementations of prefix delegation based on DHCPv6. Do we really want to provide (yet) other candidates due to the "complexity" even with this fact? Probably yes, those who do believe the complexity... - whether it is a good thing to provide other (new) possibilities. Of course, having alternatives is in general good. In this particular case, however, I don't see the need for it. First, as already stated, I don't think the "complexity" (if any) can be a show-stopper of IPv6 prefix delegation. In fact, (again as already stated) even vendors who would want a "simpler" specification have already implemented the specification. On the other hand, having several choices would increase implementation/operational cost. Vendors will end up implementing both (or all) of them, considering possible combinations. Operators will often have to learn how to configure the devices for all mechanisms (because in general we cannot assume a particular behavior at the other end). These kinds of issues are not new or specific to prefix delegation; it's basically a trade off issue. But, IMO in this case, I don't think the advantages of flexibility outweigh the disadvantages of the cost. In any event, I don't know how we can go about this discussion. As we've seen (or as far as I've seen), the points are quite subtle and/or subjective and it will be difficult for any party to convince the other. One thing I'm quite sure is that it will be a waste of time to continue the discussion here (whether the "simpler" mechanism is a good idea or not). So, I'd like to propose: 1. let's just stop this thread now. On top of this, 2-1 if those who want to standardize the "simpler" mechanism can continue the work as individual, let them do it, and let "the market" decide. If the market likes the "simpler" idea, vendors will start implementing it and operators will start deploying it. Then we can consider to take it as a wg item and/or publish it as an RFC, etc. 2-2 if those who want to standardize the "simpler" mechanism stick to adopting it as a wg document, then I don't know what to do. But we'll at least need to see consensus to adopt it. And, with all due respect (I'm trying to be fair as much as possible), the idea has not attracted many people. 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 exim@www1.ietf.org Mon Mar 22 04:04:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11083 for ; Mon, 22 Mar 2004 04:04:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5LM2-0004Es-OK for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 04:04:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M94IHf016290 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 04:04:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5LM2-0004Ef-GJ for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 04:04:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11072 for ; Mon, 22 Mar 2004 04:04:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5LLz-0002U2-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 04:04:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5LL8-0002PS-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 04:03:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5LKX-0002KQ-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 04:02:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5LJq-0003te-FQ; Mon, 22 Mar 2004 04:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5LJ6-0003rr-UK for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 04:01:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10984 for ; Mon, 22 Mar 2004 04:01:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5LJ4-0002Dl-00 for ipv6@ietf.org; Mon, 22 Mar 2004 04:01:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5LI9-00029E-00 for ipv6@ietf.org; Mon, 22 Mar 2004 04:00:18 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1B5LHX-0001zT-00 for ipv6@ietf.org; Mon, 22 Mar 2004 03:59:39 -0500 Received: from ssprunk (ip144.post-vineyard.dfw.ygnition.net [66.135.181.144]) by ns2.sea (8.12.11/8.12.5) with SMTP id i2M8x6kQ030246; Mon, 22 Mar 2004 00:59:06 -0800 Message-ID: <004f01c40feb$eff3ccc0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Stephen Sprunk" , "Bill Manning" Cc: "IETF IPv6 WG" , "ARIN Policy" References: <200403191612.i2JGCnp13620@boreas.isi.edu> <014701c40fb7$46e1a000$6401a8c0@ssprunk> Subject: Re: ASN-based prefixes for leaf ASes Date: Mon, 22 Mar 2004 02:50:24 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Stephen Sprunk" > I agree and invite input from ARIN members. NOTE: Please include in your > comments whether you're a leaf or non-leaf AS. I forgot that PPML wasn't copied on the original message... To clarify: My proposal was that automatic /48 allocations be made to anyone with an ASN, based on the premise that every AS will advertise at least one PI block. These allocations would not allow sub-assignment (i.e. by non-leaf ASes). Non-leaf ASes might use their ASN-based allocation for internal use, or might ignore the ASN-based allocation in favor of "normal" TLA allocations to minimize the number of advertised prefixes; the ASN-based allocation should not count against non-leaf ASes for measuring utilization of "normal" TLA allocations. Leaf ASes would not be granted "normal" TLA allocations without either evidence their ASN-based prefix was substantially consumed or reasonable technical justification for multiple prefixes, e.g. for varying BGP policies. Some may note this is somewhat similar to 3ffe:: allocations to 6bone sites, which were deprecated once RIR-based IPv6 allocations were standardized. The major difference is that I propose it mainly apply to leaf ASes. IMHO, ASN-based allocations still make sense for leaf ASes, and forcing leaf ASes through the RIR process for initial allocations is suboptimal if one accepts the premise that every AS will advertise at least one PI prefix. 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 exim@www1.ietf.org Mon Mar 22 07:28:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19631 for ; Mon, 22 Mar 2004 07:28:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OXZ-0000Hd-LJ for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 07:28:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MCSPYM001083 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 07:28:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OXZ-0000HO-Ep for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 07:28:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19610 for ; Mon, 22 Mar 2004 07:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5OXY-0001Dk-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 07:28:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5OWh-00018O-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 07:27:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5OVi-00012y-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 07:26:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OVH-0008Ov-LU; Mon, 22 Mar 2004 07:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OUg-0008O1-LD for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 07:25:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19541 for ; Mon, 22 Mar 2004 07:25:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5OUg-0000wt-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:25:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5OTk-0000sF-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:24:29 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1B5OTL-0000nN-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:24:03 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 348B915210; Mon, 22 Mar 2004 21:23:56 +0900 (JST) Date: Mon, 22 Mar 2004 21:23:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: rfc2462bis: new section 5.7 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Mon, 1 Mar 2004 23:59:17 -0800 (PST), >>>>> Erik Nordmark said: > The new section looks good but I think it should require that the host > store the times when the address would become deprecated and invalid > together with the address itself in stable storage. > Without that an address might accidentally be used long after it has > become invalid. Good point, thanks. How about changing the first sentence of Section 5.7 as follows? It is reasonable that implementations that have stable storage retain their addresses and the expiration times of the preferred and valid lifetimes if the addresses were acquired using stateless address autoconfiguration. Meanwhile, I have more fundamental questions: 1. it is probably not adequate to describe this in the body of rfc2462bis, since it's a kind of extension, not a bug fix or a clarification to the existing specification. Shouldn't we rather move this section to appendix entitled (e.g.) "future possible extensions"? Or should we describe this in rfc2462bis in the first place? I myself do not have a particular preference, but if we cannot reach consensus, I'd rather remove this section from rfc2462bis. 2. this extension may conflict with the rule that "if no router exists, then stateful configuration MUST be performed" (though we are now discussing the requirement level on this). Assuming the current requirement level, should we also describe the relationship (or ordering) between the two alternatives? For example, should we require that this extension (i.e., retaining the address) be used only after the attempt of stateful address configuration fails? 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 exim@www1.ietf.org Mon Mar 22 07:54:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20880 for ; Mon, 22 Mar 2004 07:54:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OwF-0004C2-JE for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 07:53:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MCrtsJ016112 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 07:53:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OwF-0004Bl-C3 for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 07:53:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20851 for ; Mon, 22 Mar 2004 07:53:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5OwD-0004Bo-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 07:53:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Our-0003yN-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 07:52:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5OuX-0003tA-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 07:52:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5Ory-0003Nh-Go for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 07:49:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ord-0003aq-6s; Mon, 22 Mar 2004 07:49:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Oqt-0003aV-0D for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 07:48:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20694 for ; Mon, 22 Mar 2004 07:48:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Oqs-0003eL-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:48:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Opt-0003Z4-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:47:22 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Oov-0003QO-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:46:22 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2MCjjc14770; Mon, 22 Mar 2004 14:45:45 +0200 Date: Mon, 22 Mar 2004 14:45:45 +0200 (EET) From: Pekka Savola To: Mukesh.Gupta@nokia.com cc: ipv6@ietf.org Subject: RE: icmpv6-v3 comments In-Reply-To: <8D260779A766FB4A9C1739A476F84FA4015473F9@daebe009.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 On Sun, 21 Mar 2004 Mukesh.Gupta@nokia.com wrote: > > Process issue: Draft Standard may not refer normatively to > > specifications of lower standardization status. See > > draft-ymbk-downref-01.txt for a bit of discussion. That is, > > IPv6-ADDR, PMTU and IPsec documents are unsuitable for normative > > references. So, some wiggling around will be needed.. > > Well, the draft draft-ymbk-downref-01.txt says > ==== > In the case of protocols, a reference is normative if it refers to > packet formats or other protocol mechanisms that are needed to fully > implement the protocol in the current specification. For example, if > a protocol relies on IPsec to provide security, one cannot fully > implement the protocol without the specification for IPsec also being > available; hence, the reference would be normative. > ==== > > As ICMPv6 proposes to use IPsec for security, according to the above > paragraph, IPsec documents should be normative. So how do we resolve > this ? Well, if we conclude that those are required, maybe we have to use draft-ietf-ipsec-rfc2402bis instead -- that's already been at IESG evaluation so might not end up blocking the document. PMTUD and Addr-arch would probably have to go on Informational section, unless we conclude that they're too strong to be used here. > > (c) If the message is a response to a message sent to an address > > that does not belong to the node, the Source Address should be > > that unicast address belonging to the node that will be most > > helpful in diagnosing the error. For example, if the message is > > a response to a packet forwarding action that cannot complete > > successfully, the Source Address should be a unicast address > > belonging to the interface on which the packet forwarding > > failed. > > > > ==> not sure if this has been implemented, so the usability > > of this generic rule seems questionable. > > Are you proposing to remove this ? Yes. (But if people think mentioning some optional behaviour like this is a good idea, maybe it could be reworded/removed in the appendix as well.) > I think, all the implementations use the IP address of the egress > interface for the ICMP packet as the source address of the packet. That is my perception as well. > The above paragraph suggests to use the IP address of the interface > on which the packet was supposed to be forwarded. Now if we are > unable to forward the packet, how would we know which interface it > was supposed to go out on :-/ So which IP address should be used > in that case ! That's a real procedural problem, and maybe one of the main reasons why this was omitted. In some cases, I think getting the IP address would be possible, but in general it would be rather challenging.. > > If the reason for the failure to deliver can not be mapped > > to any of > > the specific codes listed above, the Code field is set to 3. The > > example of such cases are inability to resolve the IPv6 destination > > address into a corresponding link address, or a > > link-specific problem > > of some sort. > > > > ==> reasons with codes 4, 5, and 6 are below this sentence. > > Maybe those paragraphs should be moved up, earlier in this > > section, or the language here reworded? > > Actually, I wanted to keep the description of the codes in the numerical > order. If this description sounds confusing, could you suggest how to > re-word it such that it is clearer without moving the descriptions of > 4, 5 and 6 before this ? Maybe reword: If the reason for the failure to deliver can not be mapped to any of the specific codes listed above, the Code field is set to 3. to: If the reason for the failure to deliver can not be mapped to any of other codes, the Code field is set to 3. ? > > If the reason for the failure to deliver is that packet with this > > source address is not allowed due to ingress or egress filtering > > policies, the Code field is set to 5. > > > > If the reason for the failure to deliver is that the route to the > > destination is a reject route, the Code field is set to 6. This may > > occur if the router has been configured to reject all the traffic for > > a specific prefix. > > > > ==> as has already been mentioned, these two rules are in fact a > > more specific, more informative subsets of code 1 -- > > administratively prohibited. I persnally don't see much of an > > objection for adding these codes, but it would IMHO make useful to > > spell this out explicitly here. > > Would it help to add the following text: > ==== > Codes 5 and 6 are more informative subsets of code 1. Thus code 1 > MAY be used in place of code 5 and 6. > ==== Fine with me, at least. (I guess there could be some resistance to the second sentence, but if so, it could always be removed.) > > It SHOULD be possible for the system administrator to configure a > > node to ignore any ICMP messages that are not authenticated using > > either the Authentication Header or Encapsulating Security Payload. > > Such a switch SHOULD default to allowing unauthenticated messages. > > > > ==> has this even been implemented anywhere? could maybe be > > deleted? This is completely unpractical, e.g., just consider > > PMTU packets -- there is no way you'll ever be able to set > > up security associations with everyone in the Internet to be > > able to accept the packets :) > > I completely agree with you that this is unpractical but it does > make sense to a completely paranoid administrator. Whoever turns > this option ON might not be interested in using PMTU. I don't > see any harm in keeping it. We can make it a MAY from SHOULD. > > What say ?? OK -- I'm fine with putting it in as MAY, with some additional text to describe its inherent problems, e.g. like: Note that setting up Security Associations to deal with all the required ICMP packets is a very difficult, if not even impossible, task (e.g., consider the PMTUD packets) so typically this is does not seem to be practical. > > [PMTU] McCann, J., S. Deering, J. Mogul, "Path MTU Discovery > > for IP version 6", RFC1981, August 1996. > > > > [IPv6-SA] Kent, S., R. Atkinson, "Security Architecture for the > > Internet Protocol", RFC1825, November 1998. > > > > ==> These, and IPsec RFCs are PS's at the moment -- can't refer. > > IPsec ones are being revised though, if that helps any. > > As I referred from the draft-ymbk-downref-01.txt, IPsec RFCs should > be normative. So what should we do now ? > > Also should we refer to the old IPsec RFCs or we should refer to the > updated ones ? If we want to refer to updated ones, how do we refer > to them because they are still drafts. See above. Referring to drafts is OK as long as they don't create a blockage when this work moves forward. As the docs are already at IESG and this is not, this is (hopefully!) not a problem. -- 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 exim@www1.ietf.org Mon Mar 22 07:55:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21083 for ; Mon, 22 Mar 2004 07:55:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OxH-0004Ee-TD for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 07:55:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MCsxmT016274 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 07:54:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OxH-0004EP-Oh for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 07:54:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21027 for ; Mon, 22 Mar 2004 07:54:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5OxG-0004Pw-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 07:54:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Ovx-00049f-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 07:53:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5Oum-0003tA-02 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 07:52:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5Ok9-0002zW-Pl for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 07:41:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ojm-00023E-TL; Mon, 22 Mar 2004 07:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OjJ-00020L-2J for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 07:40:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20481 for ; Mon, 22 Mar 2004 07:40:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5OjH-0002y6-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:40:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5OiM-0002sy-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:39:35 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1B5Ohr-0002nI-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:39:03 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3A0FD15210 for ; Mon, 22 Mar 2004 21:39:02 +0900 (JST) Date: Mon, 22 Mar 2004 21:38:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: Reminder: Re: [rfc2462bis issue 278] 2462bis for "routers" 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_Mon_Mar_22_21:38:59_2004-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --Multipart_Mon_Mar_22_21:38:59_2004-1 Content-Type: text/plain; charset=US-ASCII No one has provided an opinion on this...if the list is still silent, I'll leave the current text as is, as proposed below. If anyone of you strongly want something explicit on this in rfc2462bis, please speak up (with proposed text if possible). Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Mon_Mar_22_21:38:59_2004-1 Content-Type: message/rfc822 X-Mail-Format-Warning: Bad RFC2822 header formatting in >From jinmei Sun Feb 8 23:27:55 2004 X-Original-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@shuttle.wide.toshiba.co.jp Date: Sun, 08 Feb 2004 23:24:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 278] 2462bis for "routers" 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on ocean.jinmei.org X-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL autolearn=no version=2.61 >>>>> On Thu, 5 Feb 2004 17:32:03 -0800 (PST), >>>>> Erik Nordmark said: > So do we or do we not want to > 1. specify the per-interface router definition > 2. specify how RFC 2461 (and 62) behave on a multihomed node Hmm, I see the discussion about the definition of per-interface router leads us to the more generic (and difficult) issues: ND/autoconf for a multihomed node (host). Although opinions on this may vary, my impression is that the generic issue is beyond the scope of 2461/2462bis. It would require a large amount of time for discussion and would require significant changes to implementations. This does not meet the original purpose of 2461/2462bis. However, I also think per-interface stateless address autoconfiguration is relatively trivial and can be consistent with the current RFC2461 spec (and with 2461bis probably). That is, I think we can allow a node to receive an RA on a non-advertising interface (per RFC2461) to configure a global address on the interface without going into further on the multihome issues. In any event, I don't have a strong opinion on this. If we can quickly reach a consensus about the per-interface address autoconfiguration, I'll revise the rfc2462bis text accordingly. Otherwise, I'd simply leave the current text as is (it would be a bit ambiguous as currently is, though). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --Multipart_Mon_Mar_22_21:38:59_2004-1-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 22 10:42:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01840 for ; Mon, 22 Mar 2004 10:42:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5RXk-0003Gq-RA for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 10:41:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MFecMm012498 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 10:40:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5RXa-0003Eg-FQ for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 10:40:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01655 for ; Mon, 22 Mar 2004 10:40:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5RXR-00023c-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 10:40:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5RW5-0001km-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 10:39:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5RTt-0001I6-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 10:36:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5RTE-0002PN-P2; Mon, 22 Mar 2004 10:36:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5RSj-0002OG-3Z for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 10:35:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01196 for ; Mon, 22 Mar 2004 10:35:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5RSg-00012d-00 for ipv6@ietf.org; Mon, 22 Mar 2004 10:35:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5RRi-0000wR-00 for ipv6@ietf.org; Mon, 22 Mar 2004 10:34:34 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1B5RQv-0000m6-00 for ipv6@ietf.org; Mon, 22 Mar 2004 10:33:45 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i2MFX2LF071304; Mon, 22 Mar 2004 15:33:04 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i2MFVofL264594; Mon, 22 Mar 2004 16:31:50 +0100 Received: from zurich.ibm.com (sig-9-145-143-82.de.ibm.com [9.145.143.82]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA293976; Mon, 22 Mar 2004 16:31:43 +0100 Message-ID: <405F06F8.61337C12@zurich.ibm.com> Date: Mon, 22 Mar 2004 16:32:08 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Stephen Sprunk CC: Bill Manning , IETF IPv6 WG , ARIN Policy Subject: Re: ASN-based prefixes for leaf ASes References: <200403191612.i2JGCnp13620@boreas.isi.edu> <014701c40fb7$46e1a000$6401a8c0@ssprunk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stephen Sprunk wrote: > > Thus spake "Bill Manning" ... > > > > actually, I think it is imprudent to not include the > > RIR public policy fourm in any discussions on new address > > assignment plans. YMMV of course. > > I agree and invite input from ARIN members. NOTE: Please include in your > comments whether you're a leaf or non-leaf AS. I didn't mean to imply that input from the RIRs was unwanted - on the contrary, input from them is essential. I did mean to say that the basic technical consensus on whether we should go in this sort of direction at all needs to be formed here (IETF) and that is why I made an analogy with the early history of CIDR. fwiw I'm not convinced that ASN-based prefixes are a good idea, for reasons that others have stated. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 22 15:16:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17593 for ; Mon, 22 Mar 2004 15:16:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Vq5-00038z-Jk for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 15:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MKG0WR012046 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 15:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Vq4-000389-JD for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 15:16:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17499 for ; Mon, 22 Mar 2004 15:15:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Vq3-0004wV-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 15:15:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Vp1-0004mr-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 15:14:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5VoF-0004eU-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 15:14:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Vng-0001fZ-Vk; Mon, 22 Mar 2004 15:13:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Vlu-0000pK-9m for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 15:11:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16882 for ; Mon, 22 Mar 2004 15:11:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Vlo-0004GZ-00 for ipv6@ietf.org; Mon, 22 Mar 2004 15:11:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Vkp-00046S-00 for ipv6@ietf.org; Mon, 22 Mar 2004 15:10:36 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B5Vjs-0003w5-00 for ipv6@ietf.org; Mon, 22 Mar 2004 15:09:36 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2MK9Kp9021984; Mon, 22 Mar 2004 13:09:20 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2MK9GQ21266; Mon, 22 Mar 2004 21:09:16 +0100 (MET) Date: Mon, 22 Mar 2004 12:09:17 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: simpler prefix delegation To: Pekka Savola Cc: Brian E Carpenter , matthew.ford@bt.com, rdroms@cisco.com, ipv6@ietf.org, ot@cisco.com, skylane@etri.re.kr, erik.nordmark@sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 FWIW RFC 2461+2462 is 118 pages and I don't recall people complaining about them being too complex to implement. I suspect 2 more pages for DHCPv2 + DHCPV6 PD isn't that significant. So I think there is something other than page count that matters. Writing clear specifications which answers the implementor's questions up front as well as specifies sufficient detail for a high likelyhood of interoperable implementations etc means that a fair number of things need to be written down. Oh - and I think DHCPv6 has more implementable/deployable security than neighbor discovery (since we were more lax about mandatory to implement security and interoperability testing with security back in 1998). If you want that for the Neighbor Discovery functionality you need to add 60 to 80 pages of SEND drafts to the page count. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 22 16:23:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24301 for ; Mon, 22 Mar 2004 16:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Wsv-0002Us-B1 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 16:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MLMqNa009554 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 16:22:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Wsl-0002Tz-MJ for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 16:22:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24153 for ; Mon, 22 Mar 2004 16:22:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Wse-0007MP-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 16:22:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Wr8-00070j-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 16:21:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Wpl-0006hi-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 16:19:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Wp4-00024e-E9; Mon, 22 Mar 2004 16:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5WoG-0001lV-Sz for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 16:18:13 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23298 for ; Mon, 22 Mar 2004 16:18:10 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B5Wnm-0001jP-Ih; Mon, 22 Mar 2004 16:17:42 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , ipv6 mailing list , ipv6 chair , ipv6 chair Subject: Protocol Action: 'Management Information Base for the Transmission Control Protocol (TCP)' to Proposed Standard Message-Id: Date: Mon, 22 Mar 2004 16:17:42 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has approved the following document: - 'Management Information Base for the Transmission Control Protocol (TCP) ' as a Proposed Standard This document is the product of the IP Version 6 Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2012 and 2452. It accomplishes this by utilizing the InetAddress TC to provide IP address-independence on the management objects. This allows a single MIB to provide the same level of management for IPv4 and IPv6. Working Group Summary This document was produced by the IPv6 WG. There was strong WG consensus for this document in both the IPv6 working group and the IPv6 MIB design team. This document through WG last call and was updated to address last call comments. Protocol Quality This document has undergone significant review by management experts. In particular, Kristine Adamson has raised several important points from an implementation point of view. This document was reviewed for the IESG by Margaret Wasserman. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 22 20:06:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07809 for ; Mon, 22 Mar 2004 20:06:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5aMj-0002Fv-RA for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 20:06:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N16132008658 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 20:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5aMi-0002FP-WE for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 20:06:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07775 for ; Mon, 22 Mar 2004 20:05:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5aMh-0003A7-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 20:05:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5aLk-000335-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 20:05:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5aLJ-0002wW-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 20:04:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5aKo-0001wo-Ch; Mon, 22 Mar 2004 20:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5aKa-0001vq-P1 for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 20:03:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07659 for ; Mon, 22 Mar 2004 20:03:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5aKY-0002ub-00 for ipv6@ietf.org; Mon, 22 Mar 2004 20:03:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5aJY-0002nv-00 for ipv6@ietf.org; Mon, 22 Mar 2004 20:02:45 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B5aIY-0002dA-00 for ipv6@ietf.org; Mon, 22 Mar 2004 20:01:42 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2N10ks03525; Mon, 22 Mar 2004 17:00:46 -0800 X-mProtect: <200403230100> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduJTXGv; Mon, 22 Mar 2004 17:00:44 PST Message-ID: <405F8C3A.8030803@iprg.nokia.com> Date: Mon, 22 Mar 2004 17:00:42 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Pekka Savola , Brian E Carpenter , matthew.ford@bt.com, rdroms@cisco.com, ipv6@ietf.org, ot@cisco.com, skylane@etri.re.kr Subject: Re: simpler prefix delegation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This discussion (and the bykim draft) reminds me of some materials I briefed a long time ago during an NGTRANS session at IETF50: http://6bone.net/ngtrans/IETF-50-Minneapolis/Templin-v6v4compat.ppt (See slides #15-#19; note that the colors in the diagrams denote distinct IPv6 prefix assignments). The breifing presented a high-level vision of how a hierarchy of IPv6 prefixes could be driven deeply into an enterprise network ([RFC1918], section 1) during the early phases of IPv6 deployment w/o delving into technical details save for one - ISATAP was then and remains today the basic IPv6-over-(foo) mechanism required to support the vision. In terms of other required functions, this thread is touching on many but it seems surprising that folks are viewing things from an "either/or" perspective. Instead, it seems clear that the solution will not amount to picking one of DHCPv6 vs. IPv6 ND, but rather combining the best aspects of both. For example, the notion of "stateless prefix delegation" seems a clear oxymoron; prefix delegations require servers to keep lease lifetimes and employ mechanisms to avoid duplicate assignments and reclaim expired prefixes. We already have the state engine of DHCPv6 for this, and so how could it make sense to re-invent this wheel vis-a-vis extensions to the stateless mechanisms specified by RFCs 2461/2? By the same token, router lifetime advertisements, autoconfiguration prefix advertisements, etc. are clearly stateless mechanisms and so how could it make sense to use DHCPv6 for this instead of IPv6 ND? It seems like folks might be hung up somewhat on mistaking the actual format of messages sent over the wire with the protocols implemented at the endpoints. In other words, it just doesn't matter what we call the messages that are sent over the wire as long as they are kept to a minimum, are efficiently coded, and support the hybrid functions required for combining the best aspects of DHCPv6 and IPv6 ND. Perhaps this entails piggybacking DHCPv6 and IPv6 ND messages? Perhaps this entails deploying a DHCPv6 server/relay on each IPv6 router/ND proxy? To use an analogy, the legendary golfer Bobby Jones said that the secret to shooting low scores is to "find a way to turn 3 shots into 2". If we can find a way to combine the best aspects of DHCPv6 and IPv6 ND, and "turn 4 messages into 2", then everyone wins. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 23 00:19:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20431 for ; Tue, 23 Mar 2004 00:19:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5eJi-00049d-5m for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 00:19:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N5JAPw015963 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 00:19:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5eJi-00049O-0i for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 00:19:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20418 for ; Tue, 23 Mar 2004 00:19:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5eJf-00048h-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 00:19:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5eIv-00040T-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 00:18:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5eIA-0003qY-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 00:17:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5eHe-0003gh-6s; Tue, 23 Mar 2004 00:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5eGh-0003eO-Ix for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 00:16:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20277 for ; Tue, 23 Mar 2004 00:16:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5eGf-0003au-00 for ipv6@ietf.org; Tue, 23 Mar 2004 00:16:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5eFs-0003Si-00 for ipv6@ietf.org; Tue, 23 Mar 2004 00:15:13 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B5eF6-0003J4-00 for ipv6@ietf.org; Tue, 23 Mar 2004 00:14:24 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2N5Dxp9017675; Mon, 22 Mar 2004 22:14:00 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2N5DuQ11562; Tue, 23 Mar 2004 06:13:56 +0100 (MET) Date: Mon, 22 Mar 2004 21:13:57 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND-proxy applicability and loop-prevention To: Pekka Savola Cc: Erik Nordmark , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 I'd sure be interested in hearing what others in the WG think on this issue. > > The solution you want in this space is something which allows plug&play of > > the devices that glue together the stacking. And since you don't know how > > the customer will plug things together, I think you must deal with loops. > > I have a fundamental disagreement with this. Any scenario where you > would plug these in any other mode than in series should be strictly > out of scope. IMHO, we don't want to deal with that. > If the user plugs three ND-proxies in a triangle or two (or > more) ND-proxies in a loop, the everything breaks -- and the customer > fixes the set-up or calls someone to fix it. Immediate failure, > immediate fix. I see no problem with this. As it is, ND-proxy should > never be enabled by default in any case. Pekka, elsewhere (in a mail on v6ops) you stated the concern that IPv6 might end up with consumer-class "routers" (devices that sit between different types of L2) that do v6-to-v6 NAT because that would be more plug and play than the alternatives hence we need an alternative like ndproxy (at least I think you made that argument). Saying that ndproxy needs to be manually enabled and can't be enabled by default doesn't match this concern. I also don't see how one can prevent consumers from connecting such devices in ways that form loops. It *might* be sufficient if the solution could detect loops and sound the alarm (and stop forwarding frames), but ndproxy can't even detect loops and shut itself off. Thus when loops are formed the result is that the consumer will see their network die (100% link utilization due to frames looping around forever; ndproxy doesn't decrement the hop count). This doesn't satisfy what I think you say you want to solution to do. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 23 01:56:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24243 for ; Tue, 23 Mar 2004 01:56:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5fpd-000482-93 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 01:56:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N6uDFn015838 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 01:56:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5fpc-00046t-1a for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 01:56:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24232 for ; Tue, 23 Mar 2004 01:56:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5fpY-0007UW-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 01:56:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5foX-0007OG-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 01:55:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5fo4-0007IB-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 01:54:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5fnW-0003iP-OJ; Tue, 23 Mar 2004 01:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5fmX-0003fk-At for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 01:53:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24124 for ; Tue, 23 Mar 2004 01:52:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5fmU-0007AP-00 for ipv6@ietf.org; Tue, 23 Mar 2004 01:52:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5flT-00071z-00 for ipv6@ietf.org; Tue, 23 Mar 2004 01:51:56 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5fkU-0006nr-00 for ipv6@ietf.org; Tue, 23 Mar 2004 01:50:54 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2N6oLl31399; Tue, 23 Mar 2004 08:50:21 +0200 Date: Tue, 23 Mar 2004 08:50:21 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 22 Mar 2004, Erik Nordmark wrote: > elsewhere (in a mail on v6ops) you stated the concern that IPv6 might end > up with consumer-class "routers" (devices that sit between different types of > L2) that do v6-to-v6 NAT because that would be more plug and play > than the alternatives hence we need an alternative like ndproxy > (at least I think you made that argument). Right. > Saying that ndproxy needs to be manually enabled and can't be enabled > by default doesn't match this concern. Oh, sorry -- I meant that ND-proxying would not be manually enabled on *hosts* (naturally not) -- and if a router has some routing information, ND proxy could be disabled in any case. As a matter of fact, as push-button on the side of the box, "proxy/router", might be doable. > I also don't see how one can prevent consumers from connecting such > devices in ways that form loops. They cannot be prevented, yes. (And I don't think this is a serious problem, but more of a kind of support FAQ to show to the users.) > It *might* be sufficient if the solution could detect loops and sound the alarm > (and stop forwarding frames), but ndproxy can't even detect loops and shut > itself off. Thus when loops are formed the result is that the consumer will > see their network die (100% link utilization due to frames looping around > forever; ndproxy doesn't decrement the hop count). I don't personally think 100% link utilization is that bad a signal. It rather simply conveys that "oops-- I've done something wrong when I added the box there." and after it's removed all starts to work again -- intuitive. What would be worse is that some packets would work but some others not. Total connectivity loss is a good indicator of a problem :). I think it would be possible to detect loops if we wanted really hard to do that. That might just lead to reinvention of the spanning tree protocol, though. For example, the ND proxy could send in ND solicitation for its own IP address. If it hears back that solicitation on some other interface, it can conclude that someone is looping those packets and it should e.g. shut down completely. -- 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 exim@www1.ietf.org Tue Mar 23 06:14:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18094 for ; Tue, 23 Mar 2004 06:14:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5jrC-0008IP-Mx for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 06:14:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NBE6bm031887 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 06:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5jrC-0008I6-21 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 06:14:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17989 for ; Tue, 23 Mar 2004 06:14:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5jr8-0006ed-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 06:14:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5jog-00068q-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 06:11:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5jnQ-0005wp-02 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 06:10:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5ji6-0002z3-Fs for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 06:04:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5jhX-0006ab-Qb; Tue, 23 Mar 2004 06:04:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5jer-0006Sq-5h for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 06:01:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17531 for ; Tue, 23 Mar 2004 06:01:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5jen-00055T-00 for ipv6@ietf.org; Tue, 23 Mar 2004 06:01:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5je3-0004yM-00 for ipv6@ietf.org; Tue, 23 Mar 2004 06:00:32 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B5jd7-0004oy-00 for ipv6@ietf.org; Tue, 23 Mar 2004 05:59:33 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2958289946; Tue, 23 Mar 2004 12:59:28 +0200 (EET) Message-ID: <406017F2.7010109@kolumbus.fi> Date: Tue, 23 Mar 2004 12:56:50 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: Erik Nordmark , ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Erik and Hesham that loop preventation is something that we may wish to have. A couple of comments on what Pekka wrote about detection: > I think it would be possible to detect loops if we wanted really hard > to do that. That might just lead to reinvention of the spanning tree > protocol, though. This is a danger, yes. > For example, the ND proxy could send in ND solicitation for its own IP > address. If it hears back that solicitation on some other interface, > it can conclude that someone is looping those packets and it should > e.g. shut down completely. Right. Or add an ND option to a proxied query, and detect when you receive an option which you inserted by yourself. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 23 06:16:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18425 for ; Tue, 23 Mar 2004 06:16:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5jsg-0000BM-JN for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 06:15:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NBFcop000688 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 06:15:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5jsg-0000Aj-3w for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 06:15:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18369 for ; Tue, 23 Mar 2004 06:15:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5jsc-00073t-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 06:15:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5jqt-0006bR-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 06:13:48 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5joM-00064z-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 06:11:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5joO-0003MJ-R5 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 06:11:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5joF-0007vU-Th; Tue, 23 Mar 2004 06:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5jnS-0007qq-RP for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 06:10:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17803 for ; Tue, 23 Mar 2004 06:10:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5jnP-0005xA-00 for ipv6@ietf.org; Tue, 23 Mar 2004 06:10:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5jmT-0005r4-00 for ipv6@ietf.org; Tue, 23 Mar 2004 06:09:14 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5jlr-0005jy-00 for ipv6@ietf.org; Tue, 23 Mar 2004 06:08:35 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2NB7wq03313; Tue, 23 Mar 2004 13:07:58 +0200 Date: Tue, 23 Mar 2004 13:07:58 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: Erik Nordmark , Subject: RE: ND-proxy applicability and loop-prevention In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 23 Mar 2004, Soliman Hesham wrote: > > I don't personally think 100% link utilization is that bad a > > signal. > > => I think it's a bad signal, _if_ detected. I.e. An average > user is not even going to know that they have 100% link > utilisation. And _if_ they do, I actually think that neither > the user, nor the help desk first line of support will > have the faintest idea (having been a regular with help > desk people that work for a couple of major operators > in different countries). The user knows that all of his communication attempts fail. That's a good signal that there's something wrong. If the user knows nothing more of this, he calls helpdesk or some support, which may be able to identify the problem and eliminate it. Or, the user could read the manual for the shiny box he bough, and notice a big warning text "DON'T LINK THESE BOXES EXCEPT IN SERIES UNLESS YOU DISABLE ND-PROXYING [and instructions how to do it]" > > It rather simply conveys that "oops-- I've done something > > wrong when I > > added the box there." and after it's removed all starts to work again > > -- intuitive. > > => So if I somehow get inspired or guess that I should > remove the proxy and things work, what does that tell me??? > Maybe the device is faulty? Maybe I'll take it back to the > shop! Maybe the shop knows something about how the device operates -- they certainly should! -- or you read documentation, which should certainly describe this feature. All in all, it seems that the problem gets noticed and fixed by someone and that's what counts. > There is nothing intuitive about that from an average > user's perspective. For the average user, it doesn't have to be more intuitive than that, right? He only cares whether it works or not. In the first place 99.9% of people wouldn't be plugging these boxes in triangles (or more complex setups), so this is not commonplace. If the box "doesn't work", he complains to someone, and that someone may be able to help. In the end, the problem gets fixed in one way or the other (probably removing the unnecessary box, replacing it with another router, or putting the boxes in series, or whatever), and the user who happened to add them in the wrong configuration is happy again. -- 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 exim@www1.ietf.org Tue Mar 23 10:54:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05207 for ; Tue, 23 Mar 2004 10:54:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oEU-0000gw-Rq for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 10:54:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NFsQhe002655 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 10:54:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oEU-0000gi-9k for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 10:54:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05167 for ; Tue, 23 Mar 2004 10:54:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oER-0006Es-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 10:54:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oDZ-00067B-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 10:53:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5oCg-0005zM-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 10:52:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oCA-0000Io-EN; Tue, 23 Mar 2004 10:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oBm-0000EY-Lk for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 10:51:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04970 for ; Tue, 23 Mar 2004 10:51:34 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oBk-0005oV-00 for ipv6@ietf.org; Tue, 23 Mar 2004 10:51:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oAf-0005es-00 for ipv6@ietf.org; Tue, 23 Mar 2004 10:50:30 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B5o9n-0005VS-00 for ipv6@ietf.org; Tue, 23 Mar 2004 10:49:35 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2NFnWA09091; Tue, 23 Mar 2004 17:49:32 +0200 (EET) X-Scanned: Tue, 23 Mar 2004 17:50:54 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i2NFosW7016215; Tue, 23 Mar 2004 17:50:54 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00UbC5js; Tue, 23 Mar 2004 17:47:42 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2NFk1s20286; Tue, 23 Mar 2004 17:46:01 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Mar 2004 09:45:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: icmpv6-v3 comments Date: Tue, 23 Mar 2004 09:45:52 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F799E1@daebe009.americas.nokia.com> Thread-Topic: icmpv6-v3 comments Thread-Index: AcQQDKqLdJC2RZycQBGHZaoMmbqfhgA24pUA To: Cc: X-OriginalArrivalTime: 23 Mar 2004 15:45:53.0545 (UTC) FILETIME=[EC913790:01C410ED] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka, comments inline.. > Well, if we conclude that those are required, maybe we have to use =20 > draft-ietf-ipsec-rfc2402bis instead -- that's already been at IESG=20 > evaluation so might not end up blocking the document. I think, we should use the latest drafts instead of the old RFCs. I will update this in the next draft. > PMTUD and Addr-arch would probably have to go on Informational > section, unless we conclude that they're too strong to be used here. I don't mind moving them to informational. Will do that in the next draft if no one has any objection to this. > =20 > > > (c) If the message is a response to a message sent to=20 > an address > > > that does not belong to the node, the Source=20 > Address should be > > > that unicast address belonging to the node that=20 > will be most > > > helpful in diagnosing the error. For example, if=20 > the message is > > > a response to a packet forwarding action that=20 > cannot complete > > > successfully, the Source Address should be a=20 > unicast address > > > belonging to the interface on which the packet forwarding > > > failed. > > >=20 > > > =3D=3D> not sure if this has been implemented, so the usability=20 > > > of this generic rule seems questionable. > >=20 > > Are you proposing to remove this ? =20 >=20 > Yes. >=20 > (But if people think mentioning some optional behaviour=20 > like this is a good idea, maybe it could be reworded/ > removed in the appendix as well.) I am fine with removing this. If anyone is interested in keeping this, please let me know. > > Actually, I wanted to keep the description of the codes in=20 > the numerical > > order. If this description sounds confusing, could you=20 > suggest how to=20 > > re-word it such that it is clearer without moving the=20 > descriptions of=20 > > 4, 5 and 6 before this ? >=20 > Maybe reword: >=20 > If the reason for the failure to deliver can not be mapped=20 > to any of the specific codes listed above, the Code field=20 > is set to 3. >=20 > to: >=20 > If the reason for the failure to deliver can not be mapped=20 > to any of other codes, the Code field is set to 3. >=20 > ? Sounds good to me. > > > It SHOULD be possible for the system administrator to=20 > configure a > > > node to ignore any ICMP messages that are not=20 > authenticated using > > > either the Authentication Header or Encapsulating=20 > Security Payload. > > > Such a switch SHOULD default to allowing=20 > unauthenticated messages. > > >=20 > > > =3D=3D> has this even been implemented anywhere? could maybe be=20 > > > deleted? This is completely unpractical, e.g., just consider=20 > > > PMTU packets -- there is no way you'll ever be able to set=20 > > > up security associations with everyone in the Internet to be=20 > > > able to accept the packets :) > >=20 > > I completely agree with you that this is unpractical but it does > > make sense to a completely paranoid administrator. Whoever turns > > this option ON might not be interested in using PMTU. I don't > > see any harm in keeping it. We can make it a MAY from SHOULD. > >=20 > > What say ?? >=20 > OK -- I'm fine with putting it in as MAY, with some=20 > additional text to describe its inherent problems,=20 > e.g. like: >=20 > Note that setting up Security Associations to deal with all the=20 > required ICMP packets is a very difficult, if not even impossible,=20 > task (e.g., consider the PMTUD packets) so typically this is does=20 > not seem to be practical. I don't agree that it is completely impractical to use IPv6 without PMTUD. What about: Note that setting up Security Associations to deal with all the=20 required ICMP packets is a very difficult task (e.g., consider=20 the PMTUD packets). So PMTUD (and possibly some others) may not work if the node only allows authenticated ICMP packet. >=20 > > > [PMTU] McCann, J., S. Deering, J. Mogul, "Path=20 > MTU Discovery > > > for IP version 6", RFC1981, August 1996. > > >=20 > > > [IPv6-SA] Kent, S., R. Atkinson, "Security=20 > Architecture for the > > > Internet Protocol", RFC1825, November 1998. > > >=20 > > > =3D=3D> These, and IPsec RFCs are PS's at the moment -- can't = refer. =20 > > > IPsec ones are being revised though, if that helps any. > >=20 > > As I referred from the draft-ymbk-downref-01.txt, IPsec RFCs should > > be normative. So what should we do now ? > >=20 > > Also should we refer to the old IPsec RFCs or we should refer to the > > updated ones ? If we want to refer to updated ones, how do we refer > > to them because they are still drafts. >=20 > See above. Referring to drafts is OK as long as they don't create a=20 > blockage when this work moves forward. As the docs are already at=20 > IESG and this is not, this is (hopefully!) not a problem. Ok. Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 23 10:59:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05582 for ; Tue, 23 Mar 2004 10:59:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oJ1-0001ao-LG for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 10:59:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NFx7il006116 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 10:59:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oJ1-0001aZ-GD for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 10:59:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05549 for ; Tue, 23 Mar 2004 10:59:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oIz-0007CB-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 10:59:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oHU-0006sg-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 10:57:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5oGF-0006a1-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 10:56:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oG5-0000ql-IV; Tue, 23 Mar 2004 10:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oFw-0000o3-73 for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 10:55:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05310 for ; Tue, 23 Mar 2004 10:55:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oFt-0006V0-00 for ipv6@ietf.org; Tue, 23 Mar 2004 10:55:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oEr-0006J6-00 for ipv6@ietf.org; Tue, 23 Mar 2004 10:54:50 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B5oE6-00067P-00 for ipv6@ietf.org; Tue, 23 Mar 2004 10:54:02 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 23 Mar 2004 08:00:17 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2NFqwsk010012; Tue, 23 Mar 2004 16:52:58 +0100 (MET) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA26016; Tue, 23 Mar 2004 15:52:45 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Erik Nordmark Cc: Pekka Savola , ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention References: From: Ole Troan Date: Tue, 23 Mar 2004 15:52:45 +0000 In-Reply-To: (Erik Nordmark's message of "Mon, 22 Mar 2004 21:13:57 -0800 (PST)") Message-ID: <7t53c7zv9v6.fsf@mrwint.cisco.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > I'd sure be interested in hearing what others in the WG think > on this issue. I agree with Erik. I see two alternatives: 1. ND proxy. Limited to single router, proxy from uplink to downlink. No need for loop detection. 2. Multilink subnet routing. Handles arbitrary topologies. Must handle loops. publishing a specification for ND proxy with support for a restricted topology (multiple routers) without handling loops is just irresponsible. /ot >> > The solution you want in this space is something which allows plug&play of >> > the devices that glue together the stacking. And since you don't know how >> > the customer will plug things together, I think you must deal with loops. >> >> I have a fundamental disagreement with this. Any scenario where you >> would plug these in any other mode than in series should be strictly >> out of scope. IMHO, we don't want to deal with that. > >> If the user plugs three ND-proxies in a triangle or two (or >> more) ND-proxies in a loop, the everything breaks -- and the customer >> fixes the set-up or calls someone to fix it. Immediate failure, >> immediate fix. I see no problem with this. As it is, ND-proxy should >> never be enabled by default in any case. > > Pekka, > > elsewhere (in a mail on v6ops) you stated the concern that IPv6 might end > up with consumer-class "routers" (devices that sit between different types of > L2) that do v6-to-v6 NAT because that would be more plug and play > than the alternatives hence we need an alternative like ndproxy > (at least I think you made that argument). > > Saying that ndproxy needs to be manually enabled and can't be enabled > by default doesn't match this concern. > > I also don't see how one can prevent consumers from connecting such > devices in ways that form loops. > It *might* be sufficient if the solution could detect loops and sound the alarm > (and stop forwarding frames), but ndproxy can't even detect loops and shut > itself off. Thus when loops are formed the result is that the consumer will > see their network die (100% link utilization due to frames looping around > forever; ndproxy doesn't decrement the hop count). > > This doesn't satisfy what I think you say you want to solution to do. > > Erik > > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Tue Mar 23 11:19:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07024 for ; Tue, 23 Mar 2004 11:19:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oc4-0004F9-7z for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 11:18:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NGImeg016307 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 11:18:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oc4-0004Ew-2U for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 11:18:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06962 for ; Tue, 23 Mar 2004 11:18:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oc3-0002XI-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 11:18:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oYc-0001qM-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 11:15:15 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5oWf-0001L1-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 11:13:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5oL8-0002Wo-TF for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 11:01:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oKu-0001ra-P2; Tue, 23 Mar 2004 11:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5oJt-0001mN-QJ for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 11:00:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05620 for ; Tue, 23 Mar 2004 10:59:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oJr-0007PB-00 for ipv6@ietf.org; Tue, 23 Mar 2004 10:59:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5oIC-00071G-00 for ipv6@ietf.org; Tue, 23 Mar 2004 10:58:17 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5oGl-0006ba-00 for ipv6@ietf.org; Tue, 23 Mar 2004 10:56:48 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2NFuDw07845; Tue, 23 Mar 2004 17:56:13 +0200 Date: Tue, 23 Mar 2004 17:56:13 +0200 (EET) From: Pekka Savola To: Mukesh.Gupta@nokia.com cc: ipv6@ietf.org Subject: RE: icmpv6-v3 comments In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F799E1@daebe009.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 [snipped other parts as I trivially agree with them] On Tue, 23 Mar 2004 Mukesh.Gupta@nokia.com wrote: > > OK -- I'm fine with putting it in as MAY, with some > > additional text to describe its inherent problems, > > e.g. like: > > > > Note that setting up Security Associations to deal with all the > > required ICMP packets is a very difficult, if not even impossible, > > task (e.g., consider the PMTUD packets) so typically this is does > > not seem to be practical. > > I don't agree that it is completely impractical to use IPv6 without > PMTUD. > > What about: > > Note that setting up Security Associations to deal with all the > required ICMP packets is a very difficult task (e.g., consider > the PMTUD packets). So PMTUD (and possibly some others) may not > work if the node only allows authenticated ICMP packet. s/packet/packets/ I'm not sure if that gives a sufficiently strong disclaimer about PMTUD, but this is good enough for me at this point. -- 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 exim@www1.ietf.org Tue Mar 23 12:49:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14766 for ; Tue, 23 Mar 2004 12:49:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5q1o-00080s-Hb for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 12:49:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NHnSK5030796 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 12:49:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5q1o-00080d-Am for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 12:49:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14746 for ; Tue, 23 Mar 2004 12:49:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5q1m-000511-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 12:49:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5q0t-0004yH-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 12:48:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5q0H-0004vd-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 12:47:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5pyV-0007ST-SY; Tue, 23 Mar 2004 12:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5py6-0007Pz-BL for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 12:45:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14548 for ; Tue, 23 Mar 2004 12:45:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5py4-0004mP-00 for ipv6@ietf.org; Tue, 23 Mar 2004 12:45:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5pxB-0004iq-00 for ipv6@ietf.org; Tue, 23 Mar 2004 12:44:42 -0500 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1B5pwa-0004eB-00 for ipv6@ietf.org; Tue, 23 Mar 2004 12:44:04 -0500 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 1AAAD87BB; Tue, 23 Mar 2004 18:43:53 +0100 (CET) From: "Jeroen Massar" To: "'Ole Troan'" , "'Erik Nordmark'" Cc: "'Pekka Savola'" , Subject: RE: ND-proxy applicability and loop-prevention Date: Tue, 23 Mar 2004 18:43:08 +0100 Organization: Unfix MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <7t53c7zv9v6.fsf@mrwint.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2096 Thread-Index: AcQQ72TxwkftrO52Qh2A6Yq8ZVPqWQADTeAw Message-Id: <20040323174353.1AAAD87BB@purgatory.unfix.org> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ole Troan wrote: > > I'd sure be interested in hearing what others in the WG think > > on this issue. > > I agree with Erik. > > I see two alternatives: > > 1. ND proxy. Limited to single router, proxy from uplink to > downlink. No need for loop detection. > > 2. Multilink subnet routing. Handles arbitrary topologies. Must > handle loops. > > publishing a specification for ND proxy with support for a restricted > topology (multiple routers) without handling loops is just > irresponsible. The same applies to the current MLD proxy document (MAGMA WG). I heared a report of some person who setup ecmh on 4 different routers which then collapsed as it didn't prevent a routing loop. One easy way to do this would be define a special multicast group, to which all routers will listen, thus parse and forward these packets to their uplinks. The packet would contain the primary identification of that host and the uplink over which the packet gets sent, one could include a 'trace' of where the packet passed to aid in further diagnosis. When a router gets a packet containing it's own ID it can use the link field contained in the packet to see where it sent the packet too and then simply disable that link from being used for forwarding packets too, notifying the admin in some way or another. This at least prevents the loop from happening for too long and thus minimizes damage. This could then also be used in traceroute scenarios later on. Though mtrace is probably more suited for that situation. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Comment: Jeroen Massar / http://unfix.org/~jeroen/ iQBGBAERAgAQCRApqihSMz58IwUCQGB3LAAAv74AoJHH/Hw9oqQ7q4xL6xW7kjdA i2RlAJ0RJnMlXiOqusJRJJ3xcR7fIp2ZpA== =9/oc -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 23 13:38:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17033 for ; Tue, 23 Mar 2004 13:38:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5qmX-0004Vp-1y for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 13:37:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NIbid3017337 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 13:37:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5qmW-0004VY-KP for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 13:37:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16999 for ; Tue, 23 Mar 2004 13:37:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5qmU-0000SG-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 13:37:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5qlS-0000No-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 13:36:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5qkW-0000KL-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 13:35:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5qjw-0003qz-30; Tue, 23 Mar 2004 13:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5qjM-0003nJ-FG for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 13:34:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16924 for ; Tue, 23 Mar 2004 13:34:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5qjK-0000Gp-00 for ipv6@ietf.org; Tue, 23 Mar 2004 13:34:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5qiR-0000DZ-00 for ipv6@ietf.org; Tue, 23 Mar 2004 13:33:32 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1B5qhe-00004U-00 for ipv6@ietf.org; Tue, 23 Mar 2004 13:32:42 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 10:32:25 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Mar 2004 10:32:11 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 23 Mar 2004 10:32:02 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 23 Mar 2004 10:32:10 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 23 Mar 2004 10:30:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ND-proxy applicability and loop-prevention Date: Tue, 23 Mar 2004 10:32:08 -0800 Message-ID: Thread-Topic: ND-proxy applicability and loop-prevention thread-index: AcQQ72TxwkftrO52Qh2A6Yq8ZVPqWQADTeAwAAGYTAA= From: "Christian Huitema" To: "Jeroen Massar" , "Ole Troan" , "Erik Nordmark" Cc: "Pekka Savola" , X-OriginalArrivalTime: 23 Mar 2004 18:30:23.0465 (UTC) FILETIME=[E77F7D90:01C41104] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > One easy way to do this would be define a special multicast group, > to which all routers will listen, thus parse and forward these > packets to their uplinks. The packet would contain the primary > identification of that host and the uplink over which the packet > gets sent, one could include a 'trace' of where the packet passed > to aid in further diagnosis. When a router gets a packet containing > it's own ID it can use the link field contained in the packet to > see where it sent the packet too and then simply disable that link > from being used for forwarding packets too, notifying the admin > in some way or another. This at least prevents the loop from > happening for too long and thus minimizes damage. There are essentially two ways to break loops: either by using a "routing protocol" of some kind that imposes a correct routing structure on the set of proxies; or by using a form of "loop detection" option in the ND messages. The spanning tree algorithm is an example of the first class of solution; we could also conceivably use RIP or OSPF with host entries. I looked at the second class of solutions in a now expired draft. The basic idea is to add a "forwarded by" option in the discovery messages sent by the proxy, and to use that option to detect loops, either with a hop limit (don't forward more that N times) or with a packet inspection (don't forward what you have already forwarded once). The routing or spanning tree solution is the most transparent to the hosts, since it does not change any byte in the ND packets. However, transparency may not be entirely desired, since SEND requires being fairly explicit about relays. The "forwarded by" option is perhaps more powerful, as it allows for real-time discovery of alternate paths.=20 -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 23 14:07:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18534 for ; Tue, 23 Mar 2004 14:07:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rFF-0007Go-GS for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 14:07:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NJ7Pex027934 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 14:07:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rFE-0007GE-Rt for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 14:07:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18489 for ; Tue, 23 Mar 2004 14:07:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rFC-0002cj-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:07:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rED-0002Xs-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:06:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5rDF-0002Sx-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:05:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rBz-0006gO-3b; Tue, 23 Mar 2004 14:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rBR-0006eZ-Rg for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 14:03:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18220 for ; Tue, 23 Mar 2004 14:03:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rBP-0002Gq-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:03:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5r9Z-0002A5-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:01:33 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B5r8f-00021f-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:00:37 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2NIxUR20229; Tue, 23 Mar 2004 10:59:30 -0800 X-mProtect: <200403231859> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdk9qtmd; Tue, 23 Mar 2004 10:59:28 PST Message-ID: <40608913.7070600@iprg.nokia.com> Date: Tue, 23 Mar 2004 10:59:31 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ole Troan CC: Erik Nordmark , Pekka Savola , ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention References: <7t53c7zv9v6.fsf@mrwint.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ole Troan wrote: >>I'd sure be interested in hearing what others in the WG think >>on this issue. >> >> > >I agree with Erik. > >I see two alternatives: > > 1. ND proxy. Limited to single router, proxy from uplink to > downlink. No need for loop detection. > > 2. Multilink subnet routing. Handles arbitrary topologies. Must > handle loops. > >publishing a specification for ND proxy with support for a restricted >topology (multiple routers) without handling loops is just >irresponsible. > > In light of Pekka's suggested NDproxy caveats (e.g., put a warning label on the box, expect users to correctly interpret livelock due to looping as a configuration issue, etc.), I have to agree with this. I think the terminology may be getting a bit confusing here as well. When we say: "ND proxy", or "Multilink subnet router", we are really referring to a device that acts as an L2 bridge in some instances and inspects/modifies/responds to L3 message contents in other instances - some have even called this "L2.5", and I recall seeing the term "Brouter" used in days gone by. In any case, I really believe such devices will require mechanisms to support zero configuration and automatic topology discovery. A user should be able to just plug it in and have it work without needing a degree in network engineering to diagnose any number of esoteric problems that might crop up. This means that we need some form of loop prevention that is agile in terms of adapting to dynamic topology changes, doesn't unnecessarily disable interfaces as a means for loop prevention, and allows for neighbors to be reachable over possibly multiple interfaces. In other words, we need something like the experimental protocols coming from the MANET wg (e.g., AODV, DSR, OLSR, TBRPF). Even better would be a unified mechanism that combines the best aspects of on-demand and reactive protocols. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 23 14:10:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18668 for ; Tue, 23 Mar 2004 14:10:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rHO-0007xh-Nq for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 14:09:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NJ9c9j030603 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 14:09:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rHN-0007xS-OY for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 14:09:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18651 for ; Tue, 23 Mar 2004 14:09:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rHL-0002pf-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:09:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rGZ-0002mD-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:08:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5rFz-0002he-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:08:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rFs-0007Qm-Ey; Tue, 23 Mar 2004 14:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rFN-0007Iu-EI for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 14:07:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18507 for ; Tue, 23 Mar 2004 14:07:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rFL-0002e5-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:07:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rER-0002Zv-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:06:35 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rDl-0002TA-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:05:53 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2NJ5A311701; Tue, 23 Mar 2004 21:05:10 +0200 Date: Tue, 23 Mar 2004 21:05:10 +0200 (EET) From: Pekka Savola To: Ole Troan cc: Erik Nordmark , Subject: Re: ND-proxy applicability and loop-prevention In-Reply-To: <7t53c7zv9v6.fsf@mrwint.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 23 Mar 2004, Ole Troan wrote: > I see two alternatives: > > 1. ND proxy. Limited to single router, proxy from uplink to > downlink. No need for loop detection. > > 2. Multilink subnet routing. Handles arbitrary topologies. Must > handle loops. You cannot restrict (in protocol) that two boxes would not be deployed -- so what is the technical background to option 1)? Actually that's pretty close to what I'm saying: recommend against deploying more than one box (or even forbid it completely), but if the user deploys two boxes in any case, this would still work just as long as you don't build topologies in which routing loops would exist. I don't see that happening in the home networks. -- 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 exim@www1.ietf.org Tue Mar 23 14:22:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19420 for ; Tue, 23 Mar 2004 14:22:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rTl-0000ve-B6 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 14:22:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NJMPvI003564 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 14:22:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rTl-0000vP-67 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 14:22:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19343 for ; Tue, 23 Mar 2004 14:22:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rTi-0003kX-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:22:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rSk-0003dh-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:21:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5rRn-0003Yy-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:20:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rRV-00007S-I4; Tue, 23 Mar 2004 14:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rOF-0008PH-MY for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 14:16:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19032 for ; Tue, 23 Mar 2004 14:16:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rOC-0003NM-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:16:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rNR-0003JR-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:15:53 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rMa-0003DC-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:15:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2NJEQE11896; Tue, 23 Mar 2004 21:14:26 +0200 Date: Tue, 23 Mar 2004 21:14:26 +0200 (EET) From: Pekka Savola To: Soliman Hesham cc: Erik Nordmark , Subject: RE: ND-proxy applicability and loop-prevention In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 23 Mar 2004, Soliman Hesham wrote: > > The user knows that all of his communication attempts fail. > > That's a > > good signal that there's something wrong. If the user knows nothing > > more of this, he calls helpdesk or some support, which may > > be able to > > identify the problem and eliminate it. > > => "may" is the key word. I basically don't believe it. > I think it'll be problematic enough to be always disabled. Then they call the second-line support, and figure out the problem. If this happens commonly enough, it's going to be common knowledge to the technical folks. On the other hand, if it doesn't happen commonly enough, who cares? (Sooner or later someone is going to figure it out in any case, and the problem gets fixed shortly by removing the box from the looping topology.) > or you read documentation, which should > > certainly > > describe this feature. > > => I don't think you understant what an "average user" > means. It means, get the box, plug it in, it works! That's what ND-proxy is for, precisely. And that's how it operates in about every scenario. Are you suggesting that the scenario where an *average* home user, knowing nothing techically, would be purchasing *3* of these boxes, and plugging all of them in the home network in a topology just so that he'd create a loop? (loops with 1 or 2 boxes are so obvious I'm not don't think they're worth considering.) 1 additional box (in addition to the CPE) is common enough. 2 happens sometimes. I have trouble figuring why any *average user* would run the equivalent 3 NAT boxes (or routers) in a home network! (You and me could certainly do it, but the average home user is not you or me! :) Time for a reality check here. -- 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 exim@www1.ietf.org Tue Mar 23 14:23:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19488 for ; Tue, 23 Mar 2004 14:23:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rUB-00010o-OW for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 14:22:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NJMpKw003884 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 14:22:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rUB-00010Z-Jg for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 14:22:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19407 for ; Tue, 23 Mar 2004 14:22:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rU9-0003p6-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:22:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rTC-0003iG-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:21:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5rSP-0003cP-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rSR-0000Xf-6U; Tue, 23 Mar 2004 14:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rS5-0000LQ-5n for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 14:20:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19202 for ; Tue, 23 Mar 2004 14:20:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rS2-0003b6-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:20:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rRC-0003XQ-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:19:46 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B5rQe-0003Sd-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:19:12 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 16D0789949; Tue, 23 Mar 2004 21:19:06 +0200 (EET) Message-ID: <40608D0C.8030309@kolumbus.fi> Date: Tue, 23 Mar 2004 21:16:28 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema , Fred Templin Cc: Pekka Savola , ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christian Huitema wrote: > The routing or spanning tree solution is the most transparent to the > hosts, since it does not change any byte in the ND packets. However, > transparency may not be entirely desired, since SEND requires being > fairly explicit about relays. Yes. In fact, an explicit marker telling that there indeed was a proxy would be quite useful for SEND. Fred Templin wrote: > In other words, we need something like the experimental protocols > coming from the MANET wg (e.g., AODV, DSR, OLSR, TBRPF). > Even better would be a unified mechanism that combines the best > aspects of on-demand and reactive protocols. Hmm.... I thought the idea of ND proxies was to avoid a complicated L3 device. If we need something like a routing protocol, maybe its time to pull out the proxy thing and replace it with a real L3 device? --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 23 14:48:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21113 for ; Tue, 23 Mar 2004 14:48:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rsh-0003tX-Ht for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 14:48:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NJmB1S014971 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 14:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rsh-0003tO-An for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 14:48:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21053 for ; Tue, 23 Mar 2004 14:48:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rse-00064j-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:48:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rrL-0005rq-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:46:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5rqJ-0005kj-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 14:45:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rpi-0003GF-C0; Tue, 23 Mar 2004 14:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rlb-0002zT-B2 for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 14:40:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20567 for ; Tue, 23 Mar 2004 14:40:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rlY-0005NB-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:40:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rkc-0005IA-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:39:51 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B5rk5-0005AE-00 for ipv6@ietf.org; Tue, 23 Mar 2004 14:39:17 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2NJcb203734; Tue, 23 Mar 2004 11:38:37 -0800 X-mProtect: <200403231938> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNGP0En; Tue, 23 Mar 2004 11:38:34 PST Message-ID: <4060923B.2060204@iprg.nokia.com> Date: Tue, 23 Mar 2004 11:38:35 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: Christian Huitema , Pekka Savola , ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention References: <40608D0C.8030309@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Christian Huitema wrote: > >> The routing or spanning tree solution is the most transparent to the >> hosts, since it does not change any byte in the ND packets. However, >> transparency may not be entirely desired, since SEND requires being >> fairly explicit about relays. > > > Yes. In fact, an explicit marker telling that there indeed > was a proxy would be quite useful for SEND. The concern here is that the explicit marker may need to be carried in all packets (not just ND packets) if there are asymmetric paths, or if paths can change dynamically after the initial ND exchange. > Fred Templin wrote: > >> In other words, we need something like the experimental protocols >> coming from the MANET wg (e.g., AODV, DSR, OLSR, TBRPF). >> Even better would be a unified mechanism that combines the best >> aspects of on-demand and reactive protocols. > > > Hmm.... I thought the idea of ND proxies was to avoid a complicated > L3 device. If we need something like a routing protocol, maybe > its time to pull out the proxy thing and replace it with a real > L3 device? I did not say "L3 device", nor did I intend to imply such. While some of the protocols I was referring to include extensions for passing around L3 prefix information, their primary function is to establish host routes based on information learned from neighbors, and this can happen based on either L3 addresses or L2 addresses as node IDs. In fact, the correct target domain of application in this context would seem to be as a replacement for the IEEE 802.1D spanning tree, so L2 addressing would seem to be indicated. Fred ftemplin@iprg.nokia.com > --Jari > > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Tue Mar 23 15:38:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26283 for ; Tue, 23 Mar 2004 15:38:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sfB-00023d-31 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 15:38:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NKcHKW007909 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 15:38:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sfA-00023U-NB for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 15:38:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26268 for ; Tue, 23 Mar 2004 15:38:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sf9-00045A-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 15:38:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5seD-0003w3-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 15:37:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5scv-0003lM-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 15:35:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sc3-0001Ng-48; Tue, 23 Mar 2004 15:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sbs-0001Lz-NX for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 15:34:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25911 for ; Tue, 23 Mar 2004 15:34:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sbr-0003bS-00 for ipv6@ietf.org; Tue, 23 Mar 2004 15:34:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5say-0003Tp-00 for ipv6@ietf.org; Tue, 23 Mar 2004 15:33:57 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5saA-0003GN-00 for ipv6@ietf.org; Tue, 23 Mar 2004 15:33:07 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2NKWYUe006569 for ; Tue, 23 Mar 2004 12:32:34 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.128]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHA64268; Tue, 23 Mar 2004 15:32:33 -0500 (EST) Message-Id: <4.3.2.7.2.20040323151936.027f0c10@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Mar 2004 15:32:32 -0500 To: ipv6@ietf.org From: Ralph Droms Subject: Re: ND-proxy applicability and loop-prevention In-Reply-To: <40608D0C.8030309@kolumbus.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I reread draft-thaler-ipv6-ndproxy-02.txt, and wonder if it might be time to revisit the need for ND proxies. It seems the primary motivation for ND proxies is to avoid the need for L3 devices that require configuration, prefix assignment and configuration. I read the two scenarios in section 1, and, more generally, the motivation for ND proxies to provide bridging between links with dissimilar technologies, as motivation for the use of one ND proxy between a single upstream link (perhaps to a service provider) and one or more local networks. In the case of a more complicated local topology, it seems to me that it would be highly unusual to find dissimilar link technologies that require the use of ND proxies. Why would anything but bridgeable IEEE802 be used among the local networks? We've done the hard engineering work in specifying DHCPv6 to solve the problem of configuration and prefix delegation for a single gateway device that has an upstream PPP, cable or wireless connection and multiple downstream local networks. DHCPv6 PD is a published standard with multiple, interoperable implementations. It is available in simple home gateways, equivalent to the IPv4 NAT device in my basement. I don't see a compelling requirement to invent something new. - Ralph At 09:16 PM 3/23/2004 +0200, Jari Arkko wrote: >Hmm.... I thought the idea of ND proxies was to avoid a complicated >L3 device. If we need something like a routing protocol, maybe >its time to pull out the proxy thing and replace it with a real >L3 device? > >--Jari > > >-------------------------------------------------------------------- >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 exim@www1.ietf.org Tue Mar 23 15:50:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27943 for ; Tue, 23 Mar 2004 15:50:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sq9-000452-31 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 15:49:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NKnbJb015684 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 15:49:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sq8-00044l-V2 for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 15:49:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27868 for ; Tue, 23 Mar 2004 15:49:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5sq7-0005x7-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 15:49:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5soZ-0005e6-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 15:48:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5smr-0005Gn-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 15:46:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5smj-0002uD-Vs; Tue, 23 Mar 2004 15:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5sm3-0002mu-LE for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 15:45:23 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27094; Tue, 23 Mar 2004 15:45:20 -0500 (EST) Message-Id: <200403232045.PAA27094@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-optimistic-dad-00.txt Date: Tue, 23 Mar 2004 15:45:20 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Optimistic Duplicate Address Detection Author(s) : N. Moore Filename : draft-ietf-ipv6-optimistic-dad-00.txt Pages : 14 Date : 2004-3-23 Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbour Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case without greatly increasing disruption in the less likely failure case, and while remaining interoperable with unmodified nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-optimistic-dad-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-optimistic-dad-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-optimistic-dad-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-23155630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-optimistic-dad-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-optimistic-dad-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-23155630.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 23 17:19:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06823 for ; Tue, 23 Mar 2004 17:19:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uEt-0005vj-2n for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 17:19:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NMJF36022794 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 17:19:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5uEs-0005vZ-UJ for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 17:19:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06747 for ; Tue, 23 Mar 2004 17:19:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5uEq-0002dJ-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 17:19:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5uCj-0002HW-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 17:17:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5uBz-0002Ad-04 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 17:16:15 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5u5n-00042J-Uy for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 17:09:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5u4t-0004Xe-KE; Tue, 23 Mar 2004 17:08:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5tzz-00041e-Hj for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 17:03:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06032 for ; Tue, 23 Mar 2004 17:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5tzx-0001I4-00 for ipv6@ietf.org; Tue, 23 Mar 2004 17:03:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5tz3-0001A8-00 for ipv6@ietf.org; Tue, 23 Mar 2004 17:02:54 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B5txj-0000t9-00 for ipv6@ietf.org; Tue, 23 Mar 2004 17:01:32 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2NM0nk23916; Tue, 23 Mar 2004 14:00:49 -0800 X-mProtect: <200403232200> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtPYGt8; Tue, 23 Mar 2004 14:00:45 PST Message-ID: <4060B391.5050307@iprg.nokia.com> Date: Tue, 23 Mar 2004 14:00:49 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms CC: ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention References: <4.3.2.7.2.20040323151936.027f0c10@flask.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ralph, Ralph Droms wrote: > I reread draft-thaler-ipv6-ndproxy-02.txt, and wonder if it might be > time to > revisit the need for ND proxies. Yes, I have been wondering the same thing - perhaps not for exactly the same reasons. > It seems the primary motivation for ND proxies is to avoid the need > for L3 > devices that require configuration, prefix assignment and > configuration. I > read the two scenarios in section 1, and, more generally, the > motivation for > ND proxies to provide bridging between links with dissimilar > technologies, > as motivation for the use of one ND proxy between a single upstream link > (perhaps to a service provider) and one or more local networks. When you say "one or more local networks", are you intending to imply the possibility of multiple logical IP subnets within the local network or are you really meaning to say "one or more bridged segments of the local network" in a "flat" topology? (I guess "either/or", or "both/and" would also be reasonable answers.) Didn't ATM and NBMA networking specify the concept of Logical IP Subnets (LIS) - and what has been the operational experience with deployment of multiple LISs within a site? > In the case of a more complicated local topology, it seems to me that it > would be highly unusual to find dissimilar link technologies that require > the use of ND proxies. Why would anything but bridgeable IEEE802 be used > among the local networks? Well, we bump into the path MTU issue yet again in this case. Your local network might have media that configures a linkMTU quite a bit smaller than the IPv6 minMTU of 1280 bytes, e.g., I think IEEE 1394 fits this space, and RFC 3150 goes into other examples of such MTU-constrained media. Classical L2 bridging would say that packets too large to be forwarded onto the target segment should be dropped silently - resulting in an instant Path MTU black hole in this case. NDProxy tried to address this by asking the proxies to send ICMPv6 "packet too big" messages instead of just silent-drop. But, there are two issues with this: 1) ICMPv6 "packet too bigs" are not permitted to report a linkMTU of less than the IPv6 minMTU 2) Being able to send the ICMPv6's requires the ability to parse the L3 information in the packet and in some instances (e.g., when IPv6 header compression is used, when security transformations are used, etc.) the L3 information might not be available. This leaves us with the option of an L2 adaptation method of some sort. Jeff Mogul spoke well of this approach in his landmark: "Fragmentation Considered Harmful" paper, and it indeed seems to have been the approach adopted by ATM among others. The idea is that the device at the head of the segment with the restricting MTU fragments the packet and the device at the receiving end reassembles it. The trouble is, widely-deployed physical media (e.g., IEEE 802) may not have such an L2 adaptation scheme built-in and it's too late to go out and do a wide-scale recall now. Even if we could do such a recall, and new L2 media with mechanisms to support the adaptation were deployed, it would be unrealistic to expect network middleboxes that terminate media segments to do the reassembly due to state scaling issues. The good news is that there is a clean-and-simple way of getting the L2 adaptation we need when sending IPv6 packets over a network that might bridge heterogeneous technologies: always use IPv4 as the L2 media to carry IPv6 via IPv6-in-IPv4 tunneling (*) and let the bridges (or, IPv4 routers as the case may be) do IPv4 fragmentation. Then, the L2 adaptation scheme comes pre-configured in the guise of IPv4 fragmentation, and the reassembly always takes place at the tunnel decapsulator at the egress edge of the bridged network. (*) When the IPv6 neighbors can be assured that bridging of dissimilar media is not taking place, they can use native IPv6 instead of tunneled. > We've done the hard engineering work in specifying DHCPv6 to solve the > problem of configuration and prefix delegation for a single gateway > device > that has an upstream PPP, cable or wireless connection and multiple > downstream local networks. DHCPv6 PD is a published standard with > multiple, > interoperable implementations. It is available in simple home gateways, > equivalent to the IPv4 NAT device in my basement. I don't see a > compelling > requirement to invent something new. Denpending on how you answered my earlier question, can it be said that the DHCPv6 Relay would be the correct mechanism for deployment at the edges of LISs within the local network? Fred ftemplin@iprg.nokia.com > - Ralph > > > > > At 09:16 PM 3/23/2004 +0200, Jari Arkko wrote: > >> Hmm.... I thought the idea of ND proxies was to avoid a complicated >> L3 device. If we need something like a routing protocol, maybe >> its time to pull out the proxy thing and replace it with a real >> L3 device? >> >> --Jari >> >> >> -------------------------------------------------------------------- >> 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 exim@www1.ietf.org Wed Mar 24 03:12:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03575 for ; Wed, 24 Mar 2004 03:12:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B63Ub-0004zz-77 for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 03:12:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O8C4Pl019213 for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 03:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B63Ua-0004zo-K5 for ipv6-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 03:12:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03541 for ; Wed, 24 Mar 2004 03:12:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B63UY-00055S-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 03:12:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B63TV-0004sK-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 03:10:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B63SX-0004fU-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 03:09:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B63Rd-0004Q1-Ek; Wed, 24 Mar 2004 03:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B63Ln-0003hg-6U for ipv6@optimus.ietf.org; Wed, 24 Mar 2004 03:02:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03136 for ; Wed, 24 Mar 2004 03:02:56 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B63Lj-0003JD-00 for ipv6@ietf.org; Wed, 24 Mar 2004 03:02:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B63Km-00038H-00 for ipv6@ietf.org; Wed, 24 Mar 2004 03:01:56 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B63KO-0002yL-00 for ipv6@ietf.org; Wed, 24 Mar 2004 03:01:32 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2O81Rp03866; Wed, 24 Mar 2004 10:01:27 +0200 (EET) X-Scanned: Wed, 24 Mar 2004 10:01:16 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2O81GSl010485; Wed, 24 Mar 2004 10:01:16 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00jZeEee; Wed, 24 Mar 2004 10:01:14 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2O81Ds12887; Wed, 24 Mar 2004 10:01:13 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 24 Mar 2004 00:01:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: icmpv6-v3 comments Date: Wed, 24 Mar 2004 02:01:12 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA40154742D@daebe009.americas.nokia.com> Thread-Topic: icmpv6-v3 comments Thread-Index: AcQQ8YYq3TuxxIlOSxCX6mI42QshyAAhHQMw To: Cc: X-OriginalArrivalTime: 24 Mar 2004 08:01:12.0143 (UTC) FILETIME=[2C5EA5F0:01C41176] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > Note that setting up Security Associations to deal with all the=20 > > required ICMP packets is a very difficult task (e.g., consider=20 > > the PMTUD packets). So PMTUD (and possibly some others) may not > > work if the node only allows authenticated ICMP packet. >=20 > s/packet/packets/ >=20 > I'm not sure if that gives a sufficiently strong disclaimer about=20 > PMTUD, but this is good enough for me at this point. Sounds like we are in agreement. I will make these changes in the next draft if I don't hear any objections from anyone. Thanks again for the comments !! Regards Mukesh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 24 13:24:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11586 for ; Wed, 24 Mar 2004 13:24:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6D2J-0007Mb-E5 for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 13:23:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OINVZc028303 for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 13:23:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6D2J-0007MQ-8H for ipv6-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 13:23:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11574 for ; Wed, 24 Mar 2004 13:23:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6D2H-0002JG-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 13:23:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6D1J-0002EU-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 13:22:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6D0d-0002Ao-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 13:21:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Czv-0006zi-6O; Wed, 24 Mar 2004 13:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6CMy-0002zE-V5 for ipv6@optimus.ietf.org; Wed, 24 Mar 2004 12:40:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08479 for ; Wed, 24 Mar 2004 12:40:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6CMn-0006GV-00 for ipv6@ietf.org; Wed, 24 Mar 2004 12:40:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6CMA-0006AF-00 for ipv6@ietf.org; Wed, 24 Mar 2004 12:39:59 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B6CKv-0005tx-00 for ipv6@ietf.org; Wed, 24 Mar 2004 12:38:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2OHcAR09146; Wed, 24 Mar 2004 09:38:10 -0800 X-mProtect: <200403241738> Nokia Silicon Valley Messaging Protection Received: from walnut2.iprg.nokia.com (205.226.9.199, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpd0qbinI; Wed, 24 Mar 2004 09:38:06 PST Message-Id: <4.3.2.7.2.20040324093317.04406b50@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Mar 2004 09:37:11 -0800 To: ipv6@ietf.org From: Bob Hinden Subject: IPv6 w.g. minutes from the Seoul IETF Cc: Bob.Hinden@nokia.com, Brian Haberman Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_3137651==_" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 --=====================_3137651==_ Content-Type: text/plain; charset="us-ascii"; format=flowed IPv6 w.g. minutes from the Seoul IETF are attached. Many thinks to Karen O'Donoghue for taking the minutes. Corrections to the chairs. Thanks, Bob and Brian --=====================_3137651==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="ipv6wg-minutes-ietf59-mar2004.txt" IPv6 Working Group Meeting Notes Seoul IETF Tuesday March 2, 2004, 1545 - 1800 Chairs: Robert Hinden Brian Haberman Minutes taken by Karen O'Donoghue ------------------------------------------------------------------ Introduction and Agenda Bashing ------------------------------- Brian Haberman presented the proposed agenda. There were no comments, changes, or additions. Document Status --------------- Brian Haberman provided a link for document status to save time during the meeting. http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentStatus.html Any questions or issues can be brought up at the end of the meeting or on the mailing list. Charter Update -------------- Bob Hinden stated that an updated charter and list of milestones have been forwarded to the IESG for review. This charter added work on Duplicate Address Detection, use cases for IPv6 flow label, and an update to the IPv6 address architecture (to resolve issues raised in the IAB response to Robert Elz appeal and deprecation of site-local addresses). Pekka Savola expressed a concern about the ipv6 working group being the right place to do the work on the use case for IPv6 flow label. Perhaps this work belongs in the diffserv working group. Bob Hinden pointed out that the diffserv co-chair (Brian Carpenter) had suggested adding the flow label work item to the ipv6 charter. The work needs to be done, and there currently isn't anyone else doing it. Node Requirements, John Loughney -------------------------------- * draft-ietf-ipv6-node-requirements-08.txt * Goal: IESG comments review This draft is currently in the hands of the IESG for review. There were a number of issues including EDNSO, Path MTU Discovery, and security. The EDNSO issue was rejected. The IESG (Steve Bellovin) thought path MTU discovery is a MUST. In fact, RFC 2460 strongly recommends that IPv6 nodes implement Path MTU discovery. The resolution of this issue is to quote from RFC 2460 to strengthen the MAY. There were two security issues: 1) the crypto algorithm requirements should be better aligned with recommendations from the IPsec WG, i.e. 3DES as SHOULD not MAY; and 2) IKEv? should be a SHOULD and not a MAY. A significant amount of discussion followed that basically addressed the rules for referencing RFCs and drafts in normative text. The relevant documents from the IPsec WG are drafts that in the words of Gregory Lebovitz are fully baked and should have been in IESG hands long ago. However, Bob Hinden indicated that he was nervous doing normative references to less mature (by definition) documents thus risking holding up this document. Margaret Wasserman indicated that there were a couple of different issues including that the purpose of this document is to state what IPv6 is and not what it should be. John Loughney proposed a resolution where these topics could be left out of the part of the document where we define IPv6. They could be moved from the security section to the security considerations section. Text could be written to indicate that the security drafts are good and you should consider them. The text would be informative, and the alert reader would know what to do. This avoids the issue of what normative text can reference. John agreed to provide some recommended text to forward to the IESG review in the next few weeks. 2461bis, Hesham Soliman ----------------------- * draft-soliman-ipv6-2461-bis-01.txt * Goal: status update The aim of this effort is to fix the bugs in RFC 2461 and recycle the document as a Draft Standard. Issues include mobility (5 unresolved), security (1 mostly resolved), and miscellaneous ND issues (9, 2 unresolved). For the mobility issues, some have been addressed in the mobile IPv6 specification and the dna wg is addressing some of them. Discussion indicated that issues 256 (random delay in RS) and 258 (random delay in NS) could be resolved with a clarification. In the area of security, all references to IPsec in message validation and message format sections were removed. A new section (paragraph) describes the applicability and limitations of using IPsec. There is some remaining text on IPsec in ND, but it is a bug and should have been removed. The question for the WG is what should the keyword be for SEND - MAY, SHOULD or MUST? SHOULD was recommended by one working group member. Discussion followed on how to proceed in the area of security. Erik Nordmark asked if we are going to hold this up for the referenced documents. Pekka Savola indicated that we don't need any uppercase keyword here. Margaret Wasserman didn't fully parse the plan. It is to take out all mention of IPsec and mention SEND where? Brian Haberman indicated the SEND text could in an appendix. Bob Hinden commented that if we can't point to anything stronger perhaps taking IPsec out wasn't such a smart idea. Margaret Wasserman stated that we shouldn't pull all security information out of document. However, if we keep IPsec it just has the appearance of being secure. Margaret Wasserman stated that we were letting bookkeeping get in the way of what we really want, what we want to say is use SEND. Bob Hinden stated that what we had before with IPsec isn't very useful. Thomas Narten suggested we should provide truth in advertising, tell them what should be done, use security considerations section, vrrp has precedent for taking security out, but you need to explain why to the IESG. Jim Kempf believes this is the example of an issue the standards track working group (newtrk) should address. Someone asked if we could go back to proposed standard. Bob Hinden doesn't want to go back to PS just to deal with normative reference issue. Finally, as a miscellaneous issue, Hesham Soliman brought up that 2461 is inconsistent with ADDRARCH because it allows the prefix length to be larger than 64 bits. Bob Hinden disagreed, the /64 requirement is not for all the address space. Erik Nordmark suggested incorporating Bob's statement into the document. Discussion and issue resolution on 2461bis will continue on the list. 2462bis, Tatuya Jinmei ---------------------- * draft-ietf-ipv6-rfc2462bis-00.txt * Goal: status update The issue tracker for 2462bis is located at https://rt.psg.com (user/passwd: ietf/ietf; queue ipv6-2462bis). There are 21 issues to date with 14 resolved, 2 needing confirmation, and 5 under discussion. The 2 issues needing confirmation are 271 (stable storage for autoconfigured addresses) and 274 (conflict between MLD spec and RFC2462). The suggested resolutions will be discussed further on the mailing list. The issue of the use of DHCPv6 was discussed. Greg Daley pointed out that DHCPv6 is at Proposed Standard and should not be used as a normative reference in a Draft Standard. Hesham Soliman pointed out that there are references to DHCPv6 in ND, so maybe it should come out of that document as well. Margaret Wasserman stated that she is unhappy with the fact that we aren't doing the right thing because of the process. This issue should be raised for the newtrk effort. The suggestion was made to move the language back to referencing "the stateful configuration protocol" where "stateful" equals DHCPv6. Tatuya Jinmei plans to move the rest of the issues to the list and to separate serious issues from future extensions. The plan is to revise the draft around the end of March hopefully receive consensus to move to WG last call. ICMPv6 Updates, Bob Hinden -------------------------- * draft-ietf-ipngwg-icmp-v3-03.txt * Goal: status update Mukesh Gupta has agreed to be editor. A new draft with changes is available. These changes include updates to rate limiting methods, 2 new codes for destination unreachable messages, revised security considerations, IANA considerations, and editorial changes. The primary open issue is the IANA considerations section, how new type and message codes should be assigned. Bob Hinden proposed to reserve a set of codes for private experimentation and to reserve type 255 for future expansion. IANA should register new type codes from IETF RFC publication requests. IETF WGs with WG consensus and AD approval can request reclaimable type code assignment from the IANA. Requests for type code assignments from outside the IETF should be sent to the IETF for review. Margaret Wasserman asked if this was trying to redefine existing IANA assignment levels. Thomas Narten pointed out that what Bob is proposing goes beyond the current RFC in this area. He also indicated that this is ok and is what the IANA considerations section should be used for. Thomas also indicated that we need to find the right balance between conserving the space and making this useful, should think carefully about code assignment outside the IETF, need to understand who has the authority to say yes or no to IANA, may be ok to publish but not to use ICMP code types. Bob Hinden stated that the next step is to turn this into text and issue a WG last call. Multi-protocol getnameinfo, Jun-ichiro -------------------------------------- * draft-itojun-ipv6-getnameinfo-multiproto-01.txt * Goal: Informational Jun-ichiro pointed out that getnameinfo() API needs to be fixed. He would like to gather comments here, publish an informational RFC, and send this document to the POSIX community. Bob Hinden asked if he wanted this to become a working group item or an individual effort. Jun-ichiro indicated that either way is ok by him. Bob Hinden directed the discussion to the list. Brian Haberman indicated he would also query the mailing list about whether or not to accept the address selection API as a working group item. Load Sharing, Dave Thaler ------------------------- * draft-ietf-ipv6-host-load-sharing-01.txt * Goal: status update. Ready for last call? The issue tracker is available at www.icir.org/dthaler/RouterSelectionIssues.htm. Dave Thaler feels this is ready for last call. The discussion was primarily focused on whether load balancing should be mandatory. Pekka Savola stated that making this type of load balancing a requirement is not a good idea. Operationally load balancing is only needed when you need the capacity. It is difficult to diagnose problems when load balancing is used. It seems we only have rough consensus that load balancing is a MUST. Bob Hinden indicated that we will do a WG last call and the issue can be raised there. NDProxy, Dave Thaler -------------------- * draft-thaler-ipv6-ndproxy-02.txt * Goal: WG last call? All issues from before the last IETF are closed. New technical issues include AH removal (#12), segments with different MTUs (#13), and IPv4 support (#10). Issue 12 was resolved by removing all mention of AH removal. For issue 13, it had originally been a non-goal to support segments with different MTUs. One of the two scenarios used actually have different MTUs. To resolve this issue, Dave removed references to modifying RAS. Finally, issue 10 addressed whether IPv4 support should be left in or removed. Options include: 1) leave IPv4 in with caveat; 2) remove all mention of IPv4; and 3) put IPv4 support in an appendix. After some discussion, the chairs polled the room. Approximately 8 people felt we should remove IPv4 support, and approximately 4 people felt we should keep it in. Thomas Narten observed that it was disappointing that there were so few opinions in the room. The chairs noted that since the working group didn't have a strong opinion, we should defer to the author. The conclusion was to do a WG last call on the document. Optimistic DAD, Soohong Daniel Park and Nick Moore -------------------------------------------------- * draft-moore-ipv6-optimistic-dad-04.txt * draft-park-dna-ipv6adopt-requirements-02.txt * Goal: Informational, adopt as part of new charter? Soohong Daniel Park summarized the requirements for optimistic DAD, and Nick Moore discussed the technical details. Optimistic DAD modifies behaviours defined in RFCs 2461 and 2462. It has been implemented as a patch to Linux 2.4.19, and a number of pathological cases have been tested. Optimistic DAD has been independently implemented by Ed Remmel of Elmic Systems. Discussion followed on the merits of this work. Robert Elz wondered if the approach might actually take longer than just doing DAD in some circumstances. This topic falls into a bigger picture with different groups inside and outside of the IETF working these link layer types of topics. Erik Nordmark asked how this would work with something like SEND. Hesham Soliman felt that even though there may be some really obscure corner cases, they shouldn't stop the effort. Dave Thaler expressed concerns about the interactions with SEND. Greg Daley commented that he did a fairly thorough look through of SEND and didn't find any show stoppers. Dave Thaler indicated that he felt there is a bunch of complexity that isn't worth it. Another individual stated that the complexity is worth it for real time applications. Brian Haberman asked the working group if we should adopt this document as a working group item. The consensus was yes. SIOCGIFaaa ioctls and IPv6 interfaces, Tatuya Jinmei ---------------------------------------------------- Network applications sometimes need a list of IP addresses on nodes, and there are problems in current APIs. This is a topic that is relevant to but not specific to IPv6. Is it sensible to discuss this type of issue in the IPv6 WG? Dave Thaler feels that the POSIX community is more appropriate. Bob Hinden suggested sending the request to the mailing list. --------------------------------------------------------- In closing the meeting, Bob Hinden mentioned the IPv6 demo on 36th floor. ------------------------------------------------------------------ Meeting Adjourned ------------------------------------------------------------------ --=====================_3137651==_-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 24 13:57:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13438 for ; Wed, 24 Mar 2004 13:57:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DYI-0004eB-PN for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 13:56:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OIuY1h017862 for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 13:56:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DYI-0004e1-KG for ipv6-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 13:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13383 for ; Wed, 24 Mar 2004 13:56:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6DYG-0004yI-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 13:56:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6DXY-0004ub-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 13:55:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6DWz-0004p4-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 13:55:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DWo-0004F4-6K; Wed, 24 Mar 2004 13:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6DWA-0004Cm-5K for ipv6@optimus.ietf.org; Wed, 24 Mar 2004 13:54:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13152 for ; Wed, 24 Mar 2004 13:54:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6DW7-0004jx-00 for ipv6@ietf.org; Wed, 24 Mar 2004 13:54:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6DVD-0004dM-00 for ipv6@ietf.org; Wed, 24 Mar 2004 13:53:24 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6DUI-0004Uh-00 for ipv6@ietf.org; Wed, 24 Mar 2004 13:52:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Mar 2004 10:57:02 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2OIpsUe019850; Wed, 24 Mar 2004 10:51:54 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.128]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHB47873; Wed, 24 Mar 2004 13:51:53 -0500 (EST) Message-Id: <4.3.2.7.2.20040324133256.029626e8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Mar 2004 13:51:51 -0500 To: Fred Templin From: Ralph Droms Subject: Re: ND-proxy applicability and loop-prevention Cc: ipv6@ietf.org In-Reply-To: <4060B391.5050307@iprg.nokia.com> References: <4.3.2.7.2.20040323151936.027f0c10@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Fred... At 02:00 PM 3/23/2004 -0800, Fred Templin wrote: >Hi Ralph, > >Ralph Droms wrote: >[...] >>It seems the primary motivation for ND proxies is to avoid the need for L3 >>devices that require configuration, prefix assignment and configuration. I >>read the two scenarios in section 1, and, more generally, the motivation for >>ND proxies to provide bridging between links with dissimilar technologies, >>as motivation for the use of one ND proxy between a single upstream link >>(perhaps to a service provider) and one or more local networks. > > >When you say "one or more local networks", are you intending to imply the >possibility of multiple logical IP subnets within the local network or are you >really meaning to say "one or more bridged segments of the local network" in >a "flat" topology? (I guess "either/or", or "both/and" would also be >reasonable >answers.) Didn't ATM and NBMA networking specify the concept of Logical >IP Subnets (LIS) - and what has been the operational experience with >deployment of multiple LISs within a site? Here's the topology I'm thinking of: devices link <-customer|service provider-> ------- ---- phone\ /---------\ +-|telephony|\ phone/ \---------/ \ \ +-------+ +------+ host\ /---------\ --|gateway| |access| +-| data |-----|router |----------------|router| host/ \---------/ --| | | | / +-------+ +------+ TV\ /---------\ / +-| video |/ TV/ \---------/ The customer gateway router uses DHCPv6 PD to obtain the customer prefix (/48? or longer?) from the access router. The gateway router assigns /64s to its downstream links. Each of the downstream links is a physical link. I use separate links for telephony, data and video just as an example that I've heard used by service providers. >>In the case of a more complicated local topology, it seems to me that it >>would be highly unusual to find dissimilar link technologies that require >>the use of ND proxies. Why would anything but bridgeable IEEE802 be used >>among the local networks? > > >Well, we bump into the path MTU issue yet again in this case. Your local >network might have media that configures a linkMTU quite a bit smaller >than the IPv6 minMTU of 1280 bytes, e.g., I think IEEE 1394 fits this space, >and RFC 3150 goes into other examples of such MTU-constrained media. > >Classical L2 bridging would say that packets too large to be forwarded >onto the target segment should be dropped silently - resulting in an instant >Path MTU black hole in this case. Sounds to me like a hardware problem. Why should we try to hack a solution into IPv6? But that's my off-the-cuff answer. I'll review IEEE 1394 and read RFC3150. >NDProxy tried to address this by asking the proxies to send ICMPv6 >"packet too big" messages instead of just silent-drop. But, there are >two issues with this: > > 1) ICMPv6 "packet too bigs" are not permitted to report a linkMTU > of less than the IPv6 minMTU > 2) Being able to send the ICMPv6's requires the ability to parse the L3 > information in the packet and in some instances (e.g., when IPv6 header > compression is used, when security transformations are used, etc.) the > L3 information might not be available. > >This leaves us with the option of an L2 adaptation method of some sort. >Jeff Mogul spoke well of this approach in his landmark: "Fragmentation >Considered Harmful" paper, and it indeed seems to have been the approach >adopted by ATM among others. The idea is that the device at the head of >the segment with the restricting MTU fragments the packet and the device >at the receiving end reassembles it. The trouble is, widely-deployed physical >media (e.g., IEEE 802) may not have such an L2 adaptation scheme built-in >and it's too late to go out and do a wide-scale recall now. Even if we could >do such a recall, and new L2 media with mechanisms to support the >adaptation were deployed, it would be unrealistic to expect network >middleboxes that terminate media segments to do the reassembly due >to state scaling issues. > >The good news is that there is a clean-and-simple way of getting the L2 >adaptation we need when sending IPv6 packets over a network that might >bridge heterogeneous technologies: always use IPv4 as the L2 media to carry >IPv6 via IPv6-in-IPv4 tunneling (*) and let the bridges (or, IPv4 routers >as the >case may be) do IPv4 fragmentation. Then, the L2 adaptation scheme comes >pre-configured in the guise of IPv4 fragmentation, and the reassembly always >takes place at the tunnel decapsulator at the egress edge of the bridged >network. > >(*) When the IPv6 neighbors can be assured that bridging of dissimilar > media is not taking place, they can use native IPv6 instead of tunneled. When are you suggesting the use of IPv6-in-IPv4 tunneling? >>We've done the hard engineering work in specifying DHCPv6 to solve the >>problem of configuration and prefix delegation for a single gateway device >>that has an upstream PPP, cable or wireless connection and multiple >>downstream local networks. DHCPv6 PD is a published standard with multiple, >>interoperable implementations. It is available in simple home gateways, >>equivalent to the IPv4 NAT device in my basement. I don't see a compelling >>requirement to invent something new. > > >Denpending on how you answered my earlier question, can it be said that >the DHCPv6 Relay would be the correct mechanism for deployment at >the edges of LISs within the local network? I don't quite understand: DHCPv6 relay for what function? >Fred >ftemplin@iprg.nokia.com > >>- Ralph >> >> >> >> >>At 09:16 PM 3/23/2004 +0200, Jari Arkko wrote: >> >>>Hmm.... I thought the idea of ND proxies was to avoid a complicated >>>L3 device. If we need something like a routing protocol, maybe >>>its time to pull out the proxy thing and replace it with a real >>>L3 device? >>> >>>--Jari >>> >>> >>>-------------------------------------------------------------------- >>>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 exim@www1.ietf.org Wed Mar 24 14:38:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15606 for ; Wed, 24 Mar 2004 14:38:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ECq-0000V4-R6 for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 14:38:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OJcSNr001916 for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 14:38:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ECq-0000Up-KI for ipv6-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 14:38:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15585 for ; Wed, 24 Mar 2004 14:38:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ECn-0000bD-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 14:38:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6EBw-0000To-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 14:37:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6EAx-0000N6-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 14:36:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6EAU-00083d-J1; Wed, 24 Mar 2004 14:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6E9q-0007sC-28 for ipv6@optimus.ietf.org; Wed, 24 Mar 2004 14:35:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15310 for ; Wed, 24 Mar 2004 14:35:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6E9n-0000FU-00 for ipv6@ietf.org; Wed, 24 Mar 2004 14:35:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6E8m-00009L-00 for ipv6@ietf.org; Wed, 24 Mar 2004 14:34:17 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B6E7n-0007n9-00 for ipv6@ietf.org; Wed, 24 Mar 2004 14:33:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2OJWb421495; Wed, 24 Mar 2004 11:32:37 -0800 X-mProtect: <200403241932> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9d7OsE; Wed, 24 Mar 2004 11:32:34 PST Message-ID: <4061E259.80408@iprg.nokia.com> Date: Wed, 24 Mar 2004 11:32:41 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms CC: ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention References: <4.3.2.7.2.20040323151936.027f0c10@flask.cisco.com> <4.3. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ralph, A few quick follow-ups appear below: Ralph Droms wrote: > Hi, Fred... > > At 02:00 PM 3/23/2004 -0800, Fred Templin wrote: > >> Hi Ralph, >> >> Ralph Droms wrote: >> [...] >> >>> It seems the primary motivation for ND proxies is to avoid the need >>> for L3 >>> devices that require configuration, prefix assignment and >>> configuration. I >>> read the two scenarios in section 1, and, more generally, the >>> motivation for >>> ND proxies to provide bridging between links with dissimilar >>> technologies, >>> as motivation for the use of one ND proxy between a single upstream >>> link >>> (perhaps to a service provider) and one or more local networks. >> >> >> >> When you say "one or more local networks", are you intending to imply >> the >> possibility of multiple logical IP subnets within the local network >> or are you >> really meaning to say "one or more bridged segments of the local >> network" in >> a "flat" topology? (I guess "either/or", or "both/and" would also be >> reasonable >> answers.) Didn't ATM and NBMA networking specify the concept of Logical >> IP Subnets (LIS) - and what has been the operational experience with >> deployment of multiple LISs within a site? > > > Here's the topology I'm thinking of: > > > devices link <-customer|service provider-> > ------- ---- > > phone\ /---------\ > +-|telephony|\ > phone/ \---------/ \ > \ +-------+ +------+ > host\ /---------\ --|gateway| |access| > +-| data |-----|router |----------------|router| > host/ \---------/ --| | | | > / +-------+ +------+ > TV\ /---------\ / > +-| video |/ > TV/ \---------/ > > The customer gateway router uses DHCPv6 PD to obtain the customer prefix > (/48? or longer?) from the access router. The gateway router assigns > /64s > to its downstream links. Each of the downstream links is a physical > link. > I use separate links for telephony, data and video just as an example > that > I've heard used by service providers. OK, but I don't expect this would be the only configuration encountered in practical deployments. I'm thinking that integrated voice/video/data would be multiplexed over a common infrastructure in many cases. >>> In the case of a more complicated local topology, it seems to me >>> that it >>> would be highly unusual to find dissimilar link technologies that >>> require >>> the use of ND proxies. Why would anything but bridgeable IEEE802 be >>> used >>> among the local networks? >> >> >> >> Well, we bump into the path MTU issue yet again in this case. Your local >> network might have media that configures a linkMTU quite a bit smaller >> than the IPv6 minMTU of 1280 bytes, e.g., I think IEEE 1394 fits this >> space, >> and RFC 3150 goes into other examples of such MTU-constrained media. >> >> Classical L2 bridging would say that packets too large to be forwarded >> onto the target segment should be dropped silently - resulting in an >> instant >> Path MTU black hole in this case. > > > Sounds to me like a hardware problem. Why should we try to hack a > solution > into IPv6? But that's my off-the-cuff answer. I'll review IEEE 1394 and > read RFC3150. Not suggesting any solution for IPv6 because there is none. Any L2 bridge that connects media with dissimilar MTUs and does silent-drop will cause PMTUD black holes that cannot be detected as anything other than loss due to an indeterminant reason. So, I have to believe that such L2 bridges probably don't exist in wide-scale deployment (although I know of some that were around a couple of decades ago). >> NDProxy tried to address this by asking the proxies to send ICMPv6 >> "packet too big" messages instead of just silent-drop. But, there are >> two issues with this: >> >> 1) ICMPv6 "packet too bigs" are not permitted to report a linkMTU >> of less than the IPv6 minMTU >> 2) Being able to send the ICMPv6's requires the ability to parse the L3 >> information in the packet and in some instances (e.g., when IPv6 >> header >> compression is used, when security transformations are used, etc.) >> the >> L3 information might not be available. >> >> This leaves us with the option of an L2 adaptation method of some sort. >> Jeff Mogul spoke well of this approach in his landmark: "Fragmentation >> Considered Harmful" paper, and it indeed seems to have been the approach >> adopted by ATM among others. The idea is that the device at the head of >> the segment with the restricting MTU fragments the packet and the device >> at the receiving end reassembles it. The trouble is, widely-deployed >> physical >> media (e.g., IEEE 802) may not have such an L2 adaptation scheme >> built-in >> and it's too late to go out and do a wide-scale recall now. Even if >> we could >> do such a recall, and new L2 media with mechanisms to support the >> adaptation were deployed, it would be unrealistic to expect network >> middleboxes that terminate media segments to do the reassembly due >> to state scaling issues. >> >> The good news is that there is a clean-and-simple way of getting the L2 >> adaptation we need when sending IPv6 packets over a network that might >> bridge heterogeneous technologies: always use IPv4 as the L2 media to >> carry >> IPv6 via IPv6-in-IPv4 tunneling (*) and let the bridges (or, IPv4 >> routers as the >> case may be) do IPv4 fragmentation. Then, the L2 adaptation scheme comes >> pre-configured in the guise of IPv4 fragmentation, and the reassembly >> always >> takes place at the tunnel decapsulator at the egress edge of the >> bridged network. >> >> (*) When the IPv6 neighbors can be assured that bridging of dissimilar >> media is not taking place, they can use native IPv6 instead of >> tunneled. > > > When are you suggesting the use of IPv6-in-IPv4 tunneling? When the neighbor does not respond to native (i.e., non-tunneled) IPv6 ND messages. >>> We've done the hard engineering work in specifying DHCPv6 to solve the >>> problem of configuration and prefix delegation for a single gateway >>> device >>> that has an upstream PPP, cable or wireless connection and multiple >>> downstream local networks. DHCPv6 PD is a published standard with >>> multiple, >>> interoperable implementations. It is available in simple home >>> gateways, >>> equivalent to the IPv4 NAT device in my basement. I don't see a >>> compelling >>> requirement to invent something new. >> >> >> >> Denpending on how you answered my earlier question, can it be said that >> the DHCPv6 Relay would be the correct mechanism for deployment at >> the edges of LISs within the local network? > > > I don't quite understand: DHCPv6 relay for what function? The relay provides the edge of the broadcast domain for service discovery. In other words, when a node within the LIS boots up and has no configuration information, it can send a broadcast/multicast service discovery message which will hopefully be flooded within the LIS but no further. (The relay can then forward the service discovery message on to the server if needs-be.) Some of these recent "flooding" proposals from the MANET wg might be useful for this. Then again, there might alread be some existing mechanisms, e.g., something from the ZEROUTER wg. Would welcome any pointers to doc's you think I should read, but will go check on my own in the meantime... Thanks - Fred ftemplin@iprg.nokia.com >> Fred >> ftemplin@iprg.nokia.com >> >>> - Ralph >>> >>> >>> >>> >>> At 09:16 PM 3/23/2004 +0200, Jari Arkko wrote: >>> >>>> Hmm.... I thought the idea of ND proxies was to avoid a complicated >>>> L3 device. If we need something like a routing protocol, maybe >>>> its time to pull out the proxy thing and replace it with a real >>>> L3 device? >>>> >>>> --Jari >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 24 22:52:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11564 for ; Wed, 24 Mar 2004 22:52:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LuF-0001ej-7J for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 22:51:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P3pljb006362 for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 22:51:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LuE-0001eX-Um for ipv6-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 22:51:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11549 for ; Wed, 24 Mar 2004 22:51:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6LuB-0000cD-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 22:51:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6LtS-0000Y5-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 22:50:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Lsw-0000Sr-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 22:50:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Lsb-00011L-9n; Wed, 24 Mar 2004 22:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LsK-0000zn-Vj for ipv6@optimus.ietf.org; Wed, 24 Mar 2004 22:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11433 for ; Wed, 24 Mar 2004 22:49:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6LsH-0000Pu-00 for ipv6@ietf.org; Wed, 24 Mar 2004 22:49:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6LrM-0000KR-00 for ipv6@ietf.org; Wed, 24 Mar 2004 22:48:49 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1B6Lqa-0000B3-00 for ipv6@ietf.org; Wed, 24 Mar 2004 22:48:00 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2P3lLng025743; Wed, 24 Mar 2004 19:47:22 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2P3lJQ28300; Thu, 25 Mar 2004 04:47:19 +0100 (MET) Date: Wed, 24 Mar 2004 13:58:53 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND-proxy applicability and loop-prevention To: Ole Troan Cc: Erik Nordmark , Pekka Savola , ipv6@ietf.org In-Reply-To: "Your message with ID" <7t53c7zv9v6.fsf@mrwint.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 > I agree with Erik. Good :-) > I see two alternatives: > > 1. ND proxy. Limited to single router, proxy from uplink to > downlink. No need for loop detection. > > 2. Multilink subnet routing. Handles arbitrary topologies. Must > handle loops. Agreed. But furthermore I actually don't see the utility of #1. First of all, based on RFC 3177 an ISP needs to be capable of handing of /48 prefixes to customers. The issue here is when the ISP doesn't do that. The unstated assumption for #1 seems to be that an ISP (that uses a form service differentiation I disagree with but that is beside the point) can not assign a single IPv6 address to one of their customers but is somehow forced to at least hand out a /64 because it needs to assign a /64 to the link between the ISP and the customer. I think this assumption is false. An router does not need to advertise an on-link prefix for the link between it and the client. The client machine does need to be able to allocate an IP address which is easy without an on-link prefix when using DHCPv6, and a bit more subtle using stateless address autoconfiguration. (The issue is how the host autoconfiguring an address effects the routing on the ISP side.) Thus I think the ISP that wants to charge differently for one IPv6 address per customer compared to a /64 or /48 prefix can do this as easily as it can in IPv4. This implies that ISPs that want to hand out /64 or /48 prefixes should use an explicit prefix delegation mechanism which explicitly delegates the prefix to the customer and not implicitly does this by assigning a /64 to the link between the ISP and the customer. Hence ndproxy at the router the customer has on the link to the ISP isn't necessary. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 24 22:52:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11581 for ; Wed, 24 Mar 2004 22:52:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LuI-0001fK-TQ for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 22:51:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P3poMe006396 for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 22:51:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LuI-0001f5-OY for ipv6-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 22:51:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11558 for ; Wed, 24 Mar 2004 22:51:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6LuF-0000cd-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 22:51:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6LtU-0000YQ-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 22:51:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Lsw-0000Su-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 22:50:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LsY-00010V-4g; Wed, 24 Mar 2004 22:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ls8-0000z3-NS for ipv6@optimus.ietf.org; Wed, 24 Mar 2004 22:49:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11404 for ; Wed, 24 Mar 2004 22:49:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ls5-0000Ot-00 for ipv6@ietf.org; Wed, 24 Mar 2004 22:49:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Lr8-0000IU-00 for ipv6@ietf.org; Wed, 24 Mar 2004 22:48:35 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B6LqE-0000Dm-00 for ipv6@ietf.org; Wed, 24 Mar 2004 22:47:38 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2P3lWp9013156; Wed, 24 Mar 2004 20:47:33 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2P3lUQ28305; Thu, 25 Mar 2004 04:47:30 +0100 (MET) Date: Wed, 24 Mar 2004 14:06:54 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: ND-proxy applicability and loop-prevention To: Pekka Savola Cc: Soliman Hesham , Erik Nordmark , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 > The user knows that all of his communication attempts fail. That's a > good signal that there's something wrong. If the user knows nothing > more of this, he calls helpdesk or some support, which may be able to > identify the problem and eliminate it. Which help desk should my grandmother call when this happens? The ISP? The vendor for her Tivo-like box? The OS vendor for the laptop? I think what we want is the complexity equivalent of plugging together electrical extension cords. Looking at Ethernet we don't have the male/female distinction on the plugs hence it is a lot easier to create Ethernet loops than power extension cord loops. Combining this with wireless makes it even more likely that there will be accidental loops. > For the average user, it doesn't have to be more intuitive than that, > right? He only cares whether it works or not. In the first place > 99.9% of people wouldn't be plugging these boxes in triangles (or more > complex setups), so this is not commonplace. If the box "doesn't > work", he complains to someone, and that someone may be able to help. Given that we don't even know what such boxes will look like in 10+ years, how can we determine that people would not "plug" them together? Perhaps this ability to connect multiple wired and wireless media will be to cheap that every laptop, TV and stereo will include it. (Many things that don't run on batteries might have such functionality for all I can predict.) Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Wed Mar 24 22:52:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11597 for ; Wed, 24 Mar 2004 22:52:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LuG-0001f4-NI for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 22:51:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P3pmmZ006380 for ipv6-archive@odin.ietf.org; Wed, 24 Mar 2004 22:51:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LuG-0001ep-Gl for ipv6-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 22:51:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11552 for ; Wed, 24 Mar 2004 22:51:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6LuD-0000cQ-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 22:51:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6LtT-0000YG-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 22:51:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Lsw-0000Ss-00 for ipv6-web-archive@ietf.org; Wed, 24 Mar 2004 22:50:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LsZ-00010y-G2; Wed, 24 Mar 2004 22:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Ls9-0000z8-8T for ipv6@optimus.ietf.org; Wed, 24 Mar 2004 22:49:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11407 for ; Wed, 24 Mar 2004 22:49:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Ls5-0000Oy-00 for ipv6@ietf.org; Wed, 24 Mar 2004 22:49:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Lr9-0000Ih-00 for ipv6@ietf.org; Wed, 24 Mar 2004 22:48:36 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B6LqG-0000EB-00 for ipv6@ietf.org; Wed, 24 Mar 2004 22:47:40 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2P3lap9013170; Wed, 24 Mar 2004 20:47:37 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2P3lXQ28312; Thu, 25 Mar 2004 04:47:34 +0100 (MET) Date: Wed, 24 Mar 2004 14:21:12 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: ND-proxy applicability and loop-prevention To: Christian Huitema Cc: Jeroen Massar , Ole Troan , Erik Nordmark , Pekka Savola , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 > There are essentially two ways to break loops: either by using a > "routing protocol" of some kind that imposes a correct routing structure > on the set of proxies; or by using a form of "loop detection" option in > the ND messages. The spanning tree algorithm is an example of the first > class of solution; we could also conceivably use RIP or OSPF with host > entries. And RBridges argues that one can do this without any changes on hosts or routers; they see the same behavior as without the RBridges even though the RBridges use a routing protocol (on L2 and/or L3 addresses) between eachother. > I looked at the second class of solutions in a now expired draft. The > basic idea is to add a "forwarded by" option in the discovery messages > sent by the proxy, and to use that option to detect loops, either with a > hop limit (don't forward more that N times) or with a packet inspection > (don't forward what you have already forwarded once). If one were do to a loop detection scheme something like that would make sense. > The routing or spanning tree solution is the most transparent to the > hosts, since it does not change any byte in the ND packets. However, > transparency may not be entirely desired, since SEND requires being > fairly explicit about relays. The "forwarded by" option is perhaps more > powerful, as it allows for real-time discovery of alternate paths. I guess I don't understand the need for explicit relays. SEND works over existing L2 bridges - it can't even see that they are there. (As a result there are L2 derived security issues - you can "redirect" things at L2 unless L2 is somehow secure.) I guess I don't understand the tradeoffs between running SEND over a larger transparently "bridged" LAN vs. using "relays" that are visible to SEND. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 25 01:23:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18219 for ; Thu, 25 Mar 2004 01:23:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OGa-0005nG-Ep for ipv6-archive@odin.ietf.org; Thu, 25 Mar 2004 01:23:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P6N00k022269 for ipv6-archive@odin.ietf.org; Thu, 25 Mar 2004 01:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OGa-0005n6-85 for ipv6-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 01:23:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18205 for ; Thu, 25 Mar 2004 01:22:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OGX-00069J-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 01:22:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6OFW-000638-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 01:21:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6OEu-0005yb-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 01:21:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OEg-0005Qe-LI; Thu, 25 Mar 2004 01:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OEN-0005QB-IF for ipv6@optimus.ietf.org; Thu, 25 Mar 2004 01:20:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18120 for ; Thu, 25 Mar 2004 01:20:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OEK-0005xV-00 for ipv6@ietf.org; Thu, 25 Mar 2004 01:20:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ODU-0005ti-00 for ipv6@ietf.org; Thu, 25 Mar 2004 01:19:49 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OCm-0005ia-00 for ipv6@ietf.org; Thu, 25 Mar 2004 01:19:05 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2P6IRG13566; Thu, 25 Mar 2004 08:18:27 +0200 Date: Thu, 25 Mar 2004 08:18:27 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Soliman Hesham , Subject: RE: ND-proxy applicability and loop-prevention In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 24 Mar 2004, Erik Nordmark wrote: > > The user knows that all of his communication attempts fail. That's a > > good signal that there's something wrong. If the user knows nothing > > more of this, he calls helpdesk or some support, which may be able to > > identify the problem and eliminate it. > > Which help desk should my grandmother call when this happens? > The ISP? The vendor for her Tivo-like box? The OS vendor for the laptop? The same helpdesk she calls when she encounters a weird problem in her network connectivity, or in her PC. Most likely you ;-) (This is a much more generic problem, not one specific to this scenario, obviously.) > Given that we don't even know what such boxes will look like in 10+ years, > how can we determine that people would not "plug" them together? > Perhaps this ability to connect multiple wired and wireless media > will be to cheap that every laptop, TV and stereo will include it. > (Many things that don't run on batteries might have such functionality > for all I can predict.) You are making assumption that those boxes would also be acting as routers (in the ND-proxy mode) by default, right? I don't, and I don't think doing that would make a lot of sense. -- 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 exim@www1.ietf.org Thu Mar 25 01:40:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19068 for ; Thu, 25 Mar 2004 01:40:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OWv-0007j1-Oj for ipv6-archive@odin.ietf.org; Thu, 25 Mar 2004 01:39:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P6drVK029689 for ipv6-archive@odin.ietf.org; Thu, 25 Mar 2004 01:39:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OWv-0007im-IU for ipv6-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 01:39:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19044 for ; Thu, 25 Mar 2004 01:39:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OWs-0007gT-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 01:39:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6OVx-0007ab-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 01:38:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6OVD-0007V8-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 01:38:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OV9-0007OB-MJ; Thu, 25 Mar 2004 01:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OV1-0007Jy-0E for ipv6@optimus.ietf.org; Thu, 25 Mar 2004 01:37:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18893 for ; Thu, 25 Mar 2004 01:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OUx-0007SO-00 for ipv6@ietf.org; Thu, 25 Mar 2004 01:37:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6OU2-0007LA-00 for ipv6@ietf.org; Thu, 25 Mar 2004 01:36:55 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OT2-00079Q-00 for ipv6@ietf.org; Thu, 25 Mar 2004 01:35:52 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2P6ZC713815; Thu, 25 Mar 2004 08:35:12 +0200 Date: Thu, 25 Mar 2004 08:35:12 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Ole Troan , Subject: Re: ND-proxy applicability and loop-prevention In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 24 Mar 2004, Erik Nordmark wrote: > First of all, based on RFC 3177 an ISP needs to be capable of handing of > /48 prefixes to customers. The issue here is when the ISP doesn't do that. Precisely. [...] > I think this assumption is false. An router does not need to advertise an > on-link prefix for the link between it and the client. > The client machine does need to be able to allocate an IP address > which is easy without an on-link prefix when using DHCPv6, > and a bit more subtle using stateless address autoconfiguration. > (The issue is how the host autoconfiguring an address effects the routing > on the ISP side.) Stateless address autoconfig mode you're talking about is about advertising a /64 prefix on the link, with addrconfig flag set, and onlink flag not set --right? While the onlink flag gives no information how the hosts could communicate between themselves, it still gives the ability to connect multiple hosts on a link -- so it cannot be used by the ISPs to force "1 user/prefix" -model, right? So, this doesn't seem to have practical benefits to just advertising a /64 on the link. (The difference is just that without on-link flag, the hosts should communicate between themselves through the default router.) > Thus I think the ISP that wants to charge differently for one IPv6 address > per customer compared to a /64 or /48 prefix can do this as easily as it > can in IPv4. I don't know how this relates to the above, but this seems obvious. The point, however, is whether that /64 is really restricted to that link or not. I.e., whether this is a weak form of "one host only" model or not. (Assuming the subnet can't be extended, the customer can't use his own proxies, firewalls, or the like, but would have to plug all the devices in parallel.) > This implies that ISPs that want to hand out /64 or /48 prefixes > should use an explicit prefix delegation mechanism which explicitly > delegates the prefix to the customer and not implicitly does this > by assigning a /64 to the link between the ISP and the customer. This is indeed a "should". But the point is -- do we want to provide a solution for the case where this "should" does not hold? Note that the ND-proxy case is rather strong in 3GPP environments as well: the nodes are given a /64 per PDP context. If you want to hook up your laptop to your mobile (which has v6 PDP context), the mobile either has to do ND proxying, or you'll have to open a new PDP context on your laptop (e.g., of PPP type). And those 3GPP guys always start screaming when you want to open more PDP contexts.. :) -- 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 exim@www1.ietf.org Thu Mar 25 01:49:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19600 for ; Thu, 25 Mar 2004 01:49:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OfY-0000Ex-Gd for ipv6-archive@odin.ietf.org; Thu, 25 Mar 2004 01:48:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P6mmJZ000917 for ipv6-archive@odin.ietf.org; Thu, 25 Mar 2004 01:48:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6OfY-0000Eh-Bs for ipv6-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 01:48:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19585 for ; Thu, 25 Mar 2004 01:48:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6OfV-0000ff-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 01:48:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Oec-0000bc-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 01:47:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Odr-0000Wy-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 01:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Odq-0008LQ-OY; Thu, 25 Mar 2004 01:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Odk-0008Kk-4m for ipv6@optimus.ietf.org; Thu, 25 Mar 2004 01:46:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19486 for ; Thu, 25 Mar 2004 01:46:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Odg-0000Vt-00 for ipv6@ietf.org; Thu, 25 Mar 2004 01:46:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Oco-0000Qv-00 for ipv6@ietf.org; Thu, 25 Mar 2004 01:45:58 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B6OcQ-0000LT-00 for ipv6@ietf.org; Thu, 25 Mar 2004 01:45:34 -0500 content-class: urn:content-classes:message Subject: RE: ND-proxy applicability and loop-prevention Date: Thu, 25 Mar 2004 01:45:05 -0500 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: ND-proxy applicability and loop-prevention Thread-Index: AcQSM9TuCedPirhdSdaeMgNHPlfl5wAAKhZA From: "Soliman Hesham" To: "Pekka Savola" , "Erik Nordmark" Cc: "Ole Troan" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Note that the ND-proxy case is rather strong in 3GPP environments as=20 > well: the nodes are given a /64 per PDP context. If you=20 > want to hook=20 > up your laptop to your mobile (which has v6 PDP context), the mobile=20 > either has to do ND proxying, or you'll have to open a new=20 > PDP context=20 > on your laptop (e.g., of PPP type). =20 =3D> That's not correct. The mobile gets a /64. The 3GPP network should use that /64 to identify the mobile (I don't know if that contribution was eventually adopted or not). The mobile can then advertise that /64 to the laptop or other devices behind it. The mobile=20 can then act as a router. The 3GPP network has no idea if the mobile is using 3041 addresses or another device=20 behind it is using those addresses. This was one of the main reasons for pushing for the /64 delegation. Hesham And those 3GPP guys=20 > always start=20 > screaming when you want to open more PDP contexts.. :) >=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 >=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 exim@www1.ietf.org Thu Mar 25 23:11:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13940 for ; Thu, 25 Mar 2004 23:11:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ig7-0000O9-Gl for ipv6-archive@odin.ietf.org; Thu, 25 Mar 2004 23:10:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q4Ahnw001487 for ipv6-archive@odin.ietf.org; Thu, 25 Mar 2004 23:10:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ig7-0000Nu-AT for ipv6-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 23:10:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13887 for ; Thu, 25 Mar 2004 23:10:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ig3-0001Dy-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 23:10:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6if5-00019B-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 23:09:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6ieA-00014r-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 23:08:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6idX-0008Ih-Mn; Thu, 25 Mar 2004 23:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6idF-0008Cj-BW for ipv6@optimus.ietf.org; Thu, 25 Mar 2004 23:07:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13690 for ; Thu, 25 Mar 2004 23:07:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6idB-0000yq-00 for ipv6@ietf.org; Thu, 25 Mar 2004 23:07:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6icG-0000tk-00 for ipv6@ietf.org; Thu, 25 Mar 2004 23:06:44 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1B6ibH-0000mf-00 for ipv6@ietf.org; Thu, 25 Mar 2004 23:05:43 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2Q456ng004050; Thu, 25 Mar 2004 20:05:06 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2Q453Q20387; Fri, 26 Mar 2004 05:05:03 +0100 (MET) Date: Thu, 25 Mar 2004 15:55:19 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: ND-proxy applicability and loop-prevention To: Pekka Savola Cc: Erik Nordmark , Soliman Hesham , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 > The same helpdesk she calls when she encounters a weird problem in her > network connectivity, or in her PC. Most likely you ;-) > > (This is a much more generic problem, not one specific to this > scenario, obviously.) But in this particular case you seem to be arguing that plug&pray is sufficient while I argue that we should aim for plug&play; I think the futuristic goal is that wiring together network devices shouldn't be more complex than plugging in electrical appliances. > You are making assumption that those boxes would also be acting as > routers (in the ND-proxy mode) by default, right? I don't, and I > don't think doing that would make a lot of sense. No. I'm only making the same assumption that underlies ndproxy as well as the zerouter discussion; there will be L2s that do not support IEEE 802 bridging. If you disagree with this assumption we don't need ndproxy or zerouter for the home networking case - IEEE 802 bridging has already solved the problem. Given that you have different types of L2s in common use in the home, a subset of of consumer electronics will connect to multiple types of L2s. Question is what these boxes implement to make the home network plug&play. I'm not assuming the solution will be at L3; there are L2.5 solutions possible as well. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Thu Mar 25 23:58:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13942 for ; Thu, 25 Mar 2004 23:11:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ig8-0000OR-6q for ipv6-archive@odin.ietf.org; Thu, 25 Mar 2004 23:10:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q4Aitn001505 for ipv6-archive@odin.ietf.org; Thu, 25 Mar 2004 23:10:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ig7-0000OC-Vl for ipv6-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 23:10:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13890 for ; Thu, 25 Mar 2004 23:10:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ig4-0001E3-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 23:10:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6if6-00019J-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 23:09:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6ieA-00014s-00 for ipv6-web-archive@ietf.org; Thu, 25 Mar 2004 23:08:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6idW-0008Hy-7N; Thu, 25 Mar 2004 23:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6idD-0008CO-Lx for ipv6@optimus.ietf.org; Thu, 25 Mar 2004 23:07:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13687 for ; Thu, 25 Mar 2004 23:07:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6id9-0000yg-00 for ipv6@ietf.org; Thu, 25 Mar 2004 23:07:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6icE-0000tU-00 for ipv6@ietf.org; Thu, 25 Mar 2004 23:06:43 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1B6ibF-0000me-00 for ipv6@ietf.org; Thu, 25 Mar 2004 23:05:41 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2Q452WA027934; Thu, 25 Mar 2004 20:05:03 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2Q44xQ20383; Fri, 26 Mar 2004 05:05:00 +0100 (MET) Date: Thu, 25 Mar 2004 15:55:12 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND-proxy applicability and loop-prevention To: Pekka Savola Cc: Erik Nordmark , Ole Troan , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.60 > Stateless address autoconfig mode you're talking about is about > advertising a /64 prefix on the link, with addrconfig flag set, and > onlink flag not set --right? While the onlink flag gives no > information how the hosts could communicate between themselves, it > still gives the ability to connect multiple hosts on a link -- so it > cannot be used by the ISPs to force "1 user/prefix" -model, right? Not if the link to the ISP is a pt-pt link, and all the case I've seen, even if the L2 is broadcast capable such as in cable networks, the topology visible to IP seems to be pt-pt. The ISP can also do strict enforcement if they'd like on top of this. For instance, by just letting the first IPv6 address they see coming over the link from the subscriber as the only IPv6 address that can be used; packets to/from other addresses could be filtered out by the ISP. Thus in this tussle between the ISP (and its, IMHO misinformed, desire to charge per host) and the user's desire to share the bandwidth they are buying across multiple devices, it is not fruitful to try to use protocols to try to force the ISP to change their thinking; it isn't hard for them to do filters as a last resort to prevent what they think they need to prevent. What we can do from a protocol perspective (and implementation perspective) is to make it easy for the ISP to do the right thing - explicitly delegate a prefix (/48 by default as well as /64) to the customer. > > Thus I think the ISP that wants to charge differently for one IPv6 address > > per customer compared to a /64 or /48 prefix can do this as easily as it > > can in IPv4. > > I don't know how this relates to the above, but this seems obvious. The basis for needing ndproxy in this case is that the ISP doesn't want to explicitly delegate a prefix to their customer. I see two possible reasons for this behavior (and there might be more) - the ISP wants to provide tiered services with a single device service at the bottom i.e. only allow one host/IPv6 address - it is too hard for them to explicitly delegate prefixes What else might make then not do this? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Fri Mar 26 14:04:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08080 for ; Fri, 26 Mar 2004 14:04:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wcv-00030A-02 for ipv6-archive@odin.ietf.org; Fri, 26 Mar 2004 14:04:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QJ4KvX011532 for ipv6-archive@odin.ietf.org; Fri, 26 Mar 2004 14:04:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wcu-0002zv-Q3 for ipv6-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 14:04:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08077 for ; Fri, 26 Mar 2004 14:04:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wcs-0005OG-00 for ipv6-web-archive@ietf.org; Fri, 26 Mar 2004 14:04:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wbz-0005KR-00 for ipv6-web-archive@ietf.org; Fri, 26 Mar 2004 14:03:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6wbf-0005Gf-00 for ipv6-web-archive@ietf.org; Fri, 26 Mar 2004 14:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wah-0002da-3D; Fri, 26 Mar 2004 14:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wa6-0002b5-EY for ipv6@optimus.ietf.org; Fri, 26 Mar 2004 14:01:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07913 for ; Fri, 26 Mar 2004 14:01:23 -0500 (EST) From: shawn.routhier@windriver.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wa3-00058z-00 for ipv6@ietf.org; Fri, 26 Mar 2004 14:01:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wZ6-00052s-00 for ipv6@ietf.org; Fri, 26 Mar 2004 14:00:25 -0500 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx with esmtp (Exim 4.12) id 1B6wYK-0004u4-00 for ipv6@ietf.org; Fri, 26 Mar 2004 13:59:36 -0500 Received: from ala-mta03.windriver.com (ala-mta03 [147.11.57.132]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA05796; Fri, 26 Mar 2004 10:58:52 -0800 (PST) Received: by ala-mta03.wrs.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Mar 2004 10:58:53 -0800 Message-ID: <47DD7107796EF94CBE7873B8F31DF2C3CB074B@ala-mail01.wrs.com> To: ipv6@ietf.org Cc: brian@innovationslab.net, ipv6mib@ibr.cs.tu-bs.de, kzm@cisco.com Subject: IP MIB issues Date: Fri, 26 Mar 2004 10:58:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 There were two suggested changes to the IP MIB that may not have had sufficient discussion during the WG last call. The first is a simple renaming of some objects in order to provide better clarity. The second is the removal of an object from the IPv6 interface table as it may a) not be useful b) be in the wrong table. The document has been through WG last call and through IESG last call. There are a small number of editorial revisions required from the IESG last call so a new revision will be created. Including the following changes would be simple. The chairs will be sending another piece of mail to specify when the deadline for comments is. ** For issue 1 the original request described it as such: I believe that use of "AdminStatus" in ipv4InterfaceAdminStatus and ipv6InterfaceAdminStatus is confusing. These are not "AdminStatus" in the same sense as ifAdminStatus as is explained in section 3.2.2. Rather these enable or disable the connectivity between a particular version of IP and (one of) the ifIndex on top of which it operates. These should really be xxxInterfaceEnableStatus. My previous position was to skip this change as it did not seem to be a major issue and I was attempting to avoid additional changes to the MIB. My current position is that as I need to make changes anyway I may as well include this change. If there is no discussion I shall change the names of these objects. If you feel that the names of these objects should not be changed send mail by the deadline that the chairs specify. ** For issue 2 we have the following discussion: Keith: Why is ipv6InterfacePhysicalAddress defined in draft-ietf-ipv6-rfc2011-update? For all instances for which it is defined, i.e., all values of i, I believe the value of ipv6InterfacePhysicalAddress.i is always same as the value of ifPhysAddress.i Thus, it is redundant, right ? ** Shawn: While I don't have experience with them I've been told by other people that there are cases where the addresses may be different. I believe the example given was an ether switch wherein each interface might have its own physical address but the box elects to use a single ether address for some or most purposes. I can try and find the old description if you'd like more. ** Keith: This example: "an ether switch wherein each interface might have its own physical address but the box elects to use a single ether address for some or most purposes" has long been modeled in the Bridge MIB WG as the "switch" having an internal interface with its own MAC address which id independent of its external interfaces. In any case, it's not IPv6-specific. That is, if such an object were needed, it would be needed for IPv4 as well, or any past internetwork protocol (e.g., DECNET) or any future internetwork protocol (IPv9). Bottom line: I believe the solution to this issue is to have an extra ifTable row for the second MAC address. Even if I'm wrong, it's an ifTable issue, not an IPv6 (or IPv4) issue, and therefore must not be in this MIB. ** Previously I was attempting to maintain a potentially useful object. Upon reflection I have decided that if a better justification for keeping the object can't be found it should be removed. If there is no discussion I shall remove this object. If you feel it is a useful object and should be kept send mail by the deadline that the chairs specify. regards, Shawn A. Routhier -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Mar 28 00:28:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17200 for ; Sun, 28 Mar 2004 00:28:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Spg-0002z8-62 for ipv6-archive@odin.ietf.org; Sun, 28 Mar 2004 00:27:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2S5ReJs011473 for ipv6-archive@odin.ietf.org; Sun, 28 Mar 2004 00:27:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Spg-0002yy-1b for ipv6-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 00:27:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17144 for ; Sun, 28 Mar 2004 00:27:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7Spd-0005UM-00 for ipv6-web-archive@ietf.org; Sun, 28 Mar 2004 00:27:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7SoT-0005Fr-00 for ipv6-web-archive@ietf.org; Sun, 28 Mar 2004 00:26:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7Sn6-0004w6-00 for ipv6-web-archive@ietf.org; Sun, 28 Mar 2004 00:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7SmJ-0001sn-MK; Sun, 28 Mar 2004 00:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7SRU-0000lv-Oe for ipv6@optimus.ietf.org; Sun, 28 Mar 2004 00:02:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16087 for ; Sun, 28 Mar 2004 00:02:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7SRS-0002XT-00 for ipv6@ietf.org; Sun, 28 Mar 2004 00:02:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7SQo-0002Qz-00 for ipv6@ietf.org; Sun, 28 Mar 2004 00:01:58 -0500 Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx with esmtp (Exim 4.12) id 1B7SPo-0002Ib-00 for ipv6@ietf.org; Sun, 28 Mar 2004 00:00:57 -0500 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 63D1F1C5 for ; Sun, 28 Mar 2004 00:00:15 -0500 (EST) To: ipv6@ietf.org Subject: Weekly posting summary for ipv6@ietf.org From: Rob Austein Date: Sun, 28 Mar 2004 00:00:15 -0500 Message-Id: <20040328050015.63D1F1C5@cyteen.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Messages | Bytes | Who --------+------+--------+----------+------------------------ 16.07% | 9 | 14.53% | 46985 | pekkas@netcore.fi 14.29% | 8 | 12.18% | 39383 | erik.nordmark@sun.com 8.93% | 5 | 11.44% | 37007 | ftemplin@iprg.nokia.com 7.14% | 4 | 7.96% | 25740 | rdroms@cisco.com 7.14% | 4 | 7.65% | 24738 | jinmei@isl.rdc.toshiba.co.jp 5.36% | 3 | 7.36% | 23795 | mukesh.gupta@nokia.com 5.36% | 3 | 5.39% | 17440 | ot@cisco.com 5.36% | 3 | 4.22% | 13650 | stephen@sprunk.org 5.36% | 3 | 4.10% | 13269 | h.soliman@flarion.com 3.57% | 2 | 3.67% | 11865 | huitema@windows.microsoft.com 1.79% | 1 | 5.42% | 17542 | bob.hinden@nokia.com 3.57% | 2 | 2.37% | 7679 | jari.arkko@kolumbus.fi 1.79% | 1 | 2.00% | 6461 | shawn.routhier@windriver.com 1.79% | 1 | 1.75% | 5661 | william@elan.net 1.79% | 1 | 1.65% | 5338 | internet-drafts@ietf.org 1.79% | 1 | 1.56% | 5031 | jeroen@unfix.org 1.79% | 1 | 1.50% | 4846 | sra+ipng@hactrn.net 1.79% | 1 | 1.38% | 4448 | michael.dillon@radianz.com 1.79% | 1 | 1.33% | 4293 | w.kawakami@rdc.east.ntt.co.jp 1.79% | 1 | 1.30% | 4198 | brc@zurich.ibm.com 1.79% | 1 | 1.24% | 4005 | iesg-secretary@ietf.org --------+------+--------+----------+------------------------ 100.00% | 56 |100.00% | 323374 | 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 exim@www1.ietf.org Sun Mar 28 20:38:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17182 for ; Sun, 28 Mar 2004 20:38:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lj2-0007jK-UR for ipv6-archive@odin.ietf.org; Sun, 28 Mar 2004 20:38:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T1c4EX029710 for ipv6-archive@odin.ietf.org; Sun, 28 Mar 2004 20:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lj2-0007j7-OC for ipv6-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 20:38:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17169 for ; Sun, 28 Mar 2004 20:38:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7lj0-0002yI-00 for ipv6-web-archive@ietf.org; Sun, 28 Mar 2004 20:38:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7li4-0002rR-00 for ipv6-web-archive@ietf.org; Sun, 28 Mar 2004 20:37:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7lha-0002kY-00 for ipv6-web-archive@ietf.org; Sun, 28 Mar 2004 20:36:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lh4-0007Br-6E; Sun, 28 Mar 2004 20:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lgB-00079H-AL for ipv6@optimus.ietf.org; Sun, 28 Mar 2004 20:35:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17074 for ; Sun, 28 Mar 2004 20:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7lg9-0002c1-00 for ipv6@ietf.org; Sun, 28 Mar 2004 20:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7lfM-0002Uk-00 for ipv6@ietf.org; Sun, 28 Mar 2004 20:34:16 -0500 Received: from smtp.exodus.net ([66.35.230.237] helo=smtp02-w.exodus.net) by ietf-mx with esmtp (Exim 4.12) id 1B7leV-0002Jv-00 for ipv6@ietf.org; Sun, 28 Mar 2004 20:33:23 -0500 Received: from ms101.mail1.com (ms101.mail1.com [209.1.5.174]) by smtp02-w.exodus.net (8.12.8/8.12.8) with ESMTP id i2SMeZEv006582 for ; Sun, 28 Mar 2004 16:40:36 -0600 Received: from [192.168.2.2] (unverified [24.61.30.237]) by accounting.espmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Sun, 28 Mar 2004 17:32:53 -0800 Mime-Version: 1.0 X-Sender: margaret@thingmagic.com@ms101.mail1.com Message-Id: In-Reply-To: <406017F2.7010109@kolumbus.fi> References: <406017F2.7010109@kolumbus.fi> Date: Sun, 28 Mar 2004 20:31:48 -0500 To: Jari Arkko , Pekka Savola From: Margaret Wasserman Subject: Re: ND-proxy applicability and loop-prevention Cc: Erik Nordmark , ipv6@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 12:56 PM +0200 3/23/04, Jari Arkko wrote: >> I think it would be possible to detect loops if we wanted really >>hard to do that. That might just >> lead to reinvention of the spanning tree protocol, though. > >This is a danger, yes. Why is this a danger? IMO, the ND proxy mechanism effectively does bridging at layer 3. What makes you think it will be any easier here than at layer 2? If layer 3 bridging is something that we need, then why not run STP? There was some discussion of this general concept (zero-configuration routing and/or layer 3 bridging) in the Zerouter BOF and on the zerouter mailing list... Does anyone know if that effort is still active? Margaret -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Sun Mar 28 21:16:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18601 for ; Sun, 28 Mar 2004 21:16:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mJp-0004R1-CC for ipv6-archive@odin.ietf.org; Sun, 28 Mar 2004 21:16:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T2G5sY017041 for ipv6-archive@odin.ietf.org; Sun, 28 Mar 2004 21:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mJo-0004Qm-VN for ipv6-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 21:16:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18584 for ; Sun, 28 Mar 2004 21:16:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7mJm-0000er-00 for ipv6-web-archive@ietf.org; Sun, 28 Mar 2004 21:16:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7mIn-0000Xl-00 for ipv6-web-archive@ietf.org; Sun, 28 Mar 2004 21:15:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7mI4-0000RR-00 for ipv6-web-archive@ietf.org; Sun, 28 Mar 2004 21:14:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mHq-000466-2v; Sun, 28 Mar 2004 21:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7mGs-000442-Eq for ipv6@optimus.ietf.org; Sun, 28 Mar 2004 21:13:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18489 for ; Sun, 28 Mar 2004 21:12:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7mGp-0000Iu-00 for ipv6@ietf.org; Sun, 28 Mar 2004 21:12:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7mFq-0000C1-00 for ipv6@ietf.org; Sun, 28 Mar 2004 21:11:59 -0500 Received: from web13705.mail.yahoo.com ([216.136.175.138]) by ietf-mx with smtp (Exim 4.12) id 1B7mEu-00004r-00 for ipv6@ietf.org; Sun, 28 Mar 2004 21:11:00 -0500 Message-ID: <20040329021100.5235.qmail@web13705.mail.yahoo.com> Received: from [165.213.1.1] by web13705.mail.yahoo.com via HTTP; Sun, 28 Mar 2004 18:11:00 PST Date: Sun, 28 Mar 2004 18:11:00 -0800 (PST) From: knowme Subject: Is there any router vendors supporting IPv6 Jumbogram? To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, everyone, I hope to know if there are routers supporting IPv6 Jumbogram option. Or is there any vendor planning to support processing IPv6 Jumbogram option? Please give me any information you know. Thanks in advance. __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 29 02:27:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15295 for ; Mon, 29 Mar 2004 02:27:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7rAM-00011h-EX for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 02:26:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T7Qc8x003941 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 02:26:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7rAK-00011U-Q9 for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 02:26:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15157 for ; Mon, 29 Mar 2004 02:26:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7rAH-000454-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 02:26:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7r8n-0003fY-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 02:25:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7r76-0003NS-02 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 02:23:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qwE-0002lU-MA; Mon, 29 Mar 2004 02:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qvO-0002Mm-O9 for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 02:11:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11420 for ; Mon, 29 Mar 2004 02:11:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7qvK-0001UX-00 for ipv6@ietf.org; Mon, 29 Mar 2004 02:11:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7quN-0001Mq-00 for ipv6@ietf.org; Mon, 29 Mar 2004 02:10:07 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1B7qtO-0001FR-00 for ipv6@ietf.org; Mon, 29 Mar 2004 02:09:07 -0500 Received: from localhost ([130.194.13.84]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L8B257BSRA90D7FW@vaxh.its.monash.edu.au> for ipv6@ietf.org; Mon, 29 Mar 2004 17:06:06 +1000 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id A9B7739C018; Mon, 29 Mar 2004 17:06:05 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 8987D2DC013; Mon, 29 Mar 2004 17:06:05 +1000 (EST) Date: Mon, 29 Mar 2004 17:06:05 +1000 From: Greg Daley Subject: Re: ND-proxy applicability and loop-prevention To: Margaret Wasserman Cc: Jari Arkko , Pekka Savola , Erik Nordmark , ipv6@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <4067CADD.5020906@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <406017F2.7010109@kolumbus.fi> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Margaret, Margaret Wasserman wrote: > At 12:56 PM +0200 3/23/04, Jari Arkko wrote: > >>> I think it would be possible to detect loops if we wanted really >>> hard to do that. That might just >>> lead to reinvention of the spanning tree protocol, though. >> >> >> This is a danger, yes. > > > Why is this a danger? I think there's only a danger if we end up doing more work than we need to, or work on something covered by other standards bodies. > IMO, the ND proxy mechanism effectively does bridging at layer 3. What > makes you think it will be any easier here than at layer 2? If layer 3 > bridging is something that we need, then why not run STP? I think that using the spanning tree algorithm may be OK, if we can work out appropriate root brouter selection, metrics etc. I'd suggest that extending the coverage of a bridged network with 802.1d/w spanning tree protocols is not a good idea though, for a number fo reasons. Firstly, the computational/message complexity of STP is such that the convergence times will increase greatly by connecting disparate bridged networks. (Even just running a separate spanning tree amongst the proxies for a level of hierarchy would work better, as area 0 does in OSPF). Secondly, there are several issues in 802.1d/w networks which are constraints due to the transparent nature of the bridging in these networks (no modification to L2 frames). In a proxied network, we can get much more control of the forwarding plane by changing the L2 headers. This may allow us to avoid the lack of redundancy present in spanning trees (for example using DAGs or shortest paths instead for unicast forwarding). So L3 spanning trees may be one way to create a routing topology for ND/MLD proxies, but it may not be the best way. > There was some discussion of this general concept (zero-configuration > routing and/or layer 3 bridging) in the Zerouter BOF and on the zerouter > mailing list... Does anyone know if that effort is still active? I'm not sure where zerouter work is at the moment. The bof chair (Aidan Williams) was working at motorola labs in Sydney which has closed down. I've had difficulty tracking him down (mail bounces). Radia Perlman and Aidan were working on this before. in a (now expired) draft. http://www.watersprings.org/pub/id/draft-perlman-zerouter-rbridge-00.txt Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 29 03:46:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18910 for ; Mon, 29 Mar 2004 03:46:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7sPS-0002rS-EL for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 03:46:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T8kIss010998 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 03:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7sPR-0002rJ-Pj for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 03:46:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18898 for ; Mon, 29 Mar 2004 03:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7sPP-0007ke-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 03:46:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7sOU-0007cz-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 03:45:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7sNr-0007Vg-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 03:44:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7sNG-0002AZ-HB; Mon, 29 Mar 2004 03:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7sMY-0001oJ-6o for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 03:43:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18761 for ; Mon, 29 Mar 2004 03:43:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7sMV-0007Kx-00 for ipv6@ietf.org; Mon, 29 Mar 2004 03:43:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7sLi-0007CQ-00 for ipv6@ietf.org; Mon, 29 Mar 2004 03:42:26 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1B7sKi-00071W-00 for ipv6@ietf.org; Mon, 29 Mar 2004 03:41:25 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id A2A677084B0; Mon, 29 Mar 2004 18:41:02 +1000 (EST) Date: Mon, 29 Mar 2004 18:41:02 +1000 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Subject: Re: I-D ACTION:draft-ietf-ipv6-optimistic-dad-00.txt Message-ID: <20040329084102.GB9839@zoic.org> Mail-Followup-To: ipv6@ietf.org References: <200403232045.PAA27094@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403232045.PAA27094@ietf.org> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-03-23, Internet-Drafts@ietf.org wrote: > > Title : Optimistic Duplicate Address Detection > Author(s) : N. Moore > Filename : draft-ietf-ipv6-optimistic-dad-00.txt > Pages : 14 > Date : 2004-3-23 G'day all, Well, IETF Seoul brought a consensus that this is to become a working group item, so here it is :-). Thanks to Jinmei Tatuya, Pascal Thubert and Ahmet Sekercioglu for their rapid feedback, I've tried to answer your concerns in this version so let me know what you think! I think most of the small bugs are ironed out, so it's time for the draft to undergo some serious scrutiny: eg, finding the big bugs! Specifically, I'd like to get reviews on: * internal IPv6 WG issues, eg: compatibility with RFC246[12]{bis} and friends; * network configuration work like SEND and DNA; * mobility solutions work like HIP, MOBIKE, MobileIPv6; * interaction with higher layer protocols. If you can provide a review from any of those points, let me know ... I'll be putting together a web page tracking issues, and I'd like to take an issues list to IETF San Diego. thanks, -----Nick 'Sharkey' Moore. PS: Slides from Seoul are up at . Issue #1 is "NM: section 2 is rather waffly, whereas the slides are rather terse: seek a happy medium." -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 29 06:47:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27653 for ; Mon, 29 Mar 2004 06:47:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7vEi-0005A2-VW for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 06:47:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TBlOPg019834 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 06:47:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7vEi-00059p-QV for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 06:47:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27621 for ; Mon, 29 Mar 2004 06:47:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7vEe-000367-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 06:47:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7vDq-0002xg-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 06:46:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7vD4-0002om-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 06:45:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7vCQ-0004Ul-DD; Mon, 29 Mar 2004 06:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7vBp-0004RD-Ar for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 06:44:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27430 for ; Mon, 29 Mar 2004 06:44:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7vBl-0002bv-00 for ipv6@ietf.org; Mon, 29 Mar 2004 06:44:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7vAs-0002Tf-00 for ipv6@ietf.org; Mon, 29 Mar 2004 06:43:26 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1B7v9x-0002E0-00 for ipv6@ietf.org; Mon, 29 Mar 2004 06:42:29 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i2TBftL32076 for ; Mon, 29 Mar 2004 03:41:55 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i2TBu6QP007793 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 29 Mar 2004 03:56:14 -0800 Message-ID: <40680B6F.1040801@innovationslab.net> Date: Mon, 29 Mar 2004 06:41:35 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention References: <406017F2.7010109@kolumbus.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Margaret Wasserman wrote: > There was some discussion of this general concept (zero-configuration > routing and/or layer 3 bridging) in the Zerouter BOF and on the zerouter > mailing list... Does anyone know if that effort is still active? I have not seen any activity on the zerouter mailing list for a LONG time. That does not mean that people aren't working on it under the radar though... Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 29 07:20:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28583 for ; Mon, 29 Mar 2004 07:20:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7vkY-0008Sw-AH for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 07:20:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TCKIek032541 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 07:20:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7vkX-0008Sm-U8 for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 07:20:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28546 for ; Mon, 29 Mar 2004 07:20:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7vkX-0007HT-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 07:20:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7vjZ-00079T-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 07:19:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7vic-00071b-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 07:18:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7viM-00085l-Dm; Mon, 29 Mar 2004 07:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7vhk-0007zD-IS for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 07:17:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28457 for ; Mon, 29 Mar 2004 07:17:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7vhk-0006us-00 for ipv6@ietf.org; Mon, 29 Mar 2004 07:17:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7vgr-0006ne-00 for ipv6@ietf.org; Mon, 29 Mar 2004 07:16:30 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7vgP-0006g9-00 for ipv6@ietf.org; Mon, 29 Mar 2004 07:16:01 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2TCFHo07466; Mon, 29 Mar 2004 15:15:18 +0300 Date: Mon, 29 Mar 2004 15:15:17 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: Ole Troan , Subject: Re: ND-proxy applicability and loop-prevention In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 25 Mar 2004, Erik Nordmark wrote: > > Stateless address autoconfig mode you're talking about is about > > advertising a /64 prefix on the link, with addrconfig flag set, and > > onlink flag not set --right? While the onlink flag gives no > > information how the hosts could communicate between themselves, it > > still gives the ability to connect multiple hosts on a link -- so it > > cannot be used by the ISPs to force "1 user/prefix" -model, right? > > Not if the link to the ISP is a pt-pt link, and all the case I've seen, > even if the L2 is broadcast capable such as in cable networks, the topology > visible to IP seems to be pt-pt. Counterexamples include bridged xDSL and Ethernet to the Home (without PPP framing, or advertising the /64 on top of the PPP session). > The ISP can also do strict enforcement if they'd like on top of this. > For instance, by just letting the first IPv6 address they see coming over the > link from the subscriber as the only IPv6 address that can be used; > packets to/from other addresses could be filtered out by the ISP. Of course -- there is no stopping that. > The basis for needing ndproxy in this case is that the ISP doesn't want to > explicitly delegate a prefix to their customer. I see two possible reasons > for this behavior (and there might be more) > - the ISP wants to provide tiered services with a single device service > at the bottom i.e. only allow one host/IPv6 address I might reword this slightly, to: "wants to provide tiered services simply: a) with a /48 delegation, or with either b) /64 link or just c) one address". We of course hope that c) would not happen, but have no power to stop an ISP if they do it in any case. > - it is too hard for them to explicitly delegate prefixes Note that this is not a binary decision, i.e., the ISP might decide that "OK, it's not too hard for us to delegate the prefixes, but if we do that, we want some extra payment from the user for the trouble". In that kind of environment, ensuring that the users have tools to cope with a /64 prefix as well would seem to be really important. For these two basic cases, I think ND-proxy would be applicable in 1.b) (of my own proposition, above) and 2). -- 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 exim@www1.ietf.org Mon Mar 29 07:29:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28969 for ; Mon, 29 Mar 2004 07:29:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7vtH-0000kJ-Bh for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 07:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TCTJdV002865 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 07:29:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7vtH-0000k7-62 for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 07:29:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28921 for ; Mon, 29 Mar 2004 07:29:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7vtG-0000ky-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 07:29:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7vsH-0000bD-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 07:28:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7vrJ-0000RY-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 07:27:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7vr3-0000Hb-3b; Mon, 29 Mar 2004 07:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7vqS-0000F2-B8 for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 07:26:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28802 for ; Mon, 29 Mar 2004 07:26:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7vqR-0000Jn-00 for ipv6@ietf.org; Mon, 29 Mar 2004 07:26:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7vpe-0000By-00 for ipv6@ietf.org; Mon, 29 Mar 2004 07:25:35 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7vor-0007iK-00 for ipv6@ietf.org; Mon, 29 Mar 2004 07:24:45 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2TCOAo07641; Mon, 29 Mar 2004 15:24:10 +0300 Date: Mon, 29 Mar 2004 15:24:10 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: ipv6@ietf.org Subject: RE: ND-proxy applicability and loop-prevention In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Btw -- one aspect was mentioned by Mohan P. on v6ops list: whether the ND-proxy could decrement TTL instead of keeping it the same. I don't think whether this would affect this discussion (i.e., whether such a proxy would be considerably better in this respect) has been considered. On Thu, 25 Mar 2004, Erik Nordmark wrote: > > The same helpdesk she calls when she encounters a weird problem in her > > network connectivity, or in her PC. Most likely you ;-) > > > > (This is a much more generic problem, not one specific to this > > scenario, obviously.) > > But in this particular case you seem to be arguing that plug&pray > is sufficient while I argue that we should aim for plug&play; > I think the futuristic goal is that wiring together network devices > shouldn't be more complex than plugging in electrical appliances. For the deployment I have in mind, plug&pray and plug&play are pretty much equivalent. There are certainly other things, labeled plug&play which are much more brittle than this :) > > You are making assumption that those boxes would also be acting as > > routers (in the ND-proxy mode) by default, right? I don't, and I > > don't think doing that would make a lot of sense. > > No. > I'm only making the same assumption that underlies ndproxy as well as the > zerouter discussion; there will be L2s that do not support IEEE 802 bridging. > If you disagree with this assumption we don't need ndproxy or zerouter > for the home networking case - IEEE 802 bridging has already solved the > problem. OK -- maybe you're thinking of this in more generic terms, like, every VCR or equivalent having its own (more or less) internal media for which IP connectivity would be desirable. And that such media would not be currently IEEE bridgeable. (And when you combine this to a scenario when such a "VCR++" has WLAN uplink to the other devices at home, you might end up in a mess. With wired connectivity, you'd be OK.) On the other hand, I have been looking at the scenario where an explicit set of "routers" (or a home PC or whatever) would be proxying for the nodes connecting to that box. We certainly seem to have an indication that the latter is important. I do not have personal knowledge if the former would be. It'd be interesting to know. -- 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 exim@www1.ietf.org Mon Mar 29 08:54:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02499 for ; Mon, 29 Mar 2004 08:54:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7xCs-00013d-3n for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 08:53:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TDrcbL004062 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 08:53:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7xCr-00013R-RM for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 08:53:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02475 for ; Mon, 29 Mar 2004 08:53:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7xCq-0004lV-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 08:53:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7xBj-0004Qz-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 08:52:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7xAO-00048o-07 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 08:51:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7wvq-0007NL-0Y; Mon, 29 Mar 2004 08:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7wvD-0007Lt-W8 for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 08:35:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01626 for ; Mon, 29 Mar 2004 08:35:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7wvB-0002IH-00 for ipv6@ietf.org; Mon, 29 Mar 2004 08:35:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7wuE-0002BJ-00 for ipv6@ietf.org; Mon, 29 Mar 2004 08:34:23 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1B7wtO-0001xe-00 for ipv6@ietf.org; Mon, 29 Mar 2004 08:33:30 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i2TDWxL00959; Mon, 29 Mar 2004 05:32:59 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i2TDl9QP008537 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 29 Mar 2004 05:47:15 -0800 Message-ID: <40682575.8010409@innovationslab.net> Date: Mon, 29 Mar 2004 08:32:37 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Erik Nordmark , ipv6@ietf.org Subject: Re: ND-proxy applicability and loop-prevention References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka, Maybe I missed it, but how can we decrement the Hop Count for loop prevention when receiving nodes are using the Hop Count=255 check on reception? Regards, Brian Pekka Savola wrote: > Btw -- one aspect was mentioned by Mohan P. on v6ops list: whether the > ND-proxy could decrement TTL instead of keeping it the same. I don't > think whether this would affect this discussion (i.e., whether such a > proxy would be considerably better in this respect) has been > considered. > > On Thu, 25 Mar 2004, Erik Nordmark wrote: > >>>The same helpdesk she calls when she encounters a weird problem in her >>>network connectivity, or in her PC. Most likely you ;-) >>> >>>(This is a much more generic problem, not one specific to this >>>scenario, obviously.) >> >>But in this particular case you seem to be arguing that plug&pray >>is sufficient while I argue that we should aim for plug&play; >>I think the futuristic goal is that wiring together network devices >>shouldn't be more complex than plugging in electrical appliances. > > > For the deployment I have in mind, plug&pray and plug&play are pretty > much equivalent. There are certainly other things, labeled plug&play > which are much more brittle than this :) > > >>>You are making assumption that those boxes would also be acting as >>>routers (in the ND-proxy mode) by default, right? I don't, and I >>>don't think doing that would make a lot of sense. >> >>No. >>I'm only making the same assumption that underlies ndproxy as well as the >>zerouter discussion; there will be L2s that do not support IEEE 802 bridging. >>If you disagree with this assumption we don't need ndproxy or zerouter >>for the home networking case - IEEE 802 bridging has already solved the >>problem. > > > OK -- maybe you're thinking of this in more generic terms, like, every > VCR or equivalent having its own (more or less) internal media for > which IP connectivity would be desirable. And that such media would > not be currently IEEE bridgeable. (And when you combine this to a > scenario when such a "VCR++" has WLAN uplink to the other devices at > home, you might end up in a mess. With wired connectivity, you'd be > OK.) > > On the other hand, I have been looking at the scenario where an > explicit set of "routers" (or a home PC or whatever) would be proxying > for the nodes connecting to that box. > > We certainly seem to have an indication that the latter is important. > I do not have personal knowledge if the former would be. It'd be > interesting to know. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 29 13:40:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16915 for ; Mon, 29 Mar 2004 13:40:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81fd-0006x5-JP for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 13:39:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TIdbBT026721 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 13:39:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81fd-0006wt-2I for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 13:39:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16867 for ; Mon, 29 Mar 2004 13:39:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B81fa-0000U0-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 13:39:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B81em-0000Li-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 13:38:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B81dr-0000Dr-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 13:37:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81d7-0006Ho-EL; Mon, 29 Mar 2004 13:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81cr-0006Fs-Mh for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 13:36:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16739 for ; Mon, 29 Mar 2004 13:36:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B81cp-00003h-00 for ipv6@ietf.org; Mon, 29 Mar 2004 13:36:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B81bw-0007jZ-00 for ipv6@ietf.org; Mon, 29 Mar 2004 13:35:49 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1B81bV-0007b9-00 for ipv6@ietf.org; Mon, 29 Mar 2004 13:35:22 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2TIZEp9002635; Mon, 29 Mar 2004 11:35:15 -0700 (MST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2TIZCQ03169; Mon, 29 Mar 2004 20:35:12 +0200 (MEST) Date: Mon, 29 Mar 2004 10:35:13 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND-proxy applicability and loop-prevention To: Pekka Savola Cc: Erik Nordmark , Ole Troan , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > > - it is too hard for them to explicitly delegate prefixes > > Note that this is not a binary decision, i.e., the ISP might decide > that "OK, it's not too hard for us to delegate the prefixes, but if we > do that, we want some extra payment from the user for the trouble". So then you end up with a single IPv6 address, right? > In that kind of environment, ensuring that the users have tools to > cope with a /64 prefix as well would seem to be really important. But the /64 isn't delegated to the subscriber - it is merely assigned to the link between ISP and the subscriber. I think RFC 3177 is quite clear on its recommendation. Why can't we simplify the message and avoid developping additional protocols (which are as likely to slow down IPv6 deployment as speeding it up) by saying that ISPs which don't delegate at least a /64 (using a protocol/mechanism which delegates it to the *subscriber* and not just assigning it to the link from the ISP and the subscriber) doesn't follow the implications of the recommendation in 3177? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 29 14:05:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17984 for ; Mon, 29 Mar 2004 14:05:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B823x-0000G9-4f for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 14:04:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TJ4j5M000996 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 14:04:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B823w-0000Fy-Sw for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 14:04:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17970 for ; Mon, 29 Mar 2004 14:04:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B823u-0003fW-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 14:04:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B822x-0003XK-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 14:03:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B822S-0003Pu-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 14:03:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B822H-0008Ol-D6; Mon, 29 Mar 2004 14:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B821u-0008Nx-Pu for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 14:02:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17887 for ; Mon, 29 Mar 2004 14:02:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B821s-0003OW-00 for ipv6@ietf.org; Mon, 29 Mar 2004 14:02:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B820x-0003HS-00 for ipv6@ietf.org; Mon, 29 Mar 2004 14:01:40 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8206-00033s-00 for ipv6@ietf.org; Mon, 29 Mar 2004 14:00:47 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2TJ05714505; Mon, 29 Mar 2004 22:00:05 +0300 Date: Mon, 29 Mar 2004 22:00:05 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: Ole Troan , Subject: Re: ND-proxy applicability and loop-prevention In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 29 Mar 2004, Erik Nordmark wrote: > > > - it is too hard for them to explicitly delegate prefixes > > > > Note that this is not a binary decision, i.e., the ISP might decide > > that "OK, it's not too hard for us to delegate the prefixes, but if we > > do that, we want some extra payment from the user for the trouble". > > So then you end up with a single IPv6 address, right? Not necessarily. If you don't run something like PPPv6 on the link to the customer, just advertising a /64 on the customer link seems to be the simplest thing the ISP can do. (Even simpler than just a single IPv6 address.) Without ND-proxy or bridging, that's one IPv6 address. > > In that kind of environment, ensuring that the users have tools to > > cope with a /64 prefix as well would seem to be really important. > > But the /64 isn't delegated to the subscriber - it is merely assigned > to the link between ISP and the subscriber. Sure, but with ND-proxy this distinction is irrelevant, which was the the point to begin with. > I think RFC 3177 is quite clear on its recommendation. > Why can't we simplify the message and avoid developping additional protocols > (which are as likely to slow down IPv6 deployment as speeding it up) by saying > that ISPs which don't delegate at least a /64 (using a protocol/mechanism > which delegates it to the *subscriber* and not just assigning it to the link > from the ISP and the subscriber) doesn't follow the implications of the > recommendation in 3177? The problem is that with the same trouble it takes to fully delegate a /64, the ISP could do a /48 as well. That is a good thing also, of course. My worry is that the ISPs end up doing nothing unless they have simple enough means available. I mean, the message could also be "just give every customer a delegated /48. If that is not possible, advertising a /64 on the link is better than nothing." This takes no stance on the other "subnet extending" scenarios where ND-proxy could be desirable, like a gadget on firewire connected to your PC. -- 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 exim@www1.ietf.org Mon Mar 29 14:31:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19530 for ; Mon, 29 Mar 2004 14:31:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B82TC-0002Dp-8a for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 14:30:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TJUoRa008535 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 14:30:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B82TC-0002DZ-02 for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 14:30:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19512 for ; Mon, 29 Mar 2004 14:30:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B82T9-0007LK-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 14:30:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B82S7-0007Co-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 14:29:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B82Rm-00075A-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 14:29:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B82RS-0001sZ-JF; Mon, 29 Mar 2004 14:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B82R1-0001kN-AB for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 14:28:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19395 for ; Mon, 29 Mar 2004 14:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B82Qy-000745-00 for ipv6@ietf.org; Mon, 29 Mar 2004 14:28:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B82Q4-0006y3-00 for ipv6@ietf.org; Mon, 29 Mar 2004 14:27:37 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1B82PP-0006ks-00 for ipv6@ietf.org; Mon, 29 Mar 2004 14:26:56 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i2TJOQL04274; Mon, 29 Mar 2004 11:24:26 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i2TJcXQP009991 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 29 Mar 2004 11:38:44 -0800 Message-ID: <406877CB.8050801@innovationslab.net> Date: Mon, 29 Mar 2004 14:23:55 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: shawn.routhier@windriver.com CC: ipv6@ietf.org, ipv6mib@ibr.cs.tu-bs.de, kzm@cisco.com Subject: Re: IP MIB issues References: <47DD7107796EF94CBE7873B8F31DF2C3CB074B@ala-mail01.wrs.com> In-Reply-To: <47DD7107796EF94CBE7873B8F31DF2C3CB074B@ala-mail01.wrs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I would like to set a one week discussion period for these issues (i.e. speak your mind by Monday 4/5). After that, the chairs will determine if there are reasons to not make the recommended changes. Further comments in-line... shawn.routhier@windriver.com wrote: > > There were two suggested changes to the IP MIB that > may not have had sufficient discussion during the WG last call. > > The first is a simple renaming of some objects in order to provide > better clarity. > > The second is the removal of an object from the IPv6 interface table > as it may a) not be useful b) be in the wrong table. > > The document has been through WG last call and through IESG last call. > There are a small number of editorial revisions required from the IESG last > call so a new revision will be created. Including the following changes > would > be simple. > > The chairs will be sending another piece of mail to specify when the > deadline > for comments is. > > ** > > For issue 1 the original request described it as such: > > I believe that use of "AdminStatus" in ipv4InterfaceAdminStatus and > ipv6InterfaceAdminStatus is confusing. > > These are not "AdminStatus" in the same sense as ifAdminStatus as is > explained in section 3.2.2. Rather these enable or disable the > connectivity between a particular version of IP and (one of) the > ifIndex on top of which it operates. These should really be > xxxInterfaceEnableStatus. I support these changes being made. I add clarity what is being reported. > > My previous position was to skip this change as it did not seem to be > a major issue and I was attempting to avoid additional changes to the > MIB. > > My current position is that as I need to make changes anyway I may as > well include this change. > > If there is no discussion I shall change the names of these objects. If > you feel that the names of these objects should not be changed send mail > by the deadline that the chairs specify. > > ** > > For issue 2 we have the following discussion: > > Keith: > Why is ipv6InterfacePhysicalAddress defined in > draft-ietf-ipv6-rfc2011-update? > > For all instances for which it is defined, i.e., all values of i, I believe > the value of ipv6InterfacePhysicalAddress.i is always same as the value of > ifPhysAddress.i > > Thus, it is redundant, right ? > > ** > > Shawn: > While I don't have experience with them I've been told by other people > that there are cases where the addresses may be different. I believe > the example given was an ether switch wherein each interface might have > its own physical address but the box elects to use a single ether > address for some or most purposes. I can try and find the old > description if you'd like more. > > > > ** > Keith: > This example: > > "an ether switch wherein each interface might have its own physical > address but the box elects to use a single ether address for some > or most purposes" > > has long been modeled in the Bridge MIB WG as the "switch" having > an internal interface with its own MAC address which id independent of > its external interfaces. > > In any case, it's not IPv6-specific. That is, if such an object were > needed, it would be needed for IPv4 as well, or any past internetwork > protocol (e.g., DECNET) or any future internetwork protocol (IPv9). > > Bottom line: I believe the solution to this issue is to have an extra > ifTable row for the second MAC address. Even if I'm wrong, it's an > ifTable issue, not an IPv6 (or IPv4) issue, and therefore must not be > in this MIB. I agree that this is an ifTable issue and should not be in the IP MIB module. I support removing it. > > ** > > Previously I was attempting to maintain a potentially useful object. > Upon reflection I have decided that if a better justification for keeping > the object can't be found it should be removed. > > If there is no discussion I shall remove this object. If you feel it is > a useful object and should be kept send mail by the deadline that the chairs > specify. Thanks for the follow-up Shawn. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 29 15:15:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22844 for ; Mon, 29 Mar 2004 15:15:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B839Z-0006nN-4U for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 15:14:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TKEbpF026112 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 15:14:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B839Y-0006n0-VJ for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 15:14:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22749 for ; Mon, 29 Mar 2004 15:14:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B839X-0005yc-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 15:14:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B838a-0005od-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 15:13:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B837c-0005gX-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 15:12:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8371-0005H5-S7; Mon, 29 Mar 2004 15:11:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B836l-0005Ab-AH for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 15:11:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22445 for ; Mon, 29 Mar 2004 15:11:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B836i-0005Yt-00 for ipv6@ietf.org; Mon, 29 Mar 2004 15:11:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B835m-0005QN-00 for ipv6@ietf.org; Mon, 29 Mar 2004 15:10:43 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1B834z-00058o-00 for ipv6@ietf.org; Mon, 29 Mar 2004 15:09:53 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2TK9Dng027544; Mon, 29 Mar 2004 12:09:14 -0800 (PST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2TK9BQ10010; Mon, 29 Mar 2004 22:09:11 +0200 (MEST) Date: Mon, 29 Mar 2004 12:09:13 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND-proxy applicability and loop-prevention To: Pekka Savola Cc: Erik Nordmark , Ole Troan , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > The problem is that with the same trouble it takes to fully delegate a > /64, the ISP could do a /48 as well. That is a good thing also, of > course. My worry is that the ISPs end up doing nothing unless they > have simple enough means available. My worry is that ISPs would end up doing nothing because of the existance of nd proxy. Hence I conclude we should make prefix delegation work and make the implementations of it as easy as possible to use. Then the ISP can decide whether to delegate nothing (and customer gets a single address) or delegate /64, /48. > I mean, the message could also be "just give every customer a > delegated /48. If that is not possible, advertising a /64 on the link > is better than nothing." Yes, but that requires a non-robust against loops nd-proxy complexity to be added to the architecture. In the big picture this is a distraction and not a help. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 29 16:12:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26712 for ; Mon, 29 Mar 2004 16:12:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B842k-0004nV-Vj for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 16:11:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TLBcxd018439 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 16:11:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B842k-0004nK-Ni for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 16:11:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26667 for ; Mon, 29 Mar 2004 16:11:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B842j-0006fQ-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 16:11:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B841m-0006Xx-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 16:10:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B840q-0006RC-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 16:09:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B840E-0004RV-3S; Mon, 29 Mar 2004 16:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83zw-0004Qg-UZ for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 16:08:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26586 for ; Mon, 29 Mar 2004 16:08:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B83zv-0006Jd-00 for ipv6@ietf.org; Mon, 29 Mar 2004 16:08:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B83z1-0006Cl-00 for ipv6@ietf.org; Mon, 29 Mar 2004 16:07:48 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B83yb-00065B-00 for ipv6@ietf.org; Mon, 29 Mar 2004 16:07:22 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Mar 2004 13:12:55 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2TL6lKj010607; Mon, 29 Mar 2004 13:06:48 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.128]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHE82236; Mon, 29 Mar 2004 16:06:45 -0500 (EST) Message-Id: <4.3.2.7.2.20040329160046.02abd438@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Mar 2004 16:06:42 -0500 To: Erik Nordmark From: Ralph Droms Subject: Re: ND-proxy applicability and loop-prevention Cc: Pekka Savola , Erik Nordmark , Ole Troan , ipv6@ietf.org In-Reply-To: References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 12:09 PM 3/29/2004 -0800, Erik Nordmark wrote: > > The problem is that with the same trouble it takes to fully delegate a > > /64, the ISP could do a /48 as well. That is a good thing also, of > > course. My worry is that the ISPs end up doing nothing unless they > > have simple enough means available. I know that there are service providers in Japan that plan to use DHCP PD to provide /48 prefixes to customers. Therefore, DHCP PD is apparently "simple enough" that some ISPs do not consider it a barrier to deployment. Do we have any examples of ISPs that have reviewed DHCP PD and rejected it as not simple enough? >My worry is that ISPs would end up doing nothing because of the existance >of nd proxy. >Hence I conclude we should make prefix delegation work and make the >implementations of it as easy as possible to use. >Then the ISP can decide whether to delegate nothing (and customer gets >a single address) or delegate /64, /48. I agree that we should continue to work on improving prefix delegation (if, indeed., it needs improvement). > > I mean, the message could also be "just give every customer a > > delegated /48. If that is not possible, advertising a /64 on the link > > is better than nothing." > >Yes, but that requires a non-robust against loops nd-proxy complexity >to be added to the architecture. >In the big picture this is a distraction and not a help. > > Erik I agree here, as well ... we have a solution that works, has been accepted as a standard and is being deployed. - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Mon Mar 29 17:55:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01504 for ; Mon, 29 Mar 2004 17:55:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B85ee-0004gm-5r for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 17:54:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TMsqjx018018 for ipv6-archive@odin.ietf.org; Mon, 29 Mar 2004 17:54:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B85ee-0004gX-0O for ipv6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 17:54:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01419 for ; Mon, 29 Mar 2004 17:54:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B85eb-0006s7-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 17:54:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B85dN-0006W2-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 17:53:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B85cF-0006Es-00 for ipv6-web-archive@ietf.org; Mon, 29 Mar 2004 17:52:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B85bt-00041X-Bi; Mon, 29 Mar 2004 17:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B85bD-0003zc-Qm for ipv6@optimus.ietf.org; Mon, 29 Mar 2004 17:51:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01051 for ; Mon, 29 Mar 2004 17:51:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B85bB-0005y0-00 for ipv6@ietf.org; Mon, 29 Mar 2004 17:51:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B85Zn-0005ev-00 for ipv6@ietf.org; Mon, 29 Mar 2004 17:49:52 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B85Z0-0005Ob-00 for ipv6@ietf.org; Mon, 29 Mar 2004 17:49:02 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2004 14:57:15 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2TMlvsk027051; Tue, 30 Mar 2004 00:47:58 +0200 (MET DST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA25206; Mon, 29 Mar 2004 23:47:28 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Cc: Erik Nordmark , Subject: Re: ND-proxy applicability and loop-prevention References: From: Ole Troan Date: Mon, 29 Mar 2004 23:47:28 +0100 In-Reply-To: (Pekka Savola's message of "Mon, 29 Mar 2004 22:00:05 +0300 (EEST)") Message-ID: <7t5n05z8e4f.fsf@mrwint.cisco.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Pekka, et al, >> I think RFC 3177 is quite clear on its recommendation. Why can't >> we simplify the message and avoid developping additional protocols >> (which are as likely to slow down IPv6 deployment as speeding it >> up) by saying that ISPs which don't delegate at least a /64 (using >> a protocol/mechanism which delegates it to the *subscriber* and not >> just assigning it to the link from the ISP and the subscriber) >> doesn't follow the implications of the recommendation in 3177? > > The problem is that with the same trouble it takes to fully delegate > a /64, the ISP could do a /48 as well. That is a good thing also, > of course. My worry is that the ISPs end up doing nothing unless > they have simple enough means available. > > I mean, the message could also be "just give every customer a > delegated /48. If that is not possible, advertising a /64 on the link > is better than nothing." seems to me that we're trying to engineer a solution to a problem which we _think_ may exist, but only because we don't trust the ISPs to do the right thing. the IETF has already given the recommendation that each user should get a /48, as long as we make protocols, so that it is a cheap to delegate a /48 as a /64 we've done out job. the market should sort the rest out. if that turns out to be wrong, then we have enough alternatives we can work on then. - ND proxy - RA proxy - MLSR - bridging - longer prefixes than /64 - NAT - ... /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 11:36:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27510 for ; Tue, 30 Mar 2004 11:36:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MDB-00084a-49 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 11:35:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UGZbwT031032 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 11:35:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MDA-00084R-Ad for ipv6-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 11:35:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27504 for ; Tue, 30 Mar 2004 11:35:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8MD9-0005tu-00 for ipv6-web-archive@ietf.org; Tue, 30 Mar 2004 11:35:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8MCE-0005kP-00 for ipv6-web-archive@ietf.org; Tue, 30 Mar 2004 11:34:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8MBX-0005a8-00 for ipv6-web-archive@ietf.org; Tue, 30 Mar 2004 11:33:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MAf-0007Xv-TJ; Tue, 30 Mar 2004 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MA1-0007LR-SQ for ipv6@optimus.ietf.org; Tue, 30 Mar 2004 11:32:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27330 for ; Tue, 30 Mar 2004 11:32:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8MA0-0005Lr-00 for ipv6@ietf.org; Tue, 30 Mar 2004 11:32:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8M93-0005BK-00 for ipv6@ietf.org; Tue, 30 Mar 2004 11:31:22 -0500 Received: from web41801.mail.yahoo.com ([66.218.93.135]) by ietf-mx with smtp (Exim 4.12) id 1B8M87-0004sT-00 for ipv6@ietf.org; Tue, 30 Mar 2004 11:30:23 -0500 Message-ID: <20040330162952.60127.qmail@web41801.mail.yahoo.com> Received: from [63.158.252.52] by web41801.mail.yahoo.com via HTTP; Tue, 30 Mar 2004 08:29:52 PST Date: Tue, 30 Mar 2004 08:29:52 -0800 (PST) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2004: May 13-14, 2004, Las Vegas To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1390520775-1080664192=:58683" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 --0-1390520775-1080664192=:58683 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA27331 Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Internetworking 2004=20 May 13-14, 2004 Las Vegas Convention Center, Las Vegas, Nevada http://www.caitr.org/internetworking04/index.htm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Internetworking 2004, for the first time collocated with NetWorld+Interop= , aims to address some of the main issues of concern within IP networking= and the Internet. This exclusive leading-edge technology program covers = innovative solutions for Enterprises, Service Providers, networking equip= ment manufacturers, government and others.=20 =20 The Internetworking 2004 conference, comprised of comprehensive technical= sessions, panels, and case studies for real operational networks, is int= ended as a forum for technical discussions on topics including:=20 =20 =95 Voice over IP (VoIP) and Convergence =95 Multiservice Network Design and Planning =95 Virtual Private Networks (VPNs) =95 Routing: Unicast & Multicast=20 =95 Wireless Internet=20 =95 Next Generation Mobile Networks=20 =95 Quality of Service (QoS) =95 Network Security=20 =95 Network Processors=20 =95 Service Integration=20 =95 Operational Support Systems=20 =95 Network Survivability and Fault Management=20 =95 Internetworking IP and Optical Networks=20 ***EXCLUSIVE ALUMNI DISCOUNT*** We are pleased to extend a special alumni discount for the 2-day Internet= working 2004 Pass. Purchase the pass for $595.00, a $500.00 savings off t= he regular price. Visit for Priority Code and registration details.=20 We look forward to seeing you at the only end-to-end networking and commu= nications event. =20 Sincerely, The NetWorld+Interop Team http://www.interop.com/ --0-1390520775-1080664192=:58683 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA27331 Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /DIV>
Internetworking 2004
May 13-14, 2004
Las Vegas Convention Cen= ter, Las Vegas, Nevada
http://www.caitr.org/internetworking04/index.htm
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /DIV>
 
Internetworking 2004, for the first time collocated with NetWorld+In= terop, aims to address some of the main issues of concern within IP netwo= rking and the Internet. This exclusive leading-edge technology program co= vers innovative solutions for Enterprises, Service Providers, networking = equipment manufacturers, government and others.
 
The Internetworking 2004 conference, comprised of comprehensive tech= nical sessions, panels, and case studies for real operational networks, i= s intended as a forum for technical discussions on topics including:
 
=95 Voice over IP (VoIP) and Convergence
=95 Multiservice Network= Design and Planning
=95 Virtual Private Networks (VPNs)
=95 Routin= g: Unicast & Multicast
=95 Wireless Internet
=95 Next Generat= ion Mobile Networks
=95 Quality of Service (QoS)
=95 Network Secur= ity
=95 Network Processors
=95 Service Integration
=95 Operat= ional Support Systems
=95 Network Survivability and Fault Management =
=95 Internetworking IP and Optical Networks
***EXCLUSIVE ALUMNI DISCOUNT***
We are pleased to extend a s= pecial alumni discount for the 2-day Internetworking 2004 Pass. Purchase = the pass for $595.00, a $500.00 savings off the regular price. Visit= <= http://www.caitr.org/internetworking04/registration.htm> for Prior= ity Code and registration details.

We look forward to seeing you at the only end-to-end networking = and communications event.
 
Sincerely,
The NetWorld+Interop Team
http://www.interop.com/
--0-1390520775-1080664192=:58683-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:29:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17784 for ; Tue, 30 Mar 2004 17:29:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006Zv-Qt for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP09lPD021612 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 19:09:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQm2-0005cV-LN for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 19:09:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12722 for ; Mon, 24 Nov 2003 19:09:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQlz-0001OO-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 19:09:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOQly-0001OI-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 19:09:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQkN-00054s-7c; Mon, 24 Nov 2003 19:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQkJ-00054F-Lg for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 19:07:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12654 for ; Mon, 24 Nov 2003 19:07:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQkG-0001Lv-00 for ipv6@ietf.org; Mon, 24 Nov 2003 19:07:56 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AOQkF-0001Ls-00 for ipv6@ietf.org; Mon, 24 Nov 2003 19:07:55 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5E2A7AFD2D; Mon, 24 Nov 2003 19:07:51 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04354-13; Mon, 24 Nov 2003 19:07:50 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5B1F1AFC0D; Mon, 24 Nov 2003 19:07:50 -0500 (EST) Date: Mon, 24 Nov 2003 18:59:33 -0500 From: Keith Moore To: Fred Templin Cc: moore@cs.utk.edu, brc@zurich.ibm.com, ipv6@ietf.org Subject: Re: names for non-global addresses Message-Id: <20031124185933.7be21459.moore@cs.utk.edu> In-Reply-To: <3FC29956.30900@iprg.nokia.com> References: <51B9F7C2-1EB9-11D8-89BF-000393DB5366@cs.utk.edu> <3FC29956.30900@iprg.nokia.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > You are coming dangerously close to completing the full-circle and > bringing us back to the term "limited range" which was en vogue for > some time. well, to me "limited range" seems less dangerous than "private addresses", but others might disagree. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:29:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17785 for ; Tue, 30 Mar 2004 17:29:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006Zv-TD for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i147iaOO025583 for ipv6-archive@odin.ietf.org; Wed, 4 Feb 2004 02:44:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHi8-0006eY-En for ipv6-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 02:44:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23766 for ; Wed, 4 Feb 2004 02:44:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHi4-0000MD-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 02:44:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHh3-0000C6-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 02:43:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoHgG-00002u-00 for ipv6-web-archive@ietf.org; Wed, 04 Feb 2004 02:42:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHel-0005Uv-U0; Wed, 04 Feb 2004 02:41:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHdg-0005Qf-Oj for ipv6@optimus.ietf.org; Wed, 04 Feb 2004 02:40:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23373 for ; Wed, 4 Feb 2004 02:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHdc-0007bf-00 for ipv6@ietf.org; Wed, 04 Feb 2004 02:39:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHch-0007Wp-00 for ipv6@ietf.org; Wed, 04 Feb 2004 02:39:00 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AoHc3-0007Rw-00 for ipv6@ietf.org; Wed, 04 Feb 2004 02:38:19 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0047F1525D for ; Wed, 4 Feb 2004 16:38:17 +0900 (JST) Date: Wed, 04 Feb 2004 16:38:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [2462bis] preferred lifetime and the 'two-hour' rule 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 While working on the rfc2462bis (stateless address autoconf) work, I've found a new issue, and would like to hear opinions. The current RFC2462 describes in Section 5.5.3 e) how the valid lifetime of an autoconfigured address is updated, considering the avoidance of DoS attack with too short lifetimes. However, it doesn't mention preferred lifetimes. 5.5.3 e) says: e) If the advertised prefix matches the prefix of an autoconfigured address (i.e., one obtained via stateless or stateful address autoconfiguration) in the list of addresses associated with the interface, the specific action to perform depends on the Valid Lifetime in the received advertisement and the Lifetime associated with the previously autoconfigured address (which we call StoredLifetime in the discussion that follows): ... This document doesn't say anything about preferred lifetimes from this part to the end of this section. On the other hand, RFC1971, which was obsoleted by RFC2462, clearly said in Section 5.5.3 how the preferred lifetime should be updated: d) If the advertised prefix matches the prefix of an autoconfigured address (i.e., obtained via stateless or stateful address autoconfiguration) in the list of addresses associated with the interface, set the preferred timer to that of the option's preferred <--- lifetime, and set the valid lifetime to that of the option's valid lifetime. I guess this part was unintentionally dropped in RFC2462 while we concentrated on the DoS avoidance. If so, it should make sense to recover this part in rfc2462bis. Possible options include: 1) update the preferred lifetime regardless of whether the valid lifetime is accepted or not wrt the "two-hour" rule 2) update the preferred lifetime only when the valid lifetime is accepted 3) leave this as implementation dependent I don't think option 3 is the way to go, since RFC1971 clearly mentioned the preferred lifetime. The KAME/BSD implementation behaves as option 1. However, it seems to me that option 2 makes much more sense because a rejected valid lifetime indicates a possibility of attack and the other parts of the information may then be bogus as well. And, in fact, item 2 of 5.5.3 e) says: 2) If the StoredLifetime is less than or equal to 2 hours and the received Lifetime is less than or equal to StoredLifetime, ignore the prefix,... that is, it specifies ignoring "the prefix", not just "the valid lifetime". What do others think? As I already indicated, I'd propose to revise the text clearly with option 2 above. 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 exim@www1.ietf.org Tue Mar 30 17:41:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18919 for ; Tue, 30 Mar 2004 17:41:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006YH-Hj for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i245l17F027374 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 00:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylhF-00077R-Jb for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 00:47:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01516 for ; Thu, 4 Mar 2004 00:46:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AylhC-0003dB-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:46:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aylfe-0003C2-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:45:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayle9-0002lv-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:43:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayle9-0006rz-Ja for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:43:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyldN-0005cJ-R6; Thu, 04 Mar 2004 00:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayld0-0005Yb-F7 for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 00:42:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00932 for ; Thu, 4 Mar 2004 00:42:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aylcx-0002TR-00 for ipv6@ietf.org; Thu, 04 Mar 2004 00:42:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aylba-0002Dg-00 for ipv6@ietf.org; Thu, 04 Mar 2004 00:41:11 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AylaZ-0001vs-00 for ipv6@ietf.org; Thu, 04 Mar 2004 00:40:07 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 21:40:02 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Mar 2004 21:39:45 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 21:39:43 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 21:40:34 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 3 Mar 2004 21:39:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v6 host load balancing Date: Wed, 3 Mar 2004 21:39:29 -0800 Message-ID: Thread-Topic: v6 host load balancing thread-index: AcQBp6u9tjxkpQ1HT0+dLorR06S+1wAAmAvg From: "Dave Thaler" To: "Changming Liu" Cc: X-OriginalArrivalTime: 04 Mar 2004 05:39:41.0091 (UTC) FILETIME=[170BEF30:01C401AB] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Changming Liu [mailto:cliu@netscreen.com] > Sent: Thursday, March 04, 2004 2:14 PM > To: Dave Thaler; Changming Liu > Cc: 'ipv6@ietf.org ' > Subject: RE: v6 host load balancing >=20 > Hi Dave, >=20 > >If the server is telling the client who to use, then the client is > >connecting out for both the data and the control channels. If they > >go out different exit points on the client side, there's no problem > >since both connections are initiated from the inside, right? >=20 > >Can you elaborate more on what the problematic scenario is? >=20 > Sure. In case of FTP data channel, the data connection was opened by the > server by default! This is called active FTP. To get around this problem, > RFC1579 Firewall-Friendly FTP, documents a passive open, in this case, the > client initiates a connection. For more info, please see RFC 1579. Yes I'm aware of both modes. Since you mentioned the server told the client what server to use, I assumed you were talking about passive mode, which is what I was responding to above. > No matter it is active or passive open, the modem stateful will need to > open > the "hole" by listening to the control channel for "port" and "pasv" > comamnd. You lost me here. Since the passive open has the connection initiated by the client, there is no need for the firewall around the client to open a port based on listening to the control channel, right? > The hole is opened only on the firewall which is dealing the > control channel. If the data channel goes to another file, apparently this > will not work. I don't see why not. It's just another outgoing TCP connection. > FTP is just a classical example of this dynamic port problem that a > firewall > needs to deal with. For VoiP apps such H323 and SIP, similar problem > exists > as well and even severe. This is because the signalling channel and media > channel are totally different and destination are usually completely > different. >=20 >=20 > As a firewall/NAT/IDP company we've been struggling with these issues all > the time. It really adds lots of complexity to the system. I just don't > want > to get it worse in IPv6, if not better. >=20 > Hope this makes sense to you. Not particularly. I'm still at the same point I was before where=20 elaborating on what the exact scenario that fails is would help. Thanks, -Dave > Changming -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:44:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19299 for ; Tue, 30 Mar 2004 17:44:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006a4-4r for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221nWxI009952 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 20:49:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axz2J-0002Y2-Ox for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 20:49:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21429 for ; Mon, 1 Mar 2004 20:49:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axz2H-0002Yr-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:49:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axz1T-0002Oa-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:48:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axz0I-0002GI-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 20:47:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyzt-0001rG-8N; Mon, 01 Mar 2004 20:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyz7-0001q2-Vb for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 20:46:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21129 for ; Mon, 1 Mar 2004 20:46:10 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyz5-000268-00 for ipv6@ietf.org; Mon, 01 Mar 2004 20:46:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axyy8-0001yu-00 for ipv6@ietf.org; Mon, 01 Mar 2004 20:45:13 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1AxyxP-0001rl-00 for ipv6@ietf.org; Mon, 01 Mar 2004 20:44:27 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i221iOL12211; Tue, 2 Mar 2004 03:44:25 +0200 (EET) X-Scanned: Tue, 2 Mar 2004 03:44:20 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i221iKAm028092; Tue, 2 Mar 2004 03:44:20 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00h8QaR9; Tue, 02 Mar 2004 03:44:18 EET 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 i221iIO23484; Tue, 2 Mar 2004 03:44:18 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Mar 2004 03:44:20 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: IETF 59 IPv6 WG Document Status Date: Tue, 2 Mar 2004 03:44:17 +0200 Message-ID: Thread-Topic: IETF 59 IPv6 WG Document Status thread-index: AcP/7Mi0gWWEWM6UQxW1ZjH4xpUrPgACuEPA To: , X-OriginalArrivalTime: 02 Mar 2004 01:44:20.0174 (UTC) FILETIME=[E17F7EE0:01C3FFF7] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Brian, For the IPv6 Nodes Requirement, Revised ID Needed draft-ietf-ipv6-node-requirements-08.txt (To be discussed in WG = session)=20 The document has been revised, I just want a sanity check on a couple of = things, but I think the document should be marked "This version addresses IESG = DISCUSS comments." John > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On Behalf Of ext > Brian Haberman > Sent: 02 March, 2004 02:20 > To: ipv6@ietf.org > Subject: IETF 59 IPv6 WG Document Status >=20 >=20 > All, > The chairs have decided to handle document status differently > at IETF 59. Rather than spending valuable meeting time on status, > we have created a webpage with the current status of all documents. > It is now available at: >=20 > http://www.innovationslab.net/~brian/IETF59/IPv6/IPv6DocumentS tatus.html If you have questions or comments on the status, feel free to raise them at the beginning of the meeting. This pointer will also be on the agenda slide prior to the beginning of the meeting. Regards, Brian & Bob -------------------------------------------------------------------- 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 exim@www1.ietf.org Tue Mar 30 17:44:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19503 for ; Tue, 30 Mar 2004 17:44:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjj-0006YH-VT for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23869VF005311 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 03:06:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyROE-0001Mj-Je for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 03:06:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09309 for ; Wed, 3 Mar 2004 03:05:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRNv-00011H-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 03:05:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRMp-0000oY-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 03:04:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyRM2-0000cr-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 03:03:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRLU-0000aP-Qe; Wed, 03 Mar 2004 03:03:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRKn-0000S1-C7 for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 03:02:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08929 for ; Wed, 3 Mar 2004 03:02:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRKK-0000CV-00 for ipv6@ietf.org; Wed, 03 Mar 2004 03:02:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRIw-0007gJ-00 for ipv6@ietf.org; Wed, 03 Mar 2004 03:00:36 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AyRHJ-000795-00 for ipv6@ietf.org; Wed, 03 Mar 2004 02:58:53 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 2 Mar 2004 23:56:55 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Mar 2004 23:56:58 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 23:55:37 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Mar 2004 23:57:14 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 2 Mar 2004 23:56:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ndproxy and SEND Date: Tue, 2 Mar 2004 23:56:50 -0800 Message-ID: Thread-Topic: ndproxy and SEND thread-index: AcQAs1oteMlMAlfbSnOeKYKsDacsmgAQFmAg From: "Dave Thaler" To: X-OriginalArrivalTime: 03 Mar 2004 07:56:53.0548 (UTC) FILETIME=[178F6EC0:01C400F5] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I mostly agree with Erik's suggested text, but would reword it a bit to say three things: 1) the concept of proxied NAs is not introduced by this draft, it's in the base ND spec, and the mechanisms in this draft do=20 not introduce any additional security issues beyond the ones=20 inherent in the base ND spec (which at Draft Std) 2) IPv4 ARP proxying is widely deployed and the security of this spec is no worse than IPv4 ARP proxying. Hence it does not make the situation worse, but instead provides the potential for adding security in the future. 3) this document assumes that securing proxyied NA's would be=20 done by an extension to SEND -Dave > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Wednesday, March 03, 2004 9:06 AM > To: Dave Thaler > Cc: ipv6@ietf.org > Subject: ndproxy and SEND >=20 > draft-thaler-ipv6-ndproxy-02.txt says: >=20 > > o Support secure IPv6 neighbor discovery. This is discussed in > > the Security Considerations section. >=20 > I don't understand what it means to support SEND, given that the > combination of SEND and ndproxy currently doesn't work. >=20 > > As a result, securing Neighbor Discovery or ARP must take into > > account the ability to proxy messages. This document does not > > introduce any new requirements in this regard. >=20 > I would be much clearer if the document instead said > This document assumes that SEND provide security for > proxy neighbor advertisement. >=20 > The fact that SEND doesn't currently provide security for proxy neighbor > advertisements is an indication that 1) there isn't much perceived need > for it and/or 2) it is hard to do since authorization is a challenge. >=20 > Hence it is useful to be very clear about the assumption on what SEND > provides. >=20 > Erik >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:45:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19570 for ; Tue, 30 Mar 2004 17:45:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjj-0006a4-QV for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5NbRxp014543 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 18:37:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXDJ-0003m9-88 for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 18:37:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01257 for ; Wed, 5 Nov 2003 18:37:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXDG-0005os-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 18:37:22 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHXDF-0005op-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 18:37:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXCw-0003MY-Tl; Wed, 05 Nov 2003 18:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXCq-0003LQ-Nd for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 18:36:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01244 for ; Wed, 5 Nov 2003 18:36:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXCn-0005oF-00 for ipv6@ietf.org; Wed, 05 Nov 2003 18:36:53 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AHXCn-0005o9-00 for ipv6@ietf.org; Wed, 05 Nov 2003 18:36:53 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 9EB2CAFBEB; Wed, 5 Nov 2003 18:36:53 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07649-14; Wed, 5 Nov 2003 18:36:52 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id A73C9AFBE4; Wed, 5 Nov 2003 18:36:52 -0500 (EST) Date: Wed, 5 Nov 2003 18:33:10 -0500 From: Keith Moore To: nisse@lysator.liu.se (Niels =?ISO-8859-1?Q?M=F6ller?=) Cc: moore@cs.utk.edu, gene@nttmcl.com, ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) Message-Id: <20031105183310.7092846f.moore@cs.utk.edu> In-Reply-To: References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> <20031104141639.1c9d1d56.moore@cs.utk.edu> <3FA824FD.2040807@nttmcl.com> <20031104164402.68a39b3f.moore@cs.utk.edu> <20031104175008.51e17e6a.moore@cs.utk.edu> <20031105070744.0c7b9f52.moore@cs.utk.edu> <20031105124202.7f66134c.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Keith Moore writes: > > > Or you could redirect attempts to ssh to host X so that they go to > > host Y instead. This is not an inherently desirable feature. > > Sure, but if I have write access to the DNS configuration (so that I > can add the SRV record), then I don't need any SRV records to do that > redirection, plain A or CNAME works fine. SRV just let's me do it on a > more fine grained scale. in other words, it lets you mount precision attacks :) > > > If the server administrater wants it: Sure. Nobody else can really > > > decide whether or not SRV is "useful" or "appropriate" for a > > > particular service instance. > > > > Nor, for that matter, can the DNS server administrator. > > The server and administrator and DNS server administrator have to > cooperate. If they for some reason refuse to do that, they simply > can't deploy SRV in any useful way. You missed my point, which was that the DNS server admin is usually not in a position to know whether it's appropriate to impose SRV records on a particular app - unless perhaps the app specifies how and when it's okay to do that. SRV is not a general-purpose club that you can beat apps with. > > For instance, http://example.com:80/foo/bar will be canonicalized to > > http://example.com/foo/bar - which, if there were a SRV record for > > _http._tcp.example.com pointing to a different port or host, would > > change the meaning of the URL. > > Thanks, that's a good point. It's got more to do with URL syntax than > with the http protocol per se, it's pretty hard to separate HTTP and URL syntax; HTTP and URLs are very closely tied together. > but it still seems like it could be a > real problem with using SRV records for http. It's just one example among many. Some protocols can run perfectly well on any port; others have assumptions about port numbers wired-in , and often they are not obvious. The point is that one size does not fit all, and imposing SRV on all apps will break things. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:45:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19688 for ; Tue, 30 Mar 2004 17:45:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjj-0006WI-Kq for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21AD0Rg003389 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 05:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkPw-0000rO-Fe for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 05:12:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06882 for ; Mon, 1 Mar 2004 05:12:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxkPe-0000WY-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 05:12:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxkOm-0000Oh-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 05:11:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxkNu-0000Gm-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 05:10:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkNH-0000OB-Lk; Mon, 01 Mar 2004 05:10:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkMe-0000Hg-IB for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 05:09:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06678 for ; Mon, 1 Mar 2004 05:09:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxkMb-00007B-00 for ipv6@ietf.org; Mon, 01 Mar 2004 05:09:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxkLc-000019-00 for ipv6@ietf.org; Mon, 01 Mar 2004 05:08:29 -0500 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 1AxkKd-0007fv-00 for ipv6@ietf.org; Mon, 01 Mar 2004 05:07:27 -0500 Received: from [IPv6:::1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 5B1BA8; Mon, 1 Mar 2004 12:19:36 +0200 (EET) In-Reply-To: References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> <20040301055112.GA20621@zoic.org> <03a901c3ff64$e76f0110$3e6015ac@dclkempt40> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2A469A53-6B68-11D8-8A26-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: "Nick 'Sharkey' Moore" , , , "James Kempf" From: Pekka Nikander Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Mon, 1 Mar 2004 19:06:53 +0900 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > To summarize the points, I'd propose to do nothing on this in > rfc2462bis because: > > - the actual odds of the problem in the real world should be very low, > even in the current status. > - if we take the proposed change in rfc2462bis, the odds will be > getting lower and lower. > - if we add something for this to rfc2462bis, the protocol will become > complicated, degrading one of the motivations of this clarification. From the SEND point of view, looks good. --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:46:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19712 for ; Tue, 30 Mar 2004 17:46:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006Xa-KY for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA59KT1j015376 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 04:20:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJq0-0003zs-4z for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 04:20:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27584 for ; Wed, 5 Nov 2003 04:20:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJpx-0007mS-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 04:20:25 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHJpw-0007mP-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 04:20:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJpa-0003mF-V9; Wed, 05 Nov 2003 04:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHJpA-0003kO-NL for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 04:19:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27524 for ; Wed, 5 Nov 2003 04:19:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHJp7-0007kq-00 for ipv6@ietf.org; Wed, 05 Nov 2003 04:19:33 -0500 Received: from mail.lysator.liu.se ([130.236.254.3]) by ietf-mx with esmtp (Exim 4.12) id 1AHJp7-0007kk-00 for ipv6@ietf.org; Wed, 05 Nov 2003 04:19:33 -0500 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 1DBD65269E; Wed, 5 Nov 2003 10:19:31 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 6F7C515444; Wed, 5 Nov 2003 10:19:29 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hA59JTAj003696; Wed, 5 Nov 2003 10:19:29 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hA59JNPR003693; Wed, 5 Nov 2003 10:19:23 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Keith Moore Cc: gene@nttmcl.com, ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> <20031104141639.1c9d1d56.moore@cs.utk.edu> <3FA824FD.2040807@nttmcl.com> <20031104164402.68a39b3f.moore@cs.utk.edu> <20031104175008.51e17e6a.moore@cs.utk.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 05 Nov 2003 10:19:21 +0100 In-Reply-To: <20031104175008.51e17e6a.moore@cs.utk.edu> Message-ID: Lines: 81 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Content-Transfer-Encoding: 8bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Keith Moore writes: > > As far as I can see, the only good reason to have the service argument > > in getaddrinfo is to make it possible for getaddrinfo to perform SRV > > lookups. > > that's not a good reason, that's a disaster. That's a strong word, given that the only effect on lookups in the majority of domains that haven't deployed SRV, is one more roundtrip to the local caching dns-server. Or if you do lookups in parallell, you ask for A, AAAA and SRV instead of just A and AAAA. > it would also tempt NATs to tweak DNS in even more preverse > ways than they already do. I don't understand how this is relevant. It should work fine unless the NAT operator does anything stupid, and that's the highest level of NAT-support we can expect for any protocol. > there's a reason that RFC 2782 contains the following text: > > Service SRV records SHOULD NOT be used in the absence > of such specification. Right, for each particular domain and service, there's a choice that has to be made before deploying SRV. In order for SRV-records to be used for a particular service, both ends must have it: There must be SRV records configured in the DNS-server for the domain, and the client must ask for and use them. (To be precise, I'd say that if a client that asks for SRV records, gets a NODATA answer, and then falls back to the good old A, AAAA and getservbyname, then SRV is "not used". You may say there are security issues, but from reading the security considerations section of RFC2782, I don't think there's a real problem). The effect of of having getaddrinfo try SRV lookup (or generally, having a random client application ask for SRV records by default) is to make it possible for the operator of the domain in question to easily implement her choice. The effect is that the client applications delegate the decision "should I be using SRV records for this particular " to the operator of the corresponding DNS domain. This depends on how you want to deploy SRV, I guess. To me, it makes sense with a gradual deployment per . And then it seems useful if applications by default use SRV records whenever the operator of a domain has bothered to configure relevant SRV-records in the right DNS server. My current interest in SRV is that I'm hacking Ian Jackson's resolver library "adns" to support IPv6 and SRV. This includes an adns_getaddrinfo function which asks for SRV-records, and in the absense of SRV-records, constructs a fake SRV-record from A and AAAA records and getservbyname. Unlike getaddrinfo, SRV lookup is an advertised feature, and the function returns SRV records, not just a list of addresses. If there's any good reason why I shouldn't recommend random client applications to use this function, I'd like to know about it. Ah, and one more question: After a first look around for SRV records in the current DNS infrastructure, I've found SRV records for the following services: ftp, http, kerberos, kpasswd, and sip. I imagine SIP, being a recent protocol, actually specifies the use of SRV (I haven't read the SIP specs). What about the others, does there exist any standards track spec, as required by the RFC2782 applicbility statement, endorsing SRV-records for e.g. ftp, http and kerberos? For example, try host -l sunet.se sunic.sunet.se |grep SRV host -l ingate.se usagi.ingate.se |grep SRV for two domains that are operated by people who I believe are not clueless about the DNS. Best regards, /Niels PS. I'm afraid API and deployment issues border on off-topic on the ipv6 list. Feel free to send followups elsewhere (and Cc: me), or to answer privately. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:50:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20563 for ; Tue, 30 Mar 2004 17:50:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rji-0006Zv-QU for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TK0Ph5018761 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 15:00:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwUQ-0004sN-Le for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 15:00:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01802 for ; Wed, 29 Oct 2003 15:00:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwUN-00020A-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 15:00:19 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEwUN-000206-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 15:00:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwU8-0004ix-5T; Wed, 29 Oct 2003 15:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwT7-0004do-PP for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 14:59:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01723 for ; Wed, 29 Oct 2003 14:58:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwT4-0001xu-00 for ipv6@ietf.org; Wed, 29 Oct 2003 14:58:58 -0500 Received: from [206.157.230.254] (helo=hatl0ms22.CORP.COX.COM) by ietf-mx with esmtp (Exim 4.12) id 1AEwT4-0001xI-00 for ipv6@ietf.org; Wed, 29 Oct 2003 14:58:58 -0500 Received: from catl0ms22.corp.cox.com ([10.62.200.101]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 14:58:27 -0500 Received: from mail pickup service by catl0ms22.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 14:53:02 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 02:33:31 -0500 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 02:33:30 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T7XUP22108 for ; Wed, 29 Oct 2003 02:33:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEkjM-000PDz-8p for v6ops-data@psg.com; Wed, 29 Oct 2003 07:27:00 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEkjJ-000PDY-3y for v6ops@ops.ietf.org; Wed, 29 Oct 2003 07:26:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T7Qo920283; Wed, 29 Oct 2003 09:26:50 +0200 Date: Wed, 29 Oct 2003 09:26:50 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031029071117.EA85D13@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Precedence: bulk X-OriginalArrivalTime: 29 Oct 2003 07:33:30.0976 (UTC) FILETIME=[F3836E00:01C39DEE] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Wed, 29 Oct 2003 itojun@iijlab.net wrote: [...] > >Remember, the most important thing we should care about is that dual-stack > >deployments can get more common without causing problems for *IPv4* or > >services in general. AI_ADDRCONFIG is one step in that direction. > > for your story to be effective it has to be host-wide configuration > knob, not a parameter to library function. (we cannot change every > program we use to have AI_ADDRCONFIG) Yep, or the apps writing guidelines could recommend to turn it on. The basic API spec already defines "AI_DEFAULT" even though it doesn't (AFAIR) specify that it should be the default :-) > and we (*BSD groups) ship programs without AI_ADDRCONFIG, and they > work just fine... Yep, to the extent they're used. Stig already mentioned that some apps are moving to some custom address lookup hacks from getaddrinfo() due to these problems. The use of AI_ADDRCONFIG should help in the majority of cases, i.e., deploying v6-capable apps on nodes which don't have v6 connectivity yet. -- 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 exim@www1.ietf.org Tue Mar 30 17:51:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20797 for ; Tue, 30 Mar 2004 17:51:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjh-0006ZK-9V for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADFfDH4020455 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 10:41:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJaq-0005Il-5v for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 10:41:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03451 for ; Thu, 13 Nov 2003 10:40:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJan-00076y-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:41:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJan-00076v-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 10:41:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJah-0005Al-Vr; Thu, 13 Nov 2003 10:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJaf-0005AG-4l for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 10:41:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03438 for ; Thu, 13 Nov 2003 10:40:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJac-00076P-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:40:58 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AKJac-00075z-00 for ipv6@ietf.org; Thu, 13 Nov 2003 10:40:58 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 13 Nov 2003 07:40:32 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 13 Nov 2003 07:40:27 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Nov 2003 07:40:25 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 13 Nov 2003 07:40:12 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 13 Nov 2003 07:40:25 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 13 Nov 2003 07:40:13 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ISATAP in unmanaged networks? Date: Thu, 13 Nov 2003 07:40:26 -0800 Message-ID: Thread-Topic: ISATAP in unmanaged networks? Thread-Index: AcOp+VQhloBUyTXER4WKQSzjdjk7agAAOAyQ From: "Christian Huitema" To: "Fred Templin" , "Pekka Savola" Cc: , X-OriginalArrivalTime: 13 Nov 2003 15:40:13.0680 (UTC) FILETIME=[6DE0AF00:01C3A9FC] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Thu, 13 Nov 2003, Fred Templin wrote: > I have not studied this space, but it occurs to me that ISATAP > could be tried as a first alternative to check whether the two > hosts are separated by a NAT. If there is no intervening NAT, > it seems to me that ISATAP would provide the benefit of not > needing the UDP header and "bubble" packets, yielding > greater efficiency. Otherwise, if blocked by a NAT the > initiating host coud after a short timeout try again with > Teredo. Pekka already answered: we considered ISATAP, and found only one domain of applicability, the "corner case" that Pekka mentioned. If the ISP is not providing global addresses (e.g. provides net 10 addresses to subscribers), then the subscribers cannot use the 6to4 technology. The nodes could use Teredo, but the current specification requires that the Teredo server uses a global address, which means that the Teredo clients will have good connectivity with nodes outside the ISP, but poor connectivity with nodes on the inside. Subscribers of a net 10 ISP will be better served if this ISP provides an ISATAP service, including a router. This will enable direct connectivity between the nodes, and communication through the ISATAP router with the nodes outside the ISP. We will document that. However, the service only provides one IPv6 address per IPv4 address. When the unmanaged network is connected through a NAT to a net 10 network, the nodes behind the NAT cannot directly use an ISATAP service provided by an ISP.=20 -- Christian Huitema=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:52:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20929 for ; Tue, 30 Mar 2004 17:52:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjg-0006ZK-S5 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LC4p3P022680 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 07:04:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B51hC-0005tj-Tp for ipv6-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 07:04:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08109 for ; Sun, 21 Mar 2004 07:04:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B51h8-0004Z2-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 07:04:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B51gA-0004S5-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 07:03:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B51ff-0004La-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 07:03:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B51fR-0005OT-DF; Sun, 21 Mar 2004 07:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B51fD-0005OD-2m for ipv6@optimus.ietf.org; Sun, 21 Mar 2004 07:02:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08007 for ; Sun, 21 Mar 2004 07:02:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B51f8-0004Ku-00 for ipv6@ietf.org; Sun, 21 Mar 2004 07:02:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B51eK-0004EN-00 for ipv6@ietf.org; Sun, 21 Mar 2004 07:01:53 -0500 Received: from eastmail2.ntt-east.co.jp ([202.229.5.45] helo=evx2.enoc.east.ntt.co.jp) by ietf-mx with esmtp (Exim 4.12) id 1B51dT-00040T-00 for ipv6@ietf.org; Sun, 21 Mar 2004 07:00:59 -0500 Received: from emix2.enoc.east.ntt.co.jp by evx2.enoc.east.ntt.co.jp with ESMTP id i2LC0Qd24196; Sun, 21 Mar 2004 21:00:26 +0900 (JST) Received: from cip2.noc.east.ntt.co.jp by emix2.enoc.east.ntt.co.jp with ESMTP id i2LC0Pt10421; Sun, 21 Mar 2004 21:00:26 +0900 (JST) Received: from ipng.ipnw.rdc.east.ntt.co.jp ([10.35.198.93]) by cip2.noc.east.ntt.co.jp (MOS 3.4.4-GR) with ESMTP id ACW00322; Sun, 21 Mar 2004 21:00:25 +0900 (JST) Received: from wataruibm.ipingu.tokyo.east.ntt.co.jp (wataruibm.ipingu.tokyo.east.ntt.co.jp [10.41.99.2]) by ipng.ipnw.rdc.east.ntt.co.jp (Postfix) with ESMTP id E955C565F6 for ; Sun, 21 Mar 2004 21:00:24 +0900 (JST) Received: from rdc-534fc38e1e3.rdc.east.ntt.co.jp (localhost [127.0.0.1]) by wataruibm.ipingu.tokyo.east.ntt.co.jp (Postfix) with SMTP id 6434C8823; Sun, 21 Mar 2004 21:00:22 +0900 (JST) Message-Id: <200403211200.AA04170@rdc-534fc38e1e3.rdc.east.ntt.co.jp> From: Wataru Kawakami -ipv4- Date: Sun, 21 Mar 2004 21:00:20 +0900 To: Ralph Droms Cc: , w.kawakami@rdc.east.ntt.co.jp Subject: Re: simpler prefix delegation In-Reply-To: <4.3.2.7.2.20040321055909.0292fc28@flask.cisco.com> References: <4.3.2.7.2.20040321055909.0292fc28@flask.cisco.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > The network architect/engineer/admin (customer) community should be > considered here, as well. Are there any customers that have said "DHCPv6 PD > is too complex, we want something simpler"? I haven't heard from any. That's too much saying. If delegation of ``prefix'' to CPE is not needed (i.e. only address assignment to the 1st hop CPE device is only requir- ed), DHCPv6 PD is too much. # In case of this, use ``RA + DAD'' ? If you assume the case to delegate prefix, DHCPv6 PD may be the solution. wataru # Sorry to say, IPv4 is still attrative for me. # Also, IPv4 PPP is still attractive for me. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:52:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21060 for ; Tue, 30 Mar 2004 17:52:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjg-0006ZK-K8 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K9QuP9025097 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 04:26:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6vw-0006Wi-7Y for ipv6-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 04:26:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11803 for ; Fri, 20 Feb 2004 04:26:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au6vt-0005SQ-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 04:26:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au6uy-0005JR-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 04:25:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au6tv-00059s-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 04:24:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6ti-0005fH-0N; Fri, 20 Feb 2004 04:24:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6pT-0005Bp-3Q for ipv6@optimus.ietf.org; Fri, 20 Feb 2004 04:20:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11429 for ; Fri, 20 Feb 2004 04:20:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au6pQ-0004uZ-00 for ipv6@ietf.org; Fri, 20 Feb 2004 04:20:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au6oZ-0004p5-00 for ipv6@ietf.org; Fri, 20 Feb 2004 04:19:19 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1Au6nw-0004ho-00; Fri, 20 Feb 2004 04:18:40 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i1K9IfNE024777; Fri, 20 Feb 2004 02:18:41 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HTD009DSLV4SM@edgemail1.Central.Sun.COM>; Fri, 20 Feb 2004 02:18:41 -0700 (MST) Received: from [192.168.1.101] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HTD00M2DLV31P@mail.sun.net>; Fri, 20 Feb 2004 02:18:40 -0700 (MST) Date: Fri, 20 Feb 2004 01:22:30 -0800 From: Alain Durand Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" In-reply-to: <40340FCD.9070609@innovationslab.net> To: Brian Haberman , Bob Hinden Cc: The IESG , Margaret Wasserman , IPv6 Mailing List , Alain Durand , Thomas Narten Message-id: <4F02942E-6386-11D8-9E3D-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.612) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <40340FCD.9070609@innovationslab.net> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Dears ADs, I found it very unfortunate that the chair decided to request to advance this document without answering two major issues I raised during the last call: - Permanent allocation is equivalent of selling address space, which is very different from the notion of stewardship that are now in place for any IP address allocation today. There are a number of legal questions not answered around this point. More, this is imposing a business model to the entity that will be in charge of the allocations, and I believe that the IETF should refrain from imposing business model. - The document does not contain any wording recommending against the 'all zero' self allocation. It merely say that: "Locally assigned global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM].". However, it should be noted that [RANDOM] or RFC1750 does not contain any mandate, just provide ideas on how to do things. An 'all zero' self allocation would create the prefix FD00::/48 and will be very tempting to use by many. This working group just spend more than a year to deprecate the site local fec0::/10 prefixes, just to reinvent it here. As the request to advance this document came from the Ipv6 wg chairs, representing the wg, it is my opinion that the IPv6 Working Groug has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy. As the request to advance this document has already been sent to you, ADs, this is my appeal to you to reject it and send it back to the working group. - Alain. On Feb 18, 2004, at 5:22 PM, Brian Haberman wrote: > Margaret & Thomas, > On behalf of the IPv6 working group, the chairs request the > advancement of: > > Title : Unique Local IPv6 Unicast Addresses > Author(s) : R. Hinden, B. Haberman > Filename : draft-ietf-ipv6-unique-local-addr-03.txt > Pages : 16 > Date : 2004-2-13 > > as a Proposed Standard. The -02 version completed working group last > call on 02/02/2004. This version addresses issues raised during the > last call period. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:53:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21161 for ; Tue, 30 Mar 2004 17:53:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjf-0006WI-Ca for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A7AMln030220 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 02:10:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xrB-0007rL-Jw for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 02:10:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05748 for ; Wed, 10 Mar 2004 02:10:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0xr7-0000Yr-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 02:10:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0xqA-0000Os-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 02:09:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0xpG-0000Eu-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 02:08:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xox-0006qF-Qw; Wed, 10 Mar 2004 02:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0xoU-0006da-Mv for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 02:07:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02266 for ; Wed, 10 Mar 2004 02:07:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0xoR-00003d-00 for ipv6@ietf.org; Wed, 10 Mar 2004 02:07:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0xnW-0007gN-00 for ipv6@ietf.org; Wed, 10 Mar 2004 02:06:35 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B0xmx-0007Tm-00 for ipv6@ietf.org; Wed, 10 Mar 2004 02:05:59 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUC005C5MCIYR@mailout3.samsung.com> for ipv6@ietf.org; Wed, 10 Mar 2004 16:05:06 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUC00JYNMB2I9@mailout3.samsung.com> for ipv6@ietf.org; Wed, 10 Mar 2004 16:04:14 +0900 (KST) Received: from Alperyegin ([75.2.47.232]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUC008P7MB113@mmp1.samsung.com> for ipv6@ietf.org; Wed, 10 Mar 2004 16:04:14 +0900 (KST) Date: Tue, 09 Mar 2004 23:04:16 -0800 From: Alper Yegin Subject: RE: Multiple DRs on a link In-reply-to: <404E23A1.60700@ericsson.com> To: "'Mattias Pettersson'" , ipv6@ietf.org Message-id: <000101c4066d$e6bb1a00$e82f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT There is some relevant text in RFC 3484: 7. Interactions with Routing ... Implementations may also use the choice of router to influence the choice of source address. For example, suppose a host is on a link with two routers. One router is advertising a global prefix A and the other router is advertising global prefix B. Then when sending via the first router, the host may prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B. This provides guidance in the right direction, but I'm not sure if it is sufficient, or ever implemented. Alper > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of > Mattias Pettersson > Sent: Tuesday, March 09, 2004 12:06 PM > To: ipv6@ietf.org > Subject: Multiple DRs on a link > > Hi, > > [This issue spans some WGs but it originates from here I believe.] > > We've had a small discussion in NEMO about multiple default routers on a > link, and whether these DRs are allowed to advertise different prefix > sets or not. > > Think of this small network: > > > ISP A ISP B > \ / > Ra Rb > | | > -+-----+-----+- > | > H > > Further assume that Ra advertises prefix Pa and Rb advertises prefix Pb. > Host H will have two DRs, hear two prefixes and build addresses out of > the both. > > What I'm asking for is whether this scenario was ever considered > "broken" unless there is some form of coordination between Ra and Rb. I > seem to recall that there was a discussion on ipng/IPv6 on exactly this > long ago but on the other hand I can't find it. > > The reason for calling this scenario broken is that H must be careful > with what source address to use when sending to either default router > (and that is a requirement we can't put on a legacy IPv6 host). One can > assume that both ISPs perform ingress filtering. If H contructs a packet > with a source address Sa from Pa and: > > - sends it to Ra: > - the packet will be routed successfully > > - but if it was to send it to Rb instead: > - (1) ISP B would drop it due to ingress filtering, or > - (2) Rb would have to forward it to Ra, or > - (3) Rb would have to tunnel it to ISP A, or > - (4) Rb would have to send a redirect to H, or > - (5) Rb or ISP B would generate an ICMP error about bad source address > > Alternatives 2-5 are typically described in draft-huitema-multi6-hosts, > but they either: > - require some form of coordination between the routers and their > ISPs, or they > - require that the host H implement some additional mapping between > prefixes/source addresses and default routers. > > To H there is no difference between Ra and Rb. Both claim that they are > default routers. Now both should be able to forward any traffic from H. > But unless Ra and Rb are coordinated in some of the ways described above > or that host H implement _new_ requirements in > draft-huitema-multi6-hosts (which standard IPv6 hosts do not), then host > H will have to take a chance on what default router to use (last heard? > first heard?). If H happened to select Ra as default router, packets > with source Sa will go through, but no packets with source Sb. And > default router selection will not happen again until Ra becomes > unreachable. > > So the question is: am I correct to regard this scenario as broken and > say it should not be encouraged? I also think that nobody plans to build > fixed networks like this, just for these reasons. However, people may > want to build NEMO-type of networks just like this, as it is convenient > when mobile routers are rather independent, they come and go, and each > connects to one ISP and each only advertises a prefix from its ISP. > Awkwardly, then it is more important than ever that the mobile routers > are cooperating otherwise legacy IPv6 hosts won't be able to get plain > connectivity. > > /Mattias > > > > > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution is > prohibited. If you believe this message has been sent to you in error, > please notify the sender by replying to this transmission and delete the > message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any such > corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Tue Mar 30 17:56:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21768 for ; Tue, 30 Mar 2004 17:56:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjd-0006a4-7g for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H8bd6e027038 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 03:37:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WYI-00070k-2R for ipv6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 03:37:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25546 for ; Wed, 17 Mar 2004 03:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3WYC-0001xX-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:37:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3WXI-0001qp-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:36:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3WWO-0001jk-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:35:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WW3-0006e4-PZ; Wed, 17 Mar 2004 03:35:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WVL-0006b3-EL for ipv6@optimus.ietf.org; Wed, 17 Mar 2004 03:34:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25410 for ; Wed, 17 Mar 2004 03:34:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3WVJ-0001aw-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:34:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3WUS-0001Uu-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:33:28 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3WUA-0001O0-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:33:10 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2004 00:37:31 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2H8W1id019188; Wed, 17 Mar 2004 09:32:09 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Mar 2004 08:32:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple DRs on a link Date: Wed, 17 Mar 2004 08:32:29 -0000 Message-ID: Thread-Topic: Multiple DRs on a link Thread-Index: AcQHQpjQj53paCxyT6GHECneio7xwgABPUzQASx6Z3A= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" , "Jari Arkko" Cc: X-OriginalArrivalTime: 17 Mar 2004 08:32:31.0126 (UTC) FILETIME=[63707360:01C40BFA] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable MRs on different links? >=20 > =3D> There are many different reasons. I sent a verly long > email about this to nemo (monet back then). One simple > scenario is that you might be walking around with a PAN > that happens to have 2 MRs on a single link (e.g. a laptop > and a mobile phone). The two MRs could share the same ingress > link and have different egress links. For instance your laptop > might have a WLAN card and your mobile might have a cellular > interface. Once you walk into an airport lounge or starbucks > you'll suddenly have a multihomed PAN. By definition, each MR > must have a separate home prefix. So each will advertise > a different prefix on the ingress side. Hi Hesham: I fail to understand the "by definition" here. Nemo does not prevent 2 different MRs from registering the same MNP. It's like multiple parallel routes. What's not duplicated is the Home address... In fact, I proposed a test to check that both registrations actually end up in a same link, otherwise there's a problem equivalent to the DAD problem in MIP6. Not much success on that proposal, though Pascal -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:56:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21878 for ; Tue, 30 Mar 2004 17:56:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjd-0006a4-5T for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29KA4Ia022251 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 15:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nYC-0005mF-Fk for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 15:10:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19439 for ; Tue, 9 Mar 2004 15:10:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nY9-0002Me-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 15:10:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0nXG-0002BU-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 15:09:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0nWW-00020g-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 15:08:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nWH-0004Sx-GP; Tue, 09 Mar 2004 15:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nW5-0004LS-20 for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 15:07:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19162 for ; Tue, 9 Mar 2004 15:07:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nW2-0001xK-00 for ipv6@ietf.org; Tue, 09 Mar 2004 15:07:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0nV9-0001n5-00 for ipv6@ietf.org; Tue, 09 Mar 2004 15:06:56 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B0nUK-0001dA-00 for ipv6@ietf.org; Tue, 09 Mar 2004 15:06:04 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i29K63YG020594 for ; Tue, 9 Mar 2004 21:06:03 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 9 Mar 2004 21:06:03 +0100 Received: from ericsson.com (arael27m51.eu.ericsson.se [153.88.95.52]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FYFTZWTA; Tue, 9 Mar 2004 21:06:53 +0100 Message-ID: <404E23A1.60700@ericsson.com> Date: Tue, 09 Mar 2004 21:05:53 +0100 X-Sybari-Trust: 708f768c 2c4885b5 39802fef 00000138 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Multiple DRs on a link Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2004 20:06:03.0709 (UTC) FILETIME=[F32AB6D0:01C40611] Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, [This issue spans some WGs but it originates from here I believe.] We've had a small discussion in NEMO about multiple default routers on a link, and whether these DRs are allowed to advertise different prefix sets or not. Think of this small network: ISP A ISP B \ / Ra Rb | | -+-----+-----+- | H Further assume that Ra advertises prefix Pa and Rb advertises prefix Pb. Host H will have two DRs, hear two prefixes and build addresses out of the both. What I'm asking for is whether this scenario was ever considered "broken" unless there is some form of coordination between Ra and Rb. I seem to recall that there was a discussion on ipng/IPv6 on exactly this long ago but on the other hand I can't find it. The reason for calling this scenario broken is that H must be careful with what source address to use when sending to either default router (and that is a requirement we can't put on a legacy IPv6 host). One can assume that both ISPs perform ingress filtering. If H contructs a packet with a source address Sa from Pa and: - sends it to Ra: - the packet will be routed successfully - but if it was to send it to Rb instead: - (1) ISP B would drop it due to ingress filtering, or - (2) Rb would have to forward it to Ra, or - (3) Rb would have to tunnel it to ISP A, or - (4) Rb would have to send a redirect to H, or - (5) Rb or ISP B would generate an ICMP error about bad source address Alternatives 2-5 are typically described in draft-huitema-multi6-hosts, but they either: - require some form of coordination between the routers and their ISPs, or they - require that the host H implement some additional mapping between prefixes/source addresses and default routers. To H there is no difference between Ra and Rb. Both claim that they are default routers. Now both should be able to forward any traffic from H. But unless Ra and Rb are coordinated in some of the ways described above or that host H implement _new_ requirements in draft-huitema-multi6-hosts (which standard IPv6 hosts do not), then host H will have to take a chance on what default router to use (last heard? first heard?). If H happened to select Ra as default router, packets with source Sa will go through, but no packets with source Sb. And default router selection will not happen again until Ra becomes unreachable. So the question is: am I correct to regard this scenario as broken and say it should not be encouraged? I also think that nobody plans to build fixed networks like this, just for these reasons. However, people may want to build NEMO-type of networks just like this, as it is convenient when mobile routers are rather independent, they come and go, and each connects to one ISP and each only advertises a prefix from its ISP. Awkwardly, then it is more important than ever that the mobile routers are cooperating otherwise legacy IPv6 hosts won't be able to get plain connectivity. /Mattias This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:56:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21976 for ; Tue, 30 Mar 2004 17:56:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjc-0006ZK-Ng for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i218Uxu8001987 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 03:30:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxipH-0000Vy-4m for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 03:30:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01989 for ; Mon, 1 Mar 2004 03:30:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxipE-0005uf-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 03:30:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxioO-0005nG-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 03:30:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axinb-0005eJ-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 03:29:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxinO-0008W8-4k; Mon, 01 Mar 2004 03:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AximO-0008Iq-EJ for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 03:28:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01748 for ; Mon, 1 Mar 2004 03:27:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AximL-0005Sx-00 for ipv6@ietf.org; Mon, 01 Mar 2004 03:27:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxilV-0005Io-00 for ipv6@ietf.org; Mon, 01 Mar 2004 03:27:06 -0500 Received: from yue.hongo.wide.ad.jp ([203.178.135.30]) by ietf-mx with esmtp (Exim 4.12) id 1AxikW-00057x-00 for ipv6@ietf.org; Mon, 01 Mar 2004 03:26:04 -0500 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 01F1F33CA5; Mon, 1 Mar 2004 17:27:22 +0900 (JST) Date: Mon, 01 Mar 2004 17:27:22 +0900 (JST) Message-Id: <20040301.172722.52127223.yoshfuji@linux-ipv6.org> To: jinmei@isl.rdc.toshiba.co.jp Cc: Erik.Nordmark@sun.com, ipv6@ietf.org, yoshfuji@linux-ipv6.org Subject: Re: additional agenda item From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello. In article (at Mon, 01 Mar 2004 16:54:25 +0900), JINMEI Tatuya / $B?@L@C#:H(B says: > FYI: currently getifaddrs(3) provides the following information: > > char *ifa_name; /* Interface name */ > u_int ifa_flags; /* Interface flags */ > struct sockaddr *ifa_addr; /* Interface address */ > struct sockaddr *ifa_netmask; /* Interface netmask */ > struct sockaddr *ifa_broadaddr; /* Interface broadcast address */ > struct sockaddr *ifa_dstaddr; /* P2P interface destination */ > void *ifa_data; /* Address specific data */ 1. From the viewpoint of protocol independent programming, we need to have ifa_addrlen or something like that because non-4.4-BSDs (such as Windows, Solaris, Linux, etc...) does not seem to have sa_len field in sockaddr{}. 2. ifa_broadaddr and ifa_dstaddr will conflict on some platforms. Linux already has the following #define in . struct ifaddr { struct sockaddr ifa_addr; union { struct sockaddr ifu_broadaddr; struct sockaddr ifu_dstaddr; } ifa_ifu; struct iface *ifa_ifp; struct ifaddr *ifa_next; }; #define ifa_broadaddr ifa_ifu.ifu_broadaddr #define ifa_dstaddr ifa_ifu.ifu_dstaddr On Linux, ifaddrs{} is like this: struct ifaddrs { struct ifaddrs *ifa_next; char *ifa_name; unsigedint int ifa_flags; struct sockaddr *ifa_addr; struct sockaddr *ifa_netmask; union { struct sockaddr ifu_broadaddr; struct sockaddr ifu_dstaddr; } ifa_ifu; void *ifa_data; }; We need to be careful to describe the structure. 2. The description for "ifa_flags" is rather bogus. For L3 addresses, it seems to return IFA_xxx (or IN6_IFA_xxx?) flags, instead of IFF_xxx flags for L2. 3. flags are different from system to system; it is not so easy to describe (especially for IFA_xxx). I'm trying to write some proposals on this... -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:57:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22167 for ; Tue, 30 Mar 2004 17:57:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjc-0006ZK-HY for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i245ksoD027346 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 00:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aylh8-00076z-8A for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 00:46:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01477 for ; Thu, 4 Mar 2004 00:46:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aylh5-0003cE-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:46:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylfT-00037n-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:45:11 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayle0-0002kQ-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:43:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayle1-0006rn-Ny for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:43:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyldQ-0005d6-Rm; Thu, 04 Mar 2004 00:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyldH-0005ah-5s for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 00:42:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00965 for ; Thu, 4 Mar 2004 00:42:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyldE-0002W6-00 for ipv6@ietf.org; Thu, 04 Mar 2004 00:42:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aylbh-0002Er-00 for ipv6@ietf.org; Thu, 04 Mar 2004 00:41:18 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1Aylb6-000253-00 for ipv6@ietf.org; Thu, 04 Mar 2004 00:40:40 -0500 Received: from localhost ([130.194.13.81]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L7C2B29KSG8X3OBC@vaxh.its.monash.edu.au> for ipv6@ietf.org; Thu, 4 Mar 2004 15:53:06 +1100 Received: from kapow.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 944291B000E; Thu, 04 Mar 2004 15:53:05 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 82287124011; Thu, 04 Mar 2004 15:53:05 +1100 (EST) Date: Thu, 04 Mar 2004 04:53:05 +0000 (GMT) From: Gregory Daley Subject: RFC2461bis #256 RA Response Delay To: ipv6@ietf.org Cc: h.soliman@flarion.com Message-id: <728f7e72888c.72888c728f7e@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, I think that in general this is actually new function, and is likely to be covered in DNA. It may be worth talking about whether router solicitations sent to the unicast address of the router need to be delayed in the same fashion though. (since there is no chance of response implosion, if a unicast response. multicast could still have the MIN_DELAY_BETWEEN_RAS). At this time (based on discussion on DNA list) it may be useful to have an RS only transmitted to one of the routers. It is unclear how well this is supported by existing routers, or if it is intended that hosts can solicit only their favourite router. If it is already supported by routers, is it worth clarifying the capability in 2461bis. There is no mention of unicast RS in RFC2461, and no strict requirement listed for multicast. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:57:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22246 for ; Tue, 30 Mar 2004 17:57:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjc-0006ZK-Fb for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LLFvwq008445 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 16:15:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5AIX-0002C5-KP for ipv6-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 16:15:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01270 for ; Sun, 21 Mar 2004 16:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5AIU-0004co-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 16:15:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5AHc-0004Xl-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 16:15:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5AGt-0004Sx-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 16:14:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5AGg-0001ug-2Z; Sun, 21 Mar 2004 16:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5AGY-0001uR-Ee for ipv6@optimus.ietf.org; Sun, 21 Mar 2004 16:13:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01227 for ; Sun, 21 Mar 2004 16:13:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5AGW-0004S4-00 for ipv6@ietf.org; Sun, 21 Mar 2004 16:13:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5AFf-0004Nl-00 for ipv6@ietf.org; Sun, 21 Mar 2004 16:12:59 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B5AFR-0004Ij-00 for ipv6@ietf.org; Sun, 21 Mar 2004 16:12:46 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2004 13:18:29 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2LLBhiZ016382; Sun, 21 Mar 2004 22:11:43 +0100 (MET) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id VAA01489; Sun, 21 Mar 2004 21:11:35 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: "Christian Huitema" Cc: "Pekka Savola" , "Ralph Droms" , Subject: Re: simpler prefix delegation References: From: Ole Troan Date: Sun, 21 Mar 2004 21:11:35 +0000 In-Reply-To: (Christian Huitema's message of "Sun, 21 Mar 2004 12:11:50 -0800") Message-ID: <7t5oeqplxbs.fsf@mrwint.cisco.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >> the amount of work required to implement PD using a DHCP based >> protocol engine versus an ICMP based protocol engine is similar. the >> benefit of reusing DHCP (ignoring the fact that its already an RFC and >> has numerous implementation) is that the cost of implementing and >> deploying all the N++ features (DNS, address assignment, SIP, ...) is >> much lower. > > There are many practical issue with using DHCPV6 for prefix delegation. > > In many cases, the source of the prefix delegation is not the same as > the source of other configuration parameters. If you read the RFC, you > have the distinct feeling that one should discover the PD server > independently of the other DHCP services. There are good reasons for > these being independent: most of the other parameters are essentially > stateless, copied from some configuration database, while PD is > stateful, possibly made up on the fly by the router managing a subnet. > Trying to shove independent assignments into a single provisioning > system is bound to cause operational problems. > > Another practical issue arises when the prefix delegation server is more > than one hop away from the router requesting an assignment. The DHCP > discovery process relies on a structure of proxies, but there is no > guarantee that the proxies will end up sending the request to the > desired server. That also will cause operational problems. > >> it sounds to me like the motivation here is to avoid DHCP at all >> cost. I'm certainly not a big fan of DHCP, but I'm pragmatic enough to >> see that reinventing DHCP just to get a different acronym isn't worth >> it. > > If we were just speaking about packet encoding, I might agree with you. > However, we also have to consider operational issues. For example, the > RA based assignment of addresses is vastly more reliable than a DHCP > based system, because it only includes 2 parties: host and router; DHCP > requires in addition a proxy and a server, and often a network > configuration database. We have all witnessed the results: during the > typical snafu on the IETF network, IPv6 is up and running because of > automatic address configuration, while IPv4 is struggling with a > congested DHCP server. DHCP PD can very well only include two parties. the requesting router and the delegating router. no additional proxies or servers are required. by server I presume you mean a separate box from the first-hop router, and not the DHCP PD process running in the delegating router. as you well know the RA server in the first-hop router may as well go down as the PD process. the delegating router could get prefix information from a third party server like AAA or DHCP but that is not required for the operation of the protocol. if the ISP would want to authenticate the user using e.g radius and the prefix information can be included in the AAA messages so not additional servers are needed. > So, yes, there is a desire to solve reliability issues that are inherent > with the use of DHCP. since prefix delegation is stateful it might be less reliable than a stateless protocol. unless there is a proposal for how to do stateless prefix delegation, then substituting DHCP for ICMP isn't going to make the slightest difference for reliability. I know it is in good tradition of this working group to reopen and reiterate every discussion ever had every nine months or so. isn't it about time we close this working group if there isn't anything new to work on? or at least reopen some interesting discussions. I still think the address should be 64 bits long. :) /ot -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:58:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22347 for ; Tue, 30 Mar 2004 17:58:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006a4-Ug for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i245kl9N027328 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 00:46:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aylh1-00076h-GH for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 00:46:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01455 for ; Thu, 4 Mar 2004 00:46:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aylgy-0003aw-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:46:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylfN-00036S-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:45:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayldx-0002kJ-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:43:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayldy-0006rm-Ll for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 00:43:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyldT-0005fU-2y; Thu, 04 Mar 2004 00:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyldH-0005am-R1 for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 00:42:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00968 for ; Thu, 4 Mar 2004 00:42:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyldF-0002WB-00 for ipv6@ietf.org; Thu, 04 Mar 2004 00:42:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aylbi-0002Ez-00 for ipv6@ietf.org; Thu, 04 Mar 2004 00:41:19 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1Aylb6-000253-01 for ipv6@ietf.org; Thu, 04 Mar 2004 00:40:40 -0500 Received: from localhost ([130.194.13.85]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L7C1XVBQBM907ZSZ@vaxh.its.monash.edu.au> for ipv6@ietf.org; Thu, 4 Mar 2004 15:43:14 +1100 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 4EC76158002; Thu, 04 Mar 2004 15:43:14 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by broink.its.monash.edu.au (Postfix) with ESMTP id 3EB52120011; Thu, 04 Mar 2004 15:43:14 +1100 (EST) Date: Thu, 04 Mar 2004 04:43:14 +0000 (GMT) From: Gregory Daley Subject: RFC2461bis #255 RA interval To: ipv6@ietf.org Cc: h.soliman@flarion.com Message-id: <7250ed72581b.72581b7250ed@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Hesham, I think it was agreed that this function was new, and only defined in a Proposed Standard (MIPv6). Apart from this, It may be better just to let devices look at MIPv6 for guidance. (Even then it is a marginal solution). Perhaps this issue should be rejected. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:58:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22351 for ; Tue, 30 Mar 2004 17:58:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006a4-SX for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248idiT017776 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:44:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoT8-0004cd-DJ for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:44:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29898 for ; Thu, 4 Mar 2004 03:44:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoT6-0003NS-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:44:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoSF-00039Z-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:43:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyoRW-0002uG-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:42:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoQo-0003zP-Te; Thu, 04 Mar 2004 03:42:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoQ5-0003wK-En for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 03:41:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29465 for ; Thu, 4 Mar 2004 03:41:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoQ3-0002SR-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:41:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoNr-0001kD-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:39:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyoLO-0001A2-03 for ipv6@ietf.org; Thu, 04 Mar 2004 03:36:39 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayo7X-0000sZ-DI for ipv6@ietf.org; Thu, 04 Mar 2004 03:22:19 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i248Lck08102; Thu, 4 Mar 2004 00:21:38 -0800 X-mProtect: <200403040821> Nokia Silicon Valley Messaging Protection Received: from spruce.wireless.ietf59.or.kr (218.37.229.60, claiming to be "spruce.nokia.com") by darkstar.iprg.nokia.com smtpdsC2sWa; Thu, 04 Mar 2004 00:21:35 PST Message-Id: <4.3.2.7.2.20040304001227.02301930@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Mar 2004 00:21:18 -0800 To: Suresh Satapati From: Bob Hinden Subject: RE: v6 host load balancing Cc: ipv6@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Suresh, >coz data from the client may be going thru a different device Y, which is >being blocked by the fw on that device. fw Y doesn't have the hole >to let the traffic go through. This won't be caused by the load sharing when the data and control are going to the same destination host. If the data traffic is going to a different destination host, then it could end up on a different router because of a more specific route or a redirect. I don't see that load sharing adds to the complexity. Also, anytime there are multiple routers, the inbound traffic may come back to the different router than it went out on. The same lack of FW state problem will occur. This doesn't have anything to do with load sharing. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:58:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22383 for ; Tue, 30 Mar 2004 17:58:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006WI-RE for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H8Vvap024246 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 03:31:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WSx-0006Hs-MC for ipv6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 03:31:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25252 for ; Wed, 17 Mar 2004 03:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3WSb-0001Dz-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:31:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3WRW-00015z-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:30:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3WQz-0000zE-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 03:29:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WQE-0005kM-8J; Wed, 17 Mar 2004 03:29:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3WPW-0005ie-0l for ipv6@optimus.ietf.org; Wed, 17 Mar 2004 03:28:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25146 for ; Wed, 17 Mar 2004 03:28:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3WPT-0000rd-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:28:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3WOW-0000mE-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:27:20 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx with esmtp (Exim 4.12) id 1B3WOF-0000gi-00 for ipv6@ietf.org; Wed, 17 Mar 2004 03:27:03 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2004 00:31:24 +0000 Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2H8Q2iZ017364; Wed, 17 Mar 2004 09:26:02 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Mar 2004 08:26:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple DRs on a link Date: Wed, 17 Mar 2004 08:26:31 -0000 Message-ID: Thread-Topic: Multiple DRs on a link Thread-Index: AcQHNfD1BN+cUTkETi6jMRqxHMCCGAAAFcIQAS/zPQA= From: "Pascal Thubert \(pthubert\)" To: "Soliman Hesham" Cc: X-OriginalArrivalTime: 17 Mar 2004 08:26:31.0921 (UTC) FILETIME=[8D561E10:01C40BF9] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Hesham: In case that helps, we've found practical in some experimentations to allow a MR to autoconf addresses on its ingress interfaces, and install the associated connected routes. Note that if a MR listens to itself from a different interface, it will not install the prefix. Anyway, once the router has installed autoconf'ed address, the result is that source addresses are always topologically correct. But of course there comes a new set of problems: - potential attacks by rogue routers - redistribution: if such a connected route is redistributed over MIP explicit prefix, then an attack may be propagated. If not, then ingress filtering at the HA will discard the packet.=20 - multiple ingress interfaces Xconnected via wireless. Only one installs the connected route so the trick fails for other interfaces. Note that Nemo is a bit unclear about that ingress filtering at HA and I proposed some text recently that's not in draft 02.=20 Pascal > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Soliman Hesham > Sent: jeudi 11 mars 2004 08:08 > To: Jari Arkko; Tim Chown; Mattias Pettersson L (KI/EAB) > Cc: ipv6@ietf.org > Subject: RE: Multiple DRs on a link >=20 >=20 > > Right. In addition, the SEND WG had an issue about this as well, when > > they debated the semantics of prefixes in router certificates. (They > > decided to stick with the IPv6 RA semantics. That is, SEND hopes > > someone else, maybe multi6, will make it clearer what the rules are.) > > > > I have also seen the RFC 3484 rules, and I agree with others that > > they are somewhat vague. In any case, multi6 is already discussing > > this so eventually there will be a spec that will guide us. However, > > in any case when there are multiple routers with different prefixes > > on the same link, currently implemented IPv6 hosts may make the > > wrong decision. Certainly at least those nodes that predate RFC 3484. >=20 > =3D> I think even the nodes that implement 3484 may make the > wrong decision. The text that Alper sent is not "standards text" > and I suspect there are implementations (e.g. BSD) that don't > follow this. >=20 > > > > But I have a question about the NEMO case. I had assumed that mobile > > routers move around and attach their egress interface to various > > place in the internet. And that their ingress interface serves > > a number of hosts, unaware of the movements. I don't see the > > default router selection as an issue in this scenario, as the > > hosts will stick to the same mobile router all the time, and > > the mobile router acts like a host on its egress interface. So > > if the visited link works for hosts, it should work for mobile > > routers. >=20 > =3D> The problem is when you have 2 MRs, each advertising a different > prefix (i.e. different home prefix). >=20 > Hesham >=20 > > > > But perhaps you are considering a situation where the ingress > > interface of two mobile routers may be shared, or that a mobile > > router's ingress interface may suddenly appear on some stationary > > network. If we allow this, there could be problems. Do we really > > need it? > > > > --Jari > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:58:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22472 for ; Tue, 30 Mar 2004 17:58:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006WI-LM for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248gp7s015883 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:42:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoRO-00047w-TY for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:42:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29673 for ; Thu, 4 Mar 2004 03:42:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoRL-0002sn-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:42:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoQ7-0002Vp-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:41:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyoNw-0001lj-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:39:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoMn-0003Fk-V6; Thu, 04 Mar 2004 03:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoM0-0002vQ-JF for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 03:37:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29069 for ; Thu, 4 Mar 2004 03:37:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoLx-0001Jp-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:37:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoKx-00017u-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:36:12 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AyoJw-0000pS-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:35:08 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2004 00:47:10 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i248YbiQ008648; Thu, 4 Mar 2004 00:34:38 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQW56511; Thu, 4 Mar 2004 00:34:36 -0800 (PST) Date: Thu, 4 Mar 2004 00:34:36 -0800 (PST) From: Suresh Satapati To: Bob Hinden cc: ipv6@ietf.org Subject: RE: v6 host load balancing In-Reply-To: <4.3.2.7.2.20040304001227.02301930@mailhost.iprg.nokia.com> Message-ID: References: <4.3.2.7.2.20040304001227.02301930@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Thu, 4 Mar 2004, Bob Hinden wrote: > Suresh, > > >coz data from the client may be going thru a different device Y, which is > >being blocked by the fw on that device. fw Y doesn't have the hole > >to let the traffic go through. > > This won't be caused by the load sharing when the data and control are > going to the same destination host. If the data traffic is going to a > different destination host, then it could end up on a different router > because of a more specific route or a redirect. I don't see that load > sharing adds to the complexity. Agreed. I was just trying to clarify Changming's concern. > > Also, anytime there are multiple routers, the inbound traffic may come back > to the different router than it went out on. The same lack of FW state > problem will occur. This doesn't have anything to do with load sharing. > Quite possible. But my main concern was why do we insist on a MUST for the host when there is no convincing reason to do so. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:58:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22531 for ; Tue, 30 Mar 2004 17:58:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006WI-Nu for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IHBmlA025361 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 12:11:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B413b-0006aq-1T for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 12:11:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25650 for ; Thu, 18 Mar 2004 12:11:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B413U-0004jN-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 12:11:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B412j-0004g0-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 12:10:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4129-0004bS-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 12:10:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B410v-00067c-Vh; Thu, 18 Mar 2004 12:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B410Y-0005xT-9C for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 12:08:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25477 for ; Thu, 18 Mar 2004 12:08:34 -0500 (EST) From: matthew.ford@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B410W-0004TK-00 for ipv6@ietf.org; Thu, 18 Mar 2004 12:08:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B40zi-0004Q0-00 for ipv6@ietf.org; Thu, 18 Mar 2004 12:07:46 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151] helo=i2kc04-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1B40yy-0004LE-00 for ipv6@ietf.org; Thu, 18 Mar 2004 12:07:00 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Mar 2004 16:47:48 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Mar 2004 16:47:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: simpler prefix delegation Date: Thu, 18 Mar 2004 16:47:47 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A7006477E0B@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: simpler prefix delegation Thread-Index: AcQM/GEKD+U35obTShmAC4JMdybwBQAC0Tug To: , Cc: , , , X-OriginalArrivalTime: 18 Mar 2004 16:47:47.0940 (UTC) FILETIME=[BE742A40:01C40D08] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On 18 March 2004, Pekka Savola wrote: > On Thu, 18 Mar 2004, Ralph Droms wrote: > > Is there interest in expending any more of the IETF's resources=20 > > reopening a problem for which we have rough consensus on a=20 > solution,=20 > > published specifications and running code? >=20 > You say that carefully, but still giving an impression as if=20 > rough consensus had been gauged that only one solution would=20 > be specified -- otherwise there would not be "reopening" the=20 > problem. That has never been even raised (AFAIR); I'd=20 > certainly have objected. >=20 > The fact that there is a solution out there, which fits the=20 > needs of some users, does not mean that there can not (or=20 > should not) be a different kind of solution which would seem=20 > to be much more appropriate in some other scenarios or for=20 > some other users. As I've said before in reference to the recursive name server discovery discussion, I don't believe it benefits the network operations community to have multiple solutions to these kind of requirements. -- Mat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:59:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22571 for ; Tue, 30 Mar 2004 17:59:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006Xa-ML for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACK2dTW016186 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:02:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1CJ-00049G-HP for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:02:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04609 for ; Wed, 12 Nov 2003 15:02:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1CF-0004pZ-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:02:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1CF-0004pW-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:02:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Bh-0003oU-SF; Wed, 12 Nov 2003 15:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1BD-0003iT-6Y for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 15:01:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04454 for ; Wed, 12 Nov 2003 15:01:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1B9-0004ns-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:01:28 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AK1B9-0004mm-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:01:27 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 12:00:46 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Nov 2003 12:00:45 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 12:00:44 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 12:00:46 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 12 Nov 2003 12:00:42 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Date: Wed, 12 Nov 2003 12:00:45 -0800 Message-ID: Thread-Topic: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Thread-Index: AcOpV6ji5VbA3+nySqesm8hDZA0Atg== From: "Christian Huitema" To: X-OriginalArrivalTime: 12 Nov 2003 20:00:42.0651 (UTC) FILETIME=[A70EA6B0:01C3A957] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The section "5.4.5 When Duplicate Address Detection Fails" currently says: A tentative address that is determined to be a duplicate as described above, MUST NOT be assigned to an interface and the node SHOULD log a system management error. If the address is a link-local address formed from an interface identifier, the interface SHOULD be disabled. The part about disabling the interface enables a DOS attack: wait for a target to come on line and send a DAD packet, reply with a deliberate collision, and poof the target is disconnected from the network.=20 Proposed resolution: write "MAY be disabled" instead. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 17:59:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22628 for ; Tue, 30 Mar 2004 17:59:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006Xa-K6 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K9QvC9025113 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 04:26:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6vx-0006Wy-B6 for ipv6-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 04:26:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11806 for ; Fri, 20 Feb 2004 04:26:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au6vu-0005Sd-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 04:26:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au6uz-0005Jc-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 04:25:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au6tv-00059t-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 04:24:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6tI-0005Ut-JG; Fri, 20 Feb 2004 04:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au61c-00026t-O8 for ipv6@optimus.ietf.org; Fri, 20 Feb 2004 03:28:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09654 for ; Fri, 20 Feb 2004 03:28:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au61a-0001jr-00 for ipv6@ietf.org; Fri, 20 Feb 2004 03:28:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au60g-0001f8-00 for ipv6@ietf.org; Fri, 20 Feb 2004 03:27:46 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Au5zs-0001Xm-00 for ipv6@ietf.org; Fri, 20 Feb 2004 03:26:56 -0500 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2004 00:26:51 -0800 Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1K8MiFs023832; Fri, 20 Feb 2004 09:25:59 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Feb 2004 08:26:21 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Optimistic DAD _again!_ Date: Fri, 20 Feb 2004 08:26:20 -0000 Message-ID: Thread-Topic: Optimistic DAD _again!_ Thread-Index: AcP2xjNjO+7nK8vmRsuJ6ubmnZfiNQAwk53Q From: "Pascal Thubert (pthubert)" To: "Nick 'Sharkey' Moore" , X-OriginalArrivalTime: 20 Feb 2004 08:26:21.0076 (UTC) FILETIME=[3821CD40:01C3F78B] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Nick: If more voices can help, you have my full support as well :) Pascal > -----Original Message----- > From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of = Nick 'Sharkey' Moore > Sent: jeudi 19 f=E9vrier 2004 09:52 > To: ipv6@ietf.org > Subject: Optimistic DAD _again!_ >=20 > Hi IPv6ers, >=20 > You might recall some time ago I stirred up some interest > in my Optimistic DAD draft, which seeks to eliminate DAD delay > without significantly increasing the risk involved in address > collision. In the meantime it's picked up a couple of independant > implementations[1] and a couple of conference publications[2]. >=20 > It was debated fairly thoroughly in MobileIP WG, > (I presented the idea to the WG in San Francisco[3]) but > has since been judged to be outside the scope of that group, > as it is applies to any situation needing fast address > configuration, not just MobileIP. >=20 > IPv6 WG seems the proper place for it to be developed > further, and I'd like to open it up for debate here with the > aim of moving it towards standardization. >=20 > The latest version is: > > ... and it's _still_ only 13 pages long. >=20 > Please let me know what you think ... and if there's enough > interest maybe we can discuss it further at Seoul. >=20 > -----Nick 'sharkey' Moore. >=20 >=20 > [1] One by our team at Monash, one by Ed Remmel of Elmic Systems > [2] See for refs ... > [3] ... and for slides from these presentations. > -- > Nick Moore, Resarch Fellow | > Monash University CTIE | = > Australian Telecommunications CRC | = >=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 exim@www1.ietf.org Tue Mar 30 18:00:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22866 for ; Tue, 30 Mar 2004 18:00:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006a4-Bg for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AA4Yfj020016 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 05:04:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUkl-0005Cf-5S for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 05:04:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09621 for ; Tue, 10 Feb 2004 05:04:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqUkh-000381-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 05:04:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqUjZ-0002w9-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 05:03:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqUir-0002lj-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 05:02:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUiW-0004o6-IL; Tue, 10 Feb 2004 05:02:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUiA-0004mr-Dy for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 05:01:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09437 for ; Tue, 10 Feb 2004 05:01:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqUi7-0002iU-00 for ipv6@ietf.org; Tue, 10 Feb 2004 05:01:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqUhB-0002d4-00 for ipv6@ietf.org; Tue, 10 Feb 2004 05:00:46 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AqUgS-0002YC-00 for ipv6@ietf.org; Tue, 10 Feb 2004 05:00:00 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 798741521A; Tue, 10 Feb 2004 19:00:00 +0900 (JST) Date: Tue, 10 Feb 2004 19:00:04 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay In-Reply-To: <40276DEA.40305@innovationslab.net> References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@innovationslab.net> <40268EED.1080005@innovationslab.net> <4026D67A.2090007@eng.monash.edu.au> <40276DEA.40305@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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Mon, 09 Feb 2004 06:24:26 -0500, >>>>> Brian Haberman said: >> I think what Jari asked was not a modification to the semantics >> of reporting group joins. >> >> I think that what Jari proposed was actually that we delay DAD >> (which entails both the operation of beginning listening to >> a group and the NS transmission). > So, in logic-wise it would look like: > 1. Generate the solicited-node multicast address > 2. Wait for random timer expiry > 3. Perform ADD_MEMBERSHIP call on the socket > 4. Send DAD > I think I can live with that for the time being. In my latest proposal, the behavior is a bit different: 1. Generate the solicited-node multicast address 2. Perform ADD_MEMBERSHIP call on the socket (or equivalent) but not send MLD, i.e., start listening to the multicast address 3. Wait for random timer expiry 4. send MLD 5. Send DAD The reason for doing 2 before the random delay is because we need to listen to the multicast address to improve the reliability of DAD. The reason for doing 3 (random delay) before sending MLD is for avoiding collisions. Would you still live with this? 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 exim@www1.ietf.org Tue Mar 30 18:00:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22959 for ; Tue, 30 Mar 2004 18:00:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006a4-S2 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4JLQwh023791 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 14:21:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6k0-00069K-1Y for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 14:21:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29184 for ; Tue, 4 Nov 2003 14:21:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6jp-0003Iz-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 14:21:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH6jo-0003Iw-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 14:21:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6ji-0005yS-1t; Tue, 04 Nov 2003 14:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6in-0005kR-0t for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 14:20:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29135 for ; Tue, 4 Nov 2003 14:19:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6ik-0003HO-00 for ipv6@ietf.org; Tue, 04 Nov 2003 14:20:06 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AH6ik-0003HL-00 for ipv6@ietf.org; Tue, 04 Nov 2003 14:20:06 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 501DD14318; Tue, 4 Nov 2003 14:20:06 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11632-04; Tue, 4 Nov 2003 14:20:05 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 2188A1430C; Tue, 4 Nov 2003 14:20:05 -0500 (EST) Date: Tue, 4 Nov 2003 14:16:39 -0500 From: Keith Moore To: "Eugene M. Kim" Cc: moore@cs.utk.edu, mohacsi@niif.hu, colm@stdlib.net, Stig.Venaas@uninett.no, pekkas@netcore.fi, ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) Message-Id: <20031104141639.1c9d1d56.moore@cs.utk.edu> In-Reply-To: <3FA7F703.3060904@nttmcl.com> References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > So there seem to be at least two alternatives: > > * Change/fix the definition of getaddrinfo()/getnameinfo() so they > are tied to DNS only but nothing else. > * Keep the current semantics of those functions, then update and > standarize an API that strictly queries DNS only (res_XXX() and > dn_XXX() comes to mind first; if they fall short of what real > applications need, we could always define a new superset). There's a third option - like I suggested earlier, add a flag to getaddrinfo that says "only use DNS for this query". The res_XXX and dn_XXX functions (or improvements to these) are needed anyway because we use DNS for other things besides address lookup. > Perhaps it'd be desirable to see some actual figures; how much > percentage of the applications out there that use > gethostbyXXX()/getaddrinfo()/getnameinfo() would assume those > functions look up DNS records *only*, and would be severely broken if > they were given results not based on DNS. Well, it has a lot to do with the environment, doesn't it? I mean, if and when an alternate name-to-address translation service produces answers identical to DNS, then the app probably doesn't care what service provided the answers. The problems occur when the translation service doesn't provide the correct answers, or when the translation service in use at point A provides different answers than the service in use at point B. The more different lookup mechanisms in use, the easier it is for them to get out of sync with one another. Similarly, no app will be broken by a decision to use DNS when its host or network is properly configured. The only time breakage occurs is when the host or network is improperly configured to use some other lookup service besides DNS, or when the host is not configured at all. (yes, we do need to deal with self-configuring or ad hoc networks, but we need to do so in a way that produces results that don't conflict with DNS) An increasing number of apps are defined in such a way that DNS is *part of the protocol specification*; the app will violate the protocol specification if it uses a service other than DNS. For instance, any app that uses SRV or MX records falls into this catgory. There's little justification for an administrator to use an alternate address lookup service, since they typically have to support at least one app that requires DNS anyway. And there's certainly no reason for IETF to be endorsing the idea that a site should be able to use any lookup service it likes without breaking things. > However, my impression was that a vast majority of applications out > there use the functions in their original semantics (i.e. as a > shorthand facility for specifying human-readable text form of > addresses, not as a frontend interface for DNS only but nothing else), > e.g. `ping6 www.kame.net' certainly wouldn't care if the IPv6 address > getaddrinfo() returns comes from DNS, NIS, or any other mechanism. It's been a long time since HOSTS.TXT was sufficient. It's also been a long time since DNS was only a distributed replacement for HOSTS.TXT. The Internet is not defined by the "vast majority of applications". The Internet is defined by specifications. The problem is that our specifications are sometimes incomplete. In this case the APIs that we're recommending be used for implementation of apps aren't specified with enough precision to allow those apps to interoperate reliably. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:01:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23057 for ; Tue, 30 Mar 2004 18:01:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006WI-SW for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248AU0b001547 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:10:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynw5-0000OV-KO for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:10:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27128 for ; Thu, 4 Mar 2004 03:10:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynvu-0003SH-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:10:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynuy-0003Fl-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:09:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aynu1-00033m-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 03:08:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynrH-0007fa-G8; Thu, 04 Mar 2004 03:05:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynqV-0007Qa-KQ for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 03:04:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26513 for ; Thu, 4 Mar 2004 03:04:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynqH-00024H-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:04:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynpF-0001na-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:03:26 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AynoF-0001Ig-00 for ipv6@ietf.org; Thu, 04 Mar 2004 03:02:23 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Mar 2004 00:13:43 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2481qF8010247; Thu, 4 Mar 2004 00:01:52 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQW55358; Thu, 4 Mar 2004 00:01:51 -0800 (PST) Date: Thu, 4 Mar 2004 00:01:51 -0800 (PST) From: Suresh Satapati To: Bob Hinden cc: Pekka Savola , Changming Liu , ipv6@ietf.org Subject: RE: v6 host load balancing In-Reply-To: <4.3.2.7.2.20040303174845.00b1e6d0@mailhost.iprg.nokia.com> Message-ID: References: <1B6D4CAFB8CA554EB1A0925685A07DFC0342C69B@MONTEREY.netscreen.com> <4.3.2.7.2.20040303174845.00b1e6d0@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > I have a different set of experience where customers provision two or more > parallel router+firewalls and wish to divide the traffic between them. The > specifically do not want the other routers to be unused. They have > installed multiple routers so if one fails they want the others (using > VRRP) to take over for the failure. They have found that unless all of the > routers are used for live traffic that there is too high a probability that > the other routers won't function correctly. > > >Due to that, I, as an operator, would not wish to enable load-sharing on > >hosts except when I specifically require that kind of functionality. > Agree with Pekka. > I believe that the "Default Router Preferences and More-Specific Routes" > mechanisms provides the means to give the default routers different > preferences. This will have the effect of keeping the load sharing from > coming into play because the routers won't be seen as equivalent. This > will give you the control I think you are asking for with out having some > mechanism to change the default behavior in the hosts. > > >So, I'd propose that this document does not describe that the hosts MUST > >share the load, but rather describes how the hosts MUST behave if they wish > >to share the load -- and if turned on by default, require that there > >MUST be a way to toggle load balancing off. A difficult issue to settle > >might be whether to recommend (and if so, how strongly) to enable > >load-sharing by default. > > I disagree about what should be the default. I think the default should be > MUST, as I think it is useful in the general case. As pointed out above Disagree. load-sharing or router preferences were/are never a general case IMO and hence i disagree with MUST. > the "Default Router Preferences and More-Specific Routes" mechanisms > provides a simple mechanisms to cause the hosts to not see the routers as > equivalent if one so desires. > > Regards, > Bob > > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Tue Mar 30 18:01:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23206 for ; Tue, 30 Mar 2004 18:01:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006WI-J9 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C7MMmL022147 for ipv6-archive@odin.ietf.org; Fri, 12 Mar 2004 02:22:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1gzs-0005kt-10 for ipv6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 02:22:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05311 for ; Fri, 12 Mar 2004 02:22:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1gzo-0001va-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 02:22:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1gyo-0001of-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 02:21:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1gye-0001iE-00 for ipv6-web-archive@ietf.org; Fri, 12 Mar 2004 02:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1gxg-000568-59; Fri, 12 Mar 2004 02:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1gwt-0004qu-0e for ipv6@optimus.ietf.org; Fri, 12 Mar 2004 02:19:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05079 for ; Fri, 12 Mar 2004 02:19:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1gwp-0001b5-00 for ipv6@ietf.org; Fri, 12 Mar 2004 02:19:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1gvu-0001UP-00 for ipv6@ietf.org; Fri, 12 Mar 2004 02:18:15 -0500 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx with esmtp (Exim 4.12) id 1B1guv-0001NH-00 for ipv6@ietf.org; Fri, 12 Mar 2004 02:17:13 -0500 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id i2C7HCN8018450 for ; Fri, 12 Mar 2004 09:17:12 +0200 (EET) Received: from kallio.eur.soneragroup.net (kallio.eur.soneragroup.net [131.177.121.200]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id i2C7HAsY018419 for ; Fri, 12 Mar 2004 09:17:11 +0200 (EET) Received: from teliasonera.com ([194.142.21.49]) by kallio.eur.soneragroup.net with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Mar 2004 09:16:02 +0200 Message-ID: <4051637A.1020706@teliasonera.com> Date: Fri, 12 Mar 2004 09:15:06 +0200 From: Jyrki Soini Organization: TeliaSonera Finland User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: ICMPv6 echo reply to multicast packet thread Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2004 07:16:02.0961 (UTC) FILETIME=[E09D4810:01C40801] Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jyrki Soini wrote: > An Echo Reply MUST be sent in response to an Echo Request message > sent to an IPv6 multicast address. By default hop-limit IPv6 header > field MUST be set to value 1 [on non-router hosts?]. The hop-limit > SHOULD be administratively configurable. Hop-limit limitation is used to > prevent Echo Reply message storms on large multicast groups. ... > If [on non-router hosts?] is added to the wording, routers would > send echo reply messages to multicast echo request packets. > Still the resulted echo reply storm will be decreased from the current > situation. Clearly, I was not thinking far enough. Of course usually routers won't belong to the multicast group even though their forward traffic to it. Thus [on non-router hosts?] will usually have no affect at all. --- Jyrki Soini -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:02:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23611 for ; Tue, 30 Mar 2004 18:02:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006YH-AJ for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i139BE31010427 for ipv6-archive@odin.ietf.org; Tue, 3 Feb 2004 04:11:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnwaQ-0002i6-Lu for ipv6-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 04:11:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29066 for ; Tue, 3 Feb 2004 04:11:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnwaO-00053F-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 04:11:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnwZT-0004yP-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 04:10:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnwYm-0004tY-00 for ipv6-web-archive@ietf.org; Tue, 03 Feb 2004 04:09:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnwYK-0002H5-EM; Tue, 03 Feb 2004 04:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnwXV-00027N-J9 for ipv6@optimus.ietf.org; Tue, 03 Feb 2004 04:08:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28951 for ; Tue, 3 Feb 2004 04:08:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnwXS-0004mO-00 for ipv6@ietf.org; Tue, 03 Feb 2004 04:08:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnwWX-0004g2-00 for ipv6@ietf.org; Tue, 03 Feb 2004 04:07:13 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1AnwVZ-0004Ve-00 for ipv6@ietf.org; Tue, 03 Feb 2004 04:06:13 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 3A27E839BC; Tue, 3 Feb 2004 10:05:40 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.18]) by merkur.iu-bremen.de (Postfix) with ESMTP id 89A6182C8B; Tue, 3 Feb 2004 10:05:39 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 68A765EE6E; Tue, 3 Feb 2004 10:05:39 +0100 (CET) Date: Tue, 3 Feb 2004 10:05:38 +0100 From: Juergen Schoenwaelder To: "JINMEI Tatuya / ?$B?@L@C#:H" Cc: ipv6@ietf.org Subject: Re: scope zone ID zero as the default (for revision of ipv6-scoping-arch) Message-ID: <20040203090538.GB905@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "JINMEI Tatuya / ?$B?@L@C#:H" , ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, Feb 02, 2004 at 11:00:25PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > (I hope you still remember this) during the wg last call for > draft-ietf-ipv6-scoping-arch-00.txt, you proposed to use the zone ID > value zero as the default with a higher requirement level: [...] > And, if I remember the discussion correctly, the consensus was we > should mandate zero as the default. So, I'd like to propose the > following changes: I am happy with these changes. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:02:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23680 for ; Tue, 30 Mar 2004 18:02:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006YH-65 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Bcrl9021031 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 06:38:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4Jw-0005Qs-Kx for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 06:38:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21460 for ; Fri, 6 Feb 2004 06:38:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Jm-0005Yf-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:38:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap4Iu-0005Vb-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:37:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Ia-0005S0-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:37:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4IE-0004M4-Aj; Fri, 06 Feb 2004 06:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap1mr-0001sj-Ur for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 03:56:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17207 for ; Fri, 6 Feb 2004 03:56:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap1mp-0005TK-00 for ipv6@ietf.org; Fri, 06 Feb 2004 03:56:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap1lt-0005RT-00 for ipv6@ietf.org; Fri, 06 Feb 2004 03:55:33 -0500 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by ietf-mx with esmtp (Exim 4.12) id 1Ap1lk-0005PZ-00; Fri, 06 Feb 2004 03:55:25 -0500 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i168t12Y018338 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 6 Feb 2004 09:55:01 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i168t1Cw015040; Fri, 6 Feb 2004 09:55:01 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) id i168t1iV015037; Fri, 6 Feb 2004 09:55:01 +0100 Date: Fri, 6 Feb 2004 09:55:01 +0100 Message-Id: <200402060855.i168t1iV015037@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: raraghun@cisco.com CC: ipv6mib@ibr.cs.tu-bs.de, ipv6@ietf.org, tsvwg@ietf.org In-reply-to: <402302BA.4020000@cisco.com> (message from Rajiv Raghunarayan on Thu, 05 Feb 2004 18:58:02 -0800) Subject: Re: [ipv6mib] Discontinuity timer for TCP-MIB counters References: <402302BA.4020000@cisco.com> X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >>>>> Rajiv Raghunarayan writes: Rajiv> The IESG review suggested that we provide a discontinuity timer Rajiv> for the counters in the mib - could be via sysUpTime or a new Rajiv> discontinuity object. But we state it either way. Here are my 3 thoughs on this: 1) So far, sysUpTime has been used by the existing TCP-MIB objects. Introducing a new discontinuity indicator now raises the question whether doing so breaks existing implementations. 2) Personally, I doubt that there will be many implementations where TCP can experience discontinuities that do not also affect other parts of the networking stack or the whole system. 3) I do see the problem that sysUpTime might be more frequently reset as we like due to some other MIBs which do not use explicit discontinuity indicators and experience more frequent resets. However, the root of the problem is then really in those MIBs, not in the TCP-MIB. (Sure, by introducing a discontinuity indicator for the TCP-MIB we can protect against other misbehaving MIBs - but is this going to set a precedence which at the end requires a CLR that better every MIB module has at least one, perhaps multiple discontinuity indicators?) In the case of the TCP-MIB, I believe 1) is the killing argument. To introduce a new discontinuity indicator changes the implicit semantics of existing objects and would require to introduce new objects, which I think is prohibitive. Conclusion: Spell out that sysUpTime is used as a discontinuity indicator for the counters. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:03:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23925 for ; Tue, 30 Mar 2004 18:03:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjZ-0006YH-Pc for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i264YXfs018123 for ipv6-archive@odin.ietf.org; Fri, 5 Mar 2004 23:34:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzTWC-0004iE-6f for ipv6-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 23:34:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17135 for ; Fri, 5 Mar 2004 23:34:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzTW9-0003vP-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 23:34:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzTVA-0003lk-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 23:33:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzTTs-0003YS-00 for ipv6-web-archive@ietf.org; Fri, 05 Mar 2004 23:32:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzTSs-0004KV-NI; Fri, 05 Mar 2004 23:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzTS1-0004EG-9o for ipv6@optimus.ietf.org; Fri, 05 Mar 2004 23:30:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16922 for ; Fri, 5 Mar 2004 23:30:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzTRy-0003Eb-00 for ipv6@ietf.org; Fri, 05 Mar 2004 23:30:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzTQw-0002vv-00 for ipv6@ietf.org; Fri, 05 Mar 2004 23:29:08 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1AzTPr-0002eV-00 for ipv6@ietf.org; Fri, 05 Mar 2004 23:27:59 -0500 Received: from ssprunk (ip133.post-vineyard.dfw.ygnition.net [66.135.181.133]) by ns2.sea (8.12.11/8.12.5) with SMTP id i264RPFn024596; Fri, 5 Mar 2004 20:27:25 -0800 Message-ID: <030b01c40333$543a9f80$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" Cc: "Brian E Carpenter" , References: <40461D35.5D17EE08@zurich.ibm.com> <20040305142938.09785621.moore@cs.utk.edu> <01d701c402ec$8f8964a0$6401a8c0@ssprunk> <8BC9370A-6EEF-11D8-87F6-000393DB5366@cs.utk.edu> <02cc01c40314$ed0280d0$6401a8c0@ssprunk> <13F3D4A0-6F10-11D8-87F6-000393DB5366@cs.utk.edu> Subject: Re: Adopt Address Selection API as a WG document? Date: Fri, 5 Mar 2004 21:57:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Keith Moore" > that's not a stable API, that's an API that behaves differently in > different environments - and the differences are sufficient to break > applications. it's simply not acceptable to give applications > temporary addresses when they need stable addresses. if an app says it > needs a stable address, then the API MUST either comply or return an > error. I'm not proposing that the API return something that conflicts with the app's requirements. I'm saying if there are multiple valid possibilities, which one the API returns may vary according to site-specific policies. I'm also saying that what requirements an app is allowed to specify needs a lot of study so that programmers don't accidentally disallow valid return values. > > There is no way for software alone to determine many of the variables > > involved in address selection, especially things like security policies. > > which is why having security policies that expect hosts or apps being > able to select addresses is a complete crock, and we should not be > endorsing such brain-damage. I meant the application can't statically determine what a site's policy will be; that doesn't mean the API can't determine it via some sort of configuration. > >>> I'm not convinced that such an API is immediately useful, however, > >>> since it seems to assume a prior means of determining which addresses > >>> will work at all. Most applications will be faced with a scenario > >>> where the source has N addresses, the destination has M addresses, > >>> and it won't be clear which of the N*M combinations will work > >>> without testing them all. > >> > >> you're absolutely right about this part. about the only thing the API > >> can reasonably do is let the application specify whether it can use a > >> temporary "privacy" address (as in a web browser) or whether it needs > >> a public address (as in a server or p2p app). > > > > That argument is loaded with flawed assumptions. There are many > > servers and p2p usage scenarios that would be served just fine by > > local addresses. > > in other words, the app _might_ just happen to work if the cards fall > right. that's not a model that app writers can work with. people > expect apps to work no matter where they're plugged in, and expecting > customers to guess whether the problem is in the app or in the network > configuration is not an acceptable means of operation. Instead, you propose that apps fail because they make questionable assumptions about what is acceptable. I, as a user, want my apps to at least _attempt_ to work instead of giving up because the address set on my machine (or the policy I created) doesn't live up to the app's expectations. "Needs a global address" is an inherently flawed expectation; "needs an address which can reach a given address" is not. > > For instance, some admins may prefer intra-company communication use > > local addresses even if global addresses are available, while other admins > > may prefer the opposite. You won't get far ignoring the "whims" of the > > person who owns all of the hosts in question. > ... > our task is to define how the network operates in such a way that > > a) network admins can define reasonable policies, AND > b) apps can function as long as policies permit, AND > c) if the app breaks because of a conflict with policy, it's obvious > that this is why the app breaks > > our task is NOT to let the network admin do whatever the hell he wants > and expect the app to be able to function in the presence of arbitrary > brain damage I never suggested that; I gave a simple case of two mutually exclusive local policies which are both perfectly reasonable, but would cause apps to needlessly fail if they make unfounded static assumptions. > > The application writer can't possibly anticipate all ways his code > > will end up being used, which is why I believe that a per-host policy > > (hidden behind an API) is the best way to go. > > no, that's why giving applications a reasonably consistent view of the > network independent of location is the only way to go. There is no consistent view of the network independent of location. Not all addresses can reach all other addresses, and that is something we all need to live with. In particular, it is not guaranteed that "global" addresses' reachability is superior to that of "local" addresses; that depends on where you're located. > there is absolutely no point to deploying IPv6 if it's going to be as > brain-damaged as IPv4+NAT from day one. it will only get worse from > there. NAT is hopefully out, but firewalls are here to stay. That's no reason to give up on IPv6. > >> it is, and always has been, completely unreasonable to expect either > >> hosts or apps to have to choose between a number of > >> (source,destination) address pairs in order to successfully connect > >> with other hosts. no API can solve that problem. > > > > Not true; it would be fairly trivial to implement an API function that > > tests all N*M pairs and return the set of pairs which appear to work. > > it would be trivial to implement, and unacceptably slow and unreliable. > and yes, I've written the code and tried it out. For reasonable values of N and M it can be done in a fraction of a second. That's fast enough for me. 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 exim@www1.ietf.org Tue Mar 30 18:04:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23965 for ; Tue, 30 Mar 2004 18:04:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjZ-0006YH-KU for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ADdWbP022710 for ipv6-archive@odin.ietf.org; Wed, 10 Mar 2004 08:39:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13vo-0005u6-Fw for ipv6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 08:39:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07819 for ; Wed, 10 Mar 2004 08:39:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B13vn-0006fq-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 08:39:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B13uo-0006Vj-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 08:38:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B13tp-0006IN-00 for ipv6-web-archive@ietf.org; Wed, 10 Mar 2004 08:37:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13tO-0002ei-Hk; Wed, 10 Mar 2004 08:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B13t3-0002cp-Bw for ipv6@optimus.ietf.org; Wed, 10 Mar 2004 08:36:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07725 for ; Wed, 10 Mar 2004 08:36:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B13t2-0006A4-00 for ipv6@ietf.org; Wed, 10 Mar 2004 08:36:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B13sB-0005y6-00 for ipv6@ietf.org; Wed, 10 Mar 2004 08:35:47 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1B13rC-0005mu-00 for ipv6@ietf.org; Wed, 10 Mar 2004 08:34:47 -0500 Received: from pigeon.ecs.soton.ac.uk (pigeon [152.78.68.1]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i2ADYjOr004955 for ; Wed, 10 Mar 2004 13:34:45 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA26346 for ; Wed, 10 Mar 2004 13:34:41 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i2ADYfe06711 for ipv6@ietf.org; Wed, 10 Mar 2004 13:34:41 GMT Date: Wed, 10 Mar 2004 13:34:41 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Multiple DRs on a link Message-ID: <20040310133441.GA793@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <404E23A1.60700@ericsson.com> <20040310094331.Q10925@mignon.ki.iif.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040310094331.Q10925@mignon.ki.iif.hu> 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Mar 10, 2004 at 09:47:20AM +0100, Mohacsi Janos wrote: > > I think this is not broken at all. The host should select the correct > prefix according to the source address selection rules. I tried this > scenario approximately 3 years ago on a KAME stack and it was working > correctly. While mobile routers on a (wireless) link are one example of this scenario, a multihomed link or a renumbering link are others, whether there is one router or two the host still needs to make the RFC3484 decisions. For the multihoming side, look at http://www.ietf.org/internet-drafts/draft-huitema-multi6-hosts-03.txt where issues like in/egress filtering are discussed. There has also been a long thread on source address selection on the multi6 WG list recently, which you could read back through. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:04:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24005 for ; Tue, 30 Mar 2004 18:04:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjZ-0006YH-NH for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i215uVbi003289 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 00:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgPm-0000qy-SH for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:56:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07544 for ; Mon, 1 Mar 2004 00:56:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgPk-0005aW-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:56:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgOw-0005Vl-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:55:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxgOa-0005Q5-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:55:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgNO-00005U-Av; Mon, 01 Mar 2004 00:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgMo-0008OZ-Rq for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 00:53:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07317 for ; Mon, 1 Mar 2004 00:53:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgMm-0005Gj-00 for ipv6@ietf.org; Mon, 01 Mar 2004 00:53:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgLq-0005Ap-00 for ipv6@ietf.org; Mon, 01 Mar 2004 00:52:26 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AxgKt-00050s-00 for ipv6@ietf.org; Mon, 01 Mar 2004 00:51:28 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 76D9E7024D8; Mon, 1 Mar 2004 16:51:13 +1100 (EST) Date: Mon, 1 Mar 2004 16:51:13 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: James Kempf Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Message-ID: <20040301055112.GA20621@zoic.org> Mail-Followup-To: ipv6@ietf.org, James Kempf References: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-29, James Kempf wrote: > > No, the SEND node performs DAD for fe80::C, where C is a function of the key > and some other parameters. The [suffix] on LL addresses is also calculated > from the key. Hiya James, correct me if I'm wrong but the suffixes are both calculated from the same key, but since the "other parameters" are different, the suffixes will be different. > Yes, that's the concern. If the DIID node comes on the link second, then it > will assume that A is a unique prefix even though it only DADs it for the LL > address. Yep, that's what I'm talking about too. My assumption is that SEND WG will adapt to the changes that RFC2462bis will make. So if we tweak 2462 to require configuration of a link-local address per suffix, SEND-CGA nodes will do this. This will then prevent (well, detect) collision as discussed above. Why not just specify this in SEND then? Well, because it's a DAD issue which applies to other protocols which would like to configure one or more arbitrary suffixes, eg: privacy addressing. -----Nick (who couldn't fit in the door at mip6!) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:04:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24034 for ; Tue, 30 Mar 2004 18:04:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjZ-0006Xa-B3 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16BcrZi021032 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 06:38:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4Jw-0005Qq-Lb for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 06:38:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21457 for ; Fri, 6 Feb 2004 06:38:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Jl-0005Ya-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:38:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap4It-0005VT-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:37:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Ia-0005Rz-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:37:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4IB-0004LT-QH; Fri, 06 Feb 2004 06:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AowEA-0004ti-N7 for ipv6@optimus.ietf.org; Thu, 05 Feb 2004 22:00:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25436 for ; Thu, 5 Feb 2004 22:00:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AowE7-0005jp-00 for ipv6@ietf.org; Thu, 05 Feb 2004 22:00:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AowDB-0005iF-00 for ipv6@ietf.org; Thu, 05 Feb 2004 21:59:22 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AowCQ-0005ev-00; Thu, 05 Feb 2004 21:58:34 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 Feb 2004 19:05:14 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i162w3hk026648; Thu, 5 Feb 2004 18:58:03 -0800 (PST) Received: from cisco.com (dhcp-128-107-165-142.cisco.com [128.107.165.142]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQA60444; Thu, 5 Feb 2004 18:58:02 -0800 (PST) Message-ID: <402302BA.4020000@cisco.com> Date: Thu, 05 Feb 2004 18:58:02 -0800 From: Rajiv Raghunarayan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPv6MIB , IPv6 , TSVWG Subject: Discontinuity timer for TCP-MIB counters Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Folks, This point came out of the IESG review of the TCP-MIB, and possibly requires wider discussion. Hence this mail to all the aliases. The current update to TCP-MIB (draft-ietf-ipv6-rfc2012-update-05.txt) does not define any special discontinuity objects, for a case when the counters in the mib experience a discontinuity. There is an implicit assumption that this would be represented by sysUpTime (SNMPv2-MIB). The IESG review suggested that we provide a discontinuity timer for the counters in the mib - could be via sysUpTime or a new discontinuity object. But we state it either way. There are issues to going either way: 1. sysUpTime: If any Counter, that uses sysUpTime as the discontinuity indicator, experiences a discontinuity, then it must reset sysUpTime (basically means a warm (re-)start). Therefore, all *other* counters that also use sysUpTime are going to look and be treated as if they also had a discontinuity. This may have performance implications, in terms of network management stations generating additional queries for these (unaffected) counters as well. 2. Add a new object for indicate discontinuity: This would necessitate adding a new (perhaps) unnecessary object, if sysUpTime can serve the purpose. In addition, systems would have an additional overhead of maintaining this information. Hence the question to folks here is: 1. Are there any known systems that can experience a discontinuity in the TCP counters without affecting the network management portion of the system. For e.g. are there systems that can restart the TCP portion of the system without restarting the network management portion of the system (or the whole system)? 2. Does anyone see any other case in which we might need to/want to maintain a discontinuity timer in the TCP-MIB? My assumption is that there might not be any systems that need an explicit discontinuity timer (but I could be wrong). Hence, would appreciate responses. Thanks, Rajiv. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:06:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24528 for ; Tue, 30 Mar 2004 18:06:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjY-0006Xa-4P for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2153SdL010490 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 00:03:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfaQ-0002fU-B5 for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:03:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04113 for ; Mon, 1 Mar 2004 00:03:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfaN-0007UU-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:03:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfZR-0007Q0-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:02:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfZB-0007LX-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 00:02:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfZ3-0002Du-DN; Mon, 01 Mar 2004 00:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfYR-00028O-Av for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 00:01:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03179 for ; Mon, 1 Mar 2004 00:01:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxfYP-0007Ki-00 for ipv6@ietf.org; Mon, 01 Mar 2004 00:01:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfXW-0007Gl-00 for ipv6@ietf.org; Mon, 01 Mar 2004 00:00:27 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AxfWw-0007CO-00 for ipv6@ietf.org; Sun, 29 Feb 2004 23:59:50 -0500 Message-ID: <02e001c3ff4a$19e0c6d0$3e6015ac@dclkempt40> From: "James Kempf" To: "James Kempf" Cc: "Nick 'Sharkey' Moore" , "IPV6 WG" References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> <20040226200901.GB23217@zoic.org> <20040227075924.GA28029@zoic.org> <017401c3ff24$628a6b50$3e6015ac@dclkempt40> <02c401c3ff49$31f1ede0$3e6015ac@dclkempt40> Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) Date: Sun, 29 Feb 2004 21:00:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "James Kempf" Cc: "Nick 'Sharkey' Moore" ; "IPV6 WG" Sent: Sunday, February 29, 2004 8:53 PM Subject: Re: SEND/DIID interoperabilility (was: Re: [rfc2462bis issue 275] DAD text inconsistencies) > > We have two nodes, a "SEND node" and a "DIID node". > > > > SEND node: > > - (for simplicity) do not implement the DIID-style optimization > > - have an (e.g.,) EUI-64 based interface identifier, I. > > - configure a SEND (CGA) address P:A (where A is the identifier, A != I) > > > > DIID node > > - implement the DIID-style optimization > > - (for simplicity) do not implement SEND > > - happen to have A as an interface identifier > > > > The SEND node comes to a link. It perform DAD for both fe80::I and > > P:A, and confirms that these are unique. > > > > No, the SEND node performs DAD for fe80::C, where C is a function of the key > and some other parameters. The prefix on LL addresses is also calculated > from the key. > Sorry, I meant suffix. jak > > Then the DIID node comes to the same link. It performs DAD for > > fe80::A, and confirms it is unique. So the DIID node start using > > P:A without doing DAD while P:A is actually duplicate. > > > > Yes, that's the concern. If the DIID node comes on the link second, then it > will assume that A is a unique prefix even though it only DADs it for the LL > address. > > jak > > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Tue Mar 30 18:07:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24841 for ; Tue, 30 Mar 2004 18:07:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006YH-G5 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OGZoUm030782 for ipv6-archive@odin.ietf.org; Wed, 24 Sep 2003 12:35:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2CcI-00080P-Qo for ipv6-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 12:35:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25277 for ; Wed, 24 Sep 2003 12:35:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2CcH-00075L-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 12:35:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2CcG-00075I-00 for ipv6-web-archive@ietf.org; Wed, 24 Sep 2003 12:35:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2CbX-0007cv-9T; Wed, 24 Sep 2003 12:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Cb2-0007ae-Q9 for ipv6@optimus.ietf.org; Wed, 24 Sep 2003 12:34:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25209 for ; Wed, 24 Sep 2003 12:34:24 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Cb1-00073Q-00 for ipv6@ietf.org; Wed, 24 Sep 2003 12:34:31 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A2Cb0-00073N-00 for ipv6@ietf.org; Wed, 24 Sep 2003 12:34:30 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8OGYSt11305 for ; Wed, 24 Sep 2003 19:34:28 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 24 Sep 2003 19:34:28 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 19:34:28 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 24 Sep 2003 19:34:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-ipv6-node-requirements-05.txt Date: Wed, 24 Sep 2003 19:34:27 +0300 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-ipv6-node-requirements-05.txt Thread-Index: AcNr7PsS2p0HxAZhTt22lxbf/Rh2lgWhiKegABGi2QA= To: X-OriginalArrivalTime: 24 Sep 2003 16:34:28.0023 (UTC) FILETIME=[B8F68470:01C382B9] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 2nd try, 1st try was rejected by the list admin. > -----Original Message----- > From: Loughney John (NRC/Helsinki)=20 > Sent: 24 September, 2003 11:11 > To: 'pekkas@netcore.fi'; 'ipng@sunroof.eng.sun.com' > Subject: RE: I-D ACTION:draft-ietf-ipv6-node-requirements-05.txt >=20 >=20 > Hi all, >=20 > Pekka had raised the comment that a reference to the MLDv1=20 > Source Address Selection=20 > document should be added to the Node Reqirements document: >=20 > > > 1) some comments never made it to the draft, were they=20 > missed or rejected=20 > > > for some purpose? (Example: MLDv1 Source Address=20 > Selection document which=20 > > > has been approved by the IESG.) > >=20 > > As people bothered to write the document to fix a bootstrap=20 > problem in=20 > > MLDv1, I believe it should be included. >=20 > Does anyone have a problem with this? >=20 > thanks, > John >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:07:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25008 for ; Tue, 30 Mar 2004 18:07:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006WI-6f for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BAIajL026348 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 05:18:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1NGk-0006qp-E1 for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 05:18:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23311 for ; Thu, 11 Mar 2004 05:18:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1NGh-0001zL-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 05:18:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1NFi-0001nX-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 05:17:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1NEj-0001dx-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 05:16:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1NEU-0006TU-Se; Thu, 11 Mar 2004 05:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1NDo-0006SB-Vu for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 05:15:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23184 for ; Thu, 11 Mar 2004 05:15:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1NDl-0001Uy-00 for ipv6@ietf.org; Thu, 11 Mar 2004 05:15:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1NCt-0001Lh-00 for ipv6@ietf.org; Thu, 11 Mar 2004 05:14:27 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1B1NBy-00012m-00 for ipv6@ietf.org; Thu, 11 Mar 2004 05:13:30 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i2BAD0Bv004953; Thu, 11 Mar 2004 11:13:00 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i2BAD0nM017078; Thu, 11 Mar 2004 11:13:00 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 11 Mar 2004 11:13:00 +0100 From: Stig Venaas To: Jari Arkko Cc: Pekka Savola , "'Jyrki Soini'" , ipv6@ietf.org Subject: Re: ICMPv6 echo reply to multicast packet thread Message-ID: <20040311101300.GA17035@sverresborg.uninett.no> References: <40500617.9030301@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40500617.9030301@kolumbus.fi> User-Agent: Mutt/1.4.1i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Mar 11, 2004 at 08:24:23AM +0200, Jari Arkko wrote: [...] > This still leaves open what the behaviour for ICMPv6 Echo Request > should be. I would not bundle this issue with what the other > applications do, but my default answer would be to not respond > to multicast requests unless there is a specific reason to do > so. In this case there seems to be some discussion about multicast > debugging capabilities. I do not have experience of that myself. > Are multicast echo requests the primary multicast debugging > mechanism? If yes, we should allow responses to be sent. If not, > I agree with Suresh that it should be disallowed. Note that > multicast debugging through echo responses is naturally limited > to rather small multicast groups ;-) So I suspect people who > need multicast in a large scale are going to need another > debugging tool in any case. ICMP echo to link-local multicast addresses is very useful for debugging. In particular the all-nodes group ff02::1. If one were to restrict this, I would make an exception for link-local scope at least. Stig -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:07:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25053 for ; Tue, 30 Mar 2004 18:07:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006YH-4z for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OEvCcN017815 for ipv6-archive@odin.ietf.org; Tue, 24 Feb 2004 09:57:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdzj-0004dG-JP for ipv6-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 09:57:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23575 for ; Tue, 24 Feb 2004 09:57:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avdzh-00063B-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:57:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avdyl-0005xo-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:56:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AvdyI-0005st-00 for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:55:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AvdyH-00052S-DB for ipv6-web-archive@ietf.org; Tue, 24 Feb 2004 09:55:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdxg-0003r8-Gj; Tue, 24 Feb 2004 09:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avdwk-0003ky-Mv for ipv6@optimus.ietf.org; Tue, 24 Feb 2004 09:54:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23304 for ; Tue, 24 Feb 2004 09:54:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avdwi-0005cx-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:54:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avdvk-0005U6-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:53:05 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Avdur-0005J1-00 for ipv6@ietf.org; Tue, 24 Feb 2004 09:52:09 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id CFAE36A902; Tue, 24 Feb 2004 16:52:07 +0200 (EET) Message-ID: <403B6495.80005@kolumbus.fi> Date: Tue, 24 Feb 2004 16:49:57 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: "Nick 'Sharkey' Moore" , ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies References: <200402241402.i1OE2iSj030222@givry.rennes.enst-bretagne.fr> In-Reply-To: <200402241402.i1OE2iSj030222@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francis Dupont wrote: > Sure. But aren't you assuming that they have to go in and manually > recover? > > => it is the case for IPv4 because this kind of event is very rare > so there is no need to add an automatic recover tool. But IMHO > the real question is where are these problems for? They don't come > from hazard but in 99.99% of cases from configuration errors. Yes. > Note: In some cases the collisions is due to L2 address collision, > which I agree is quite troublesome. > > => L2 address collisions are fatal. And IMHO we should not even try to > solve them at L3 (:-). Agreed. > And in many cases the address collision is not based on L2. > > => currently there are three common ways to assign addresses: > - EUI64 based, i.e., relying on L2 address universal uniqueness > (read my EMEI draft to use it on mobile phones too) > - RFC 3401, i.e., relying on the "birthday" paradox > - manual, i.e., relying on the care of node managers. > Obviously only the last one is a real source of trouble. Agreed. > I believe what the optimistic or optimized DAD > folks intend to do is to provide a *protocol* that allows both > (a) faster operation and (b) recovery if a collision happens. > > => this is a half baked solution, i.e., either you don't want duplicates > on your network and you enforce DAD, or you accept possible problems > and you makes the live of mobile nodes (and of implementors) far easier. (snip) > => what we need is collision avoidance, no collision detection after > damage. Here I have a slightly different opinion. There are two questions: do we want avoidance or detection, and whether optimistic DAD implies "possible problems". Regarding the first question, I think what we can achieve depends on how the address is assigned, random/ eui/conf. Generally, for the last two we can only provide detection and then wait for further input from the user; for the first we can still continue and use another address. But this has little to do with regular or optimistic DAD, both provide detection as the name implies. Regarding the second question, I do not agree that an optimistic DAD implies problems. It seems reasonable that an optimized variant would detect duplicates with an equivalent reliability as regular DAD; both send similar messages and expect other nodes to answer. Would you agree? But perhaps you are worried about the possible temporary disruptions to ongoing traffic? Is that your concern? I looked at Nick's draft, and did not find it alarming myself. But others may have a different opinion. Let me ask you this: if it was shown that a particular optimistic DAD protocol did not have even temporary disruptions, would you still think it implies "possible problems"? > I am unable to say for sure if, say, draft-moore, accomplishes this goal. > It probably needs more analysis before we can be certain. However, > I do not see any obvious problems. > > => the problem is the goal of optimistic/optimized DAD has no interest. I'm not sure I can parse what you are saying. There seems to be some people who do have an interest in quick startup & movement times. I agree that DAD is not the only issue to look at here -- I once calculated the number of messages that were required on a wireless LAN for L2 & L3 network attachment if you needed access control, link layer security, mobility, and so on. That number was pretty high, over a dozen even in the most optimistic scenario, significantly worse in others. And then there were multiple delay periods, all contributing to the overall delay. DAD is one of these delay periods. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:08:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25091 for ; Tue, 30 Mar 2004 18:08:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006a4-7w for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MANRo4019292 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 05:23:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Mab-000515-UY for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 05:23:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14445 for ; Mon, 22 Mar 2004 05:23:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MaY-00038a-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 05:23:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MZc-00031f-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 05:22:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5MYl-0002vf-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 05:21:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MOl-0003nA-O2; Mon, 22 Mar 2004 05:11:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5MN1-0003HX-6z for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 05:09:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13975 for ; Mon, 22 Mar 2004 05:09:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5MMy-0001cU-00 for ipv6@ietf.org; Mon, 22 Mar 2004 05:09:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5MLz-0001X5-00 for ipv6@ietf.org; Mon, 22 Mar 2004 05:08:20 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1B5MLi-0001ST-00 for ipv6@ietf.org; Mon, 22 Mar 2004 05:08:02 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1D57615210; Mon, 22 Mar 2004 19:08:00 +0900 (JST) Date: Mon, 22 Mar 2004 19:07:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Suresh Krishnan Cc: Ralph Droms , Subject: Re: reference dependency (DS to PS) (Re: [rfc2462bis] M/O flags and DHCPv6) In-Reply-To: References: <7B2A7784F4B7F0409947481F3F3FEF830D8F6B78@eammlex037.lmc.ericsson.se> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 (Sorry for not responding sooner) >>>>> On Tue, 9 Mar 2004 20:10:13 -0500 (EST), >>>>> Suresh Krishnan said: > Don't if it is concrete or not but Section 4.2.4 of RFC2026 states > Note: Standards track specifications normally must not depend on > other standards track specifications which are at a lower maturity > level or on non standards track specifications other than referenced > specifications from other standards bodies. (See Section 7.) > Since PS is lower than DS on the maturity level, a DS spec cannot have a > normative reference to a PS spec. Thanks for the pointer. My understanding from this and the I-D Pekka provided (thanks) is: - PS is at a lower maturity level than DS is (Sections 4.1.1 and 4.1.2 of RFC2026). - so, a DS spec must not "depend on" a PS spec (Section 4.2.4 of RFC2026) - draft-ymbk-downref-01 clarifies what the dependency means in terms of the reference category. It says in abstract that: IETF procedures generally require that a standards track RFC may not have a normative reference to a document at a lower standards level. (it seems to me that this draft rather concentrates on exceptions to this rule than the original rule itself, but I guess it's enough for now) The draft use the term "standards level", but it obviously means the maturity level. As a conclusion, it should be wise not to have a normative reference to a PS document from rfc2462bis, even though there may be exceptions. This means we should not have a normative reference from rfc2462bis to RFC3315 (PS) or to node requirements document (will be info). Through the discussions so far, (my understanding of) the consensus is that it is okay to use the documents as an informative reference (which document should be used is a separate question). 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 exim@www1.ietf.org Tue Mar 30 18:08:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25131 for ; Tue, 30 Mar 2004 18:08:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006WI-4a for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2LB9kT7005296 for ipv6-archive@odin.ietf.org; Sun, 21 Mar 2004 06:09:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B50pu-0001NL-KE for ipv6-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 06:09:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06260 for ; Sun, 21 Mar 2004 06:09:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B50pq-0006h4-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 06:09:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B50ot-0006Za-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 06:08:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B50nx-0006Sb-00 for ipv6-web-archive@ietf.org; Sun, 21 Mar 2004 06:07:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B50nI-0000Ig-EI; Sun, 21 Mar 2004 06:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B50mu-0000CY-VH for ipv6@optimus.ietf.org; Sun, 21 Mar 2004 06:06:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06156 for ; Sun, 21 Mar 2004 06:06:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B50mr-0006KW-00 for ipv6@ietf.org; Sun, 21 Mar 2004 06:06:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B50lr-0006EJ-00 for ipv6@ietf.org; Sun, 21 Mar 2004 06:05:36 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1B50kr-00064e-00 for ipv6@ietf.org; Sun, 21 Mar 2004 06:04:33 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2004 03:11:10 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2LB43Uk023287 for ; Sun, 21 Mar 2004 06:04:03 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-39.cisco.com [10.86.242.39]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY75270; Sun, 21 Mar 2004 06:04:02 -0500 (EST) Message-Id: <4.3.2.7.2.20040321055909.0292fc28@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 21 Mar 2004 06:02:11 -0500 To: From: Ralph Droms Subject: Re: simpler prefix delegation In-Reply-To: References: <405AA71B.E4EC2537@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 10:44 AM 3/20/2004 +0200, Pekka Savola wrote: >On Fri, 19 Mar 2004, Brian E Carpenter wrote: > > > As I've said before in reference to the recursive name server discovery > > > discussion, I don't believe it benefits the network operations community > > > to have multiple solutions to these kind of requirements. > > > > The vendor community would probably agree. > >Probably, except for those vendors who would rather not want to be >required to implement DHCPv6 for tasks {Foo, Bar, ....}. The network architect/engineer/admin (customer) community should be considered here, as well. Are there any customers that have said "DHCPv6 PD is too complex, we want something simpler"? I haven't heard from any. >The question is really whether DHCPv6 is a feasible requirement in >*every* scenario where you'd desire prefix delegation, [DNS >discovery], and [whatnot]. If there is consensus that the answer is >"yes", we can focus the energies elsewhere. But I do not think there >is such concensus (even a rough one; even if it might help). I think the question is really "Do the network architects/engineers/admins (customers) want something simpler"? We don't need to make that decision for them. >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - Ralph - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:09:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25382 for ; Tue, 30 Mar 2004 18:09:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjW-0006YH-Ou for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H3rBtP011447 for ipv6-archive@odin.ietf.org; Tue, 16 Mar 2004 22:53:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3S7A-0002yS-NI for ipv6-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 22:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17265 for ; Tue, 16 Mar 2004 22:53:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3S77-00014l-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 22:53:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3S67-0000ym-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 22:52:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3S59-0000t0-00 for ipv6-web-archive@ietf.org; Tue, 16 Mar 2004 22:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3S4B-0002cL-8A; Tue, 16 Mar 2004 22:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3S3Q-0002ac-Bf for ipv6@optimus.ietf.org; Tue, 16 Mar 2004 22:49:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17176 for ; Tue, 16 Mar 2004 22:49:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3S3M-0000j2-00 for ipv6@ietf.org; Tue, 16 Mar 2004 22:49:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3S2V-0000dY-00 for ipv6@ietf.org; Tue, 16 Mar 2004 22:48:20 -0500 Received: from farside.isc.org ([204.152.187.5]) by ietf-mx with esmtp (Exim 4.12) id 1B3S27-0000XB-00 for ipv6@ietf.org; Tue, 16 Mar 2004 22:47:55 -0500 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id C6E10A82B for ; Wed, 17 Mar 2004 03:47:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i2H3lFqW093779; Wed, 17 Mar 2004 14:47:16 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200403170347.i2H3lFqW093779@drugs.dv.isc.org> To: Alain Durand Cc: Stephen Sprunk , ipv6@ietf.org, Brian E Carpenter , Margaret Wasserman From: Mark Andrews Subject: Re: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt In-reply-to: Your message of "Mon, 15 Mar 2004 10:07:23 -0800." <9C0F03A6-76AB-11D8-9F71-00039376A6AA@sun.com> Date: Wed, 17 Mar 2004 14:47:15 +1100 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > On Mar 15, 2004, at 12:57 AM, Stephen Sprunk wrote: > > > Thus spake "Brian E Carpenter" > >> Margaret Wasserman wrote: > >> ... > >>> SUBSTANTIVE ISSUES: > >>> > >>> (1) This draft doesn't mention the reverse DNS tree. Is it expected > > that > >>> whatever registry assigns these values will also populate the > > reverse > >>> DNS tree? Or not? > >> > >> I think it is better to leave this question for a separate document > >> (which > >> certainly needs to be written). I don't think we should delay the > >> present > >> document for this. > > > > I think this revolves around a basic question of whether information > > about > > centrally-assigned local prefixes should be available to third > > parties. If > > so -- and that is my preference -- then WHOIS information should be > > provided > > and DNS delegations should be available, though not mandatory. > > Optional > > global DNS delegations may be beneficial to those using local > > addresses to > > communicate privately between organizations because it can remove the > > need > > for split DNS. > > I too would like to see the reverse tree DNS being delegated. However, > as there is no > structure, the entire /8 to /48 address space would have to be within > one single zone... > I'm afraid we are going to create a monster zone that will be very > difficult to sign with DNSsec. No it doesn't have to be within one zone. You can split the namespace between as many zones / servers as are required to make the job managable. How this is done really should be left to the authority which is managing the space. > - Alain. > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Tue Mar 30 18:09:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25440 for ; Tue, 30 Mar 2004 18:09:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjW-0006Xa-M3 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18GcMOa005725 for ipv6-archive@odin.ietf.org; Sun, 8 Feb 2004 11:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aprws-0001UG-9L for ipv6-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 11:38:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23438 for ; Sun, 8 Feb 2004 11:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aprwr-0003sl-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 11:38:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aprvs-0003o3-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 11:37:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aprv1-0003kK-00 for ipv6-web-archive@ietf.org; Sun, 08 Feb 2004 11:36:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aprud-0000mX-R8; Sun, 08 Feb 2004 11:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aprtw-0000m2-2Q for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 11:35:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23377 for ; Sun, 8 Feb 2004 11:35:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aprtv-0003fF-00 for ipv6@ietf.org; Sun, 08 Feb 2004 11:35:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aprt0-0003bx-00 for ipv6@ietf.org; Sun, 08 Feb 2004 11:34:23 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1Aprss-0003YY-00 for ipv6@ietf.org; Sun, 08 Feb 2004 11:34:14 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:4819:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 3E1191525D; Mon, 9 Feb 2004 01:34:13 +0900 (JST) Date: Mon, 09 Feb 2004 01:34:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay In-Reply-To: <4026418E.2060900@innovationslab.net> References: <200402051555.i15Ft8Zo031842@burp.tkv.asdf.org> <40230318.7000101@eng.monash.edu.au> <4026418E.2060900@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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Sun, 08 Feb 2004 09:02:54 -0500, >>>>> Brian Haberman said: > Given my point above, I would argue that we shouldn't add a delay to > MLD messages. So, do you have any opinion among the options I raised in this thread? 1. no change in rfc2462bis (expecting MLDv1 and/or MLDv2 will eventually be updated with a random delay) 2. the original proposal of mine (expecting MLDv1 and/or MLDv2 will eventually be updated with a random delay): impose a random delay even for the first NS after the corresponding MLD when the sending node knows there is no delay for the MLD. 3. Greg's suggestion: require a random delay before the first MLD (in rfc2462bis). (including "4. none of above"). Apparently you'd reject option 3 from your point. I also know that you are NOT expecting MLDv1/v2 will be updated with a random delay, even if you prefer option 1 or 2 itself. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:09:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25518 for ; Tue, 30 Mar 2004 18:09:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjW-0006WI-M1 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IEotJX017452 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 09:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yr8-0004X3-BS for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 09:50:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14977 for ; Thu, 18 Mar 2004 09:50:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yr1-0000e2-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 09:50:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yq0-0000UF-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 09:49:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3ypM-0000MG-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 09:48:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yoU-0003px-0v; Thu, 18 Mar 2004 09:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ynz-0003ky-5Y for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 09:47:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14556 for ; Thu, 18 Mar 2004 09:47:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3ynx-0000E0-00 for ipv6@ietf.org; Thu, 18 Mar 2004 09:47:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ynI-00007W-00 for ipv6@ietf.org; Thu, 18 Mar 2004 09:46:48 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3ymk-0007k5-00 for ipv6@ietf.org; Thu, 18 Mar 2004 09:46:14 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2IEjfaD012300; Thu, 18 Mar 2004 06:45:41 -0800 (PST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-38.cisco.com [10.86.240.38]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGW68242; Thu, 18 Mar 2004 09:45:38 -0500 (EST) Message-Id: <4.3.2.7.2.20040318093441.029eb910@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Mar 2004 09:45:12 -0500 To: ipv6@ietf.org From: Ralph Droms Subject: Re: simpler prefix delegation Cc: Ole Troan , , , Pekka Savola In-Reply-To: References: <7t5brmus1r5.fsf@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 For the IPv6 WG - let's cut to the chase. Is there interest in expending any more of the IETF's resources reopening a problem for which we have rough consensus on a solution, published specifications and running code? We have lots of important problems that have *no* solution, yet; let's move on to those problems and start deploying the solutions we already have completed. - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:09:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25522 for ; Tue, 30 Mar 2004 18:09:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjV-0006YH-CP for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA49vQ5s024183 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 04:57:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxwC-0006Hx-8Q for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 04:57:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06248 for ; Tue, 4 Nov 2003 04:57:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxw9-00023p-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 04:57:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGxw8-00023m-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 04:57:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxvs-0006Bv-FL; Tue, 04 Nov 2003 04:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwYe-0007F4-BZ for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 03:29:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03498 for ; Tue, 4 Nov 2003 03:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwYb-0000fj-00 for ipv6@ietf.org; Tue, 04 Nov 2003 03:28:58 -0500 Received: from mail.ki.iif.hu ([193.6.222.240] helo=mignon.ki.iif.hu) by ietf-mx with esmtp (Exim 4.12) id 1AGwYb-0000fM-00 for ipv6@ietf.org; Tue, 04 Nov 2003 03:28:57 -0500 Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id 2655B6DBF; Tue, 4 Nov 2003 09:28:24 +0100 (CET) Received: from mignon.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74217-01-3; Tue, 4 Nov 2003 09:28:18 +0100 (CET) Received: by mignon.ki.iif.hu (Postfix, from userid 1003) id 001CB6E46; Tue, 4 Nov 2003 09:28:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id F20776E06; Tue, 4 Nov 2003 09:28:17 +0100 (CET) Date: Tue, 4 Nov 2003 09:28:17 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Keith Moore Cc: colm@stdlib.net, Stig Venaas , pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031103162255.61563fcb.moore@cs.utk.edu> Message-ID: <20031104085701.X37922@mignon.ki.iif.hu> References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, 3 Nov 2003, Keith Moore wrote: > > On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote: > > > I don't think that we should be defining getaddrinfo() in terms of > > > "whatever lookup service happens to be around" because it's very > > > difficult to get reliable and repeatable behavior that way. > > > > Isn't the DNS a lookup service that happens to be around ? > > DNS is a specific lookup service. not a random one that just might happen > to be around. > > > The purpose of getaddrinfo is to perform network address and service > > translation. Whilst a portable, granular, interface to DNS would be > > very much welcome - getaddrinfo should not be it. > > Perhaps. But if getaddrinfo isn't the service that does DNS lookups, > then at least some apps should not be using it. getaddrinfo() and getnameinfo() was developed as a generalisation of gethostbyname() and gethostbyaddr(). Thus, from pragmatic point of view should follow the behaviour of the extended functions (gethostbyname etc.) Basically if you call them you are rely on the several different name service functions controlled by local configuration (e.g nsswitch.conf resolv.conf etc.) > > Well, link-local addresses should never be in DNS in the first place. Yes this is advisable! > My argument is not that link-local addresses should be returned by > getaddrinfo() , it is that getaddrinfo() should be transparent. Completely agree. The getaddrinfo() should be completely transparent from programmers' point of view. The local setup should be system/environment specific. I think the cleanest solution would be to setup the DNS resolution order locally by administrator: IPv6 address-resolution enable, and order of IPv4/IPv6 address-resolution. In my opinion, this should be included the resolver code and configurable from resolv.conf. We already have sortlist: IPv6 should be added, and then we could configure whether we want IPv6 address or IPv4 in the first place. To disable IPv6 DNS query should be configurable one the _res.options e.g RES_NO_INET6_QUERY. The current default is to do IPv6 RR query, so that one could be disabled. I strongly against the idea, to change the current default behavior of IPv6 applications without setting up new things. The compatibility is one of the most important feature that we have to keep! Regards, Janos Mohacsi -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:11:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25921 for ; Tue, 30 Mar 2004 18:11:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjV-0006Xa-Ta for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7TQIF016532 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:29:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZuP-0004B2-Uo for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:29:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06478 for ; Thu, 23 Oct 2003 03:29:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZu7-0002sA-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:29:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZu7-0002s7-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:29:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZu8-00043t-1p; Thu, 23 Oct 2003 03:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZty-0003qc-J1 for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 03:28:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06459 for ; Thu, 23 Oct 2003 03:28:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZtw-0002rY-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:28:56 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1ACZtv-0002rI-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:28:55 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HN7009J68REDT@mailout2.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 16:28:26 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HN70046X8Q60P@mailout2.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 16:27:43 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HN700B9U8Q6MU@mmp1.samsung.com> for ipv6@ietf.org; Thu, 23 Oct 2003 16:27:42 +0900 (KST) Date: Thu, 23 Oct 2003 16:28:00 +0900 From: Soohong Daniel Park Subject: RE: "RFC 2461bis" issue: DNS configuration In-reply-to: <20031023071443.6158491@coconut.itojun.org> To: "'Jun-ichiro itojun Hagino'" Cc: H.Soliman@flarion.com, iljitsch@muada.com, ipv6@ietf.org Message-id: <012201c39937$2fe5b4a0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello itojun >Hesham's statement does not reject RA-based DNS discovery, it >seems to me. there's nothing wrong with the above-quoted line. Yes, I didn't say something was wrong but considered one of issue. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:11:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26041 for ; Tue, 30 Mar 2004 18:11:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjV-0006ZK-3x for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I9rPLp029821 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 04:53:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uDL-0007ku-6D for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 04:53:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29918 for ; Thu, 18 Mar 2004 04:53:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uDI-0000Ui-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 04:53:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uCM-0000N6-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 04:52:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3uBz-0000FU-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 04:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uB5-0007GW-AQ; Thu, 18 Mar 2004 04:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uAG-0007EW-Aq for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 04:50:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29751 for ; Thu, 18 Mar 2004 04:50:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uAD-00007j-00 for ipv6@ietf.org; Thu, 18 Mar 2004 04:50:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3u9E-00000d-00 for ipv6@ietf.org; Thu, 18 Mar 2004 04:49:09 -0500 Received: from gura.nttv6.jp ([210.163.36.2]) by ietf-mx with esmtp (Exim 4.12) id 1B3u8G-0007cv-00 for ipv6@ietf.org; Thu, 18 Mar 2004 04:48:08 -0500 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [IPv6:2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 7319F1FE47; Thu, 18 Mar 2004 18:47:37 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 479B7125B7D; Thu, 18 Mar 2004 18:47:37 +0900 (JST) Date: Thu, 18 Mar 2004 18:47:37 +0900 (JST) Message-Id: <20040318.184737.71091593.miyakawa@nttv6.jp> To: pekkas@netcore.fi Cc: ipv6@ietf.org, skylane@etri.re.kr, erik.nordmark@sun.com Subject: Re: simpler prefix delegation From: Shin Miyakawa In-Reply-To: References: Organizaton: NTT Communications X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > This started from me looking at draft-bykim-ipv6-hpd-01.txt, what it > was before that, DHCPv6 + PD, a few proposals at v6ops for integrated > prefix delegation, etc.. -- I couldn't help thinking, "there must be > an easier way to delegate an IPv6 prefix in the simplest setups (e.g., > when v6 connectivity is obtained through a tunnel) -- DHCPv6 is way > too heavy-weight". "way too Heavy Weight" is not well-defined. Please explain a bit more how you decide this. Pekka ? When we dicuss about measurement, we should be mathematical. Otherwise it sounds just a feeling or myth which leads us to just a superstition. In this case, the information carried by the protocol - either DHCP format or whatever - is essentially the same; just a prefix information which is about 128bits + prefix length. Therefore the volume of the bits are also not so different in either case. Also we need have some software (or maybe hardware) to process prefix delegation but the complexity of either software is just about the same, because it is very simple job. When I started the work of prefix delegation several years ago, Steve Deering told me that ICMP and RA are very fundamental so we should keep those as simple as possible. I believe that that philosophy is worth to keep still (or forever). Lastly, Let us recallvery important fact which is that we should not have many options or protocols for the same purpose. So, if we have DHCPv6 today, Let's use it. Best regards, Shin Miyakawa -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:13:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26407 for ; Tue, 30 Mar 2004 18:13:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjU-0006Xa-OR for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADGtJ5c013778 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 11:55:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKkW-0003Wy-QU for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 11:55:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07772 for ; Thu, 13 Nov 2003 11:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKkT-0000nm-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 11:55:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKKkS-0000nj-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 11:55:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKkK-0003RG-Bx; Thu, 13 Nov 2003 11:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKjS-0003Pr-6r for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 11:54:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07640 for ; Thu, 13 Nov 2003 11:53:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKjQ-0000lX-00 for ipv6@ietf.org; Thu, 13 Nov 2003 11:54:09 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1AKKjP-0000jK-00 for ipv6@ietf.org; Thu, 13 Nov 2003 11:54:08 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hADGrakF024190 for ; Thu, 13 Nov 2003 11:53:36 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hADGrZoA324176 for ; Thu, 13 Nov 2003 09:53:35 -0700 In-Reply-To: To: Lori Napoli , ipv6@ietf.org MIME-Version: 1.0 Subject: Re: Question regarding RFC 2461 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 11/13/2003 10:53:48 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 11/13/2003 10:53:48 AM, Serialize complete at 11/13/2003 10:53:48 AM, S/MIME Sign failed at 11/13/2003 10:53:48 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 11/13/2003 09:53:35, Serialize complete at 11/13/2003 09:53:35 Message-ID: Date: Thu, 13 Nov 2003 10:53:33 -0600 Content-Type: text/plain; charset="US-ASCII" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > I have a question about whether a NA sent to all-nodes multicast address > with the solicited bit ON is valid or invalid. Here are excerpts from the > RFC. > > For destination address in a NA: For solicited advertisements, the Source > Address of an invoking Neighbor Solicitation or, if the solicitation's > Source Address is the unspecified address, the all-nodes multicast address > > This makes it sound like a NA could be sent to the all nodes multicast > address and have the solicited bit ON. > > However, here is what is says under the solicited bit: When set, the S-bit > indicates that the advertisement was sent in response to a Neighbor > Solicitation from the Destination address. The S-bit is used as a > reachability confirmation for Neighbor Unreachability Detection. It MUST > NOT be set in multicast advertisements or in unsolicited unicast > advertisements. > > This states the solicited bit MUST NOT be set if the NA is destined for a > multicast address. > > Can you please clarify if a NA sent to all-nodes multicast address with > solicited bit ON is considered valid or invalid. Thanks! This is covered in section 7.2.4: If the source of the solicitation is the unspecified address, the node MUST set the Solicited flag to zero and multicast the advertisement to the all-nodes address. Otherwise, the node MUST set the Solicited flag to one and unicast the advertisement to the Source Address of the solicitation. Roy -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:13:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26449 for ; Tue, 30 Mar 2004 18:13:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjU-0006Zv-RN for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDtdsr014011 for ipv6-archive@odin.ietf.org; Sat, 20 Sep 2003 09:55:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0iD5-0003dZ-5m for ipv6-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:55:39 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05254 for ; Sat, 20 Sep 2003 09:55:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NgB-0007Xe-CZ; Fri, 19 Sep 2003 12:00:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nf9-0007H5-Nq for ipv6@optimus.ietf.org; Fri, 19 Sep 2003 11:59:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02039 for ; Fri, 19 Sep 2003 11:59:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0MyW-0004zT-00 for ipv6@ietf.org; Fri, 19 Sep 2003 11:15:12 -0400 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1A0MkE-00011a-00 for ipv6@ietf.org; Fri, 19 Sep 2003 11:00:26 -0400 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id B4341140AF; Fri, 19 Sep 2003 10:59:39 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11515-09; Fri, 19 Sep 2003 10:59:39 -0400 (EDT) Received: from webmail.cs.utk.edu (yomega.cs.utk.edu [160.36.56.70]) by smtp.cs.utk.edu (Postfix) with ESMTP id 40B4E1409F; Fri, 19 Sep 2003 10:59:39 -0400 (EDT) Received: from 172.129.252.90 (SquirrelMail authenticated user moore) by yomega.cs.utk.edu with HTTP; Fri, 19 Sep 2003 10:59:39 -0400 (EDT) Message-ID: <4559.172.129.252.90.1063983579.squirrel@yomega.cs.utk.edu> In-Reply-To: <10139310537.20030918140515@brandenburg.com> References: <3F658C6B.1040700@nomadiclab.com> <20030915083156.4581ae3f.moore@cs.utk.edu><15758260584.20030917153425@brandenburg.com><20030917222154.218e173d.moore@cs.utk.edu> <10139310537.20030918140515@brandenburg.com> Date: Fri, 19 Sep 2003 10:59:39 -0400 (EDT) Subject: Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) From: "Keith Moore" To: "Dave Crocker" Cc: "Keith Moore" , ipv6@ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dave, You're simply wrong. The scenarios I described are things that applications do today using IP addresses as endpoint identifiers, extrapolated to the world where DNS names are used instead. I won't claim that it's impossible to use DNS names for endpoint identifiers. I do claim, and have explained in detail, why: - using existing DNS names is a bad idea (due to overloading) - using the DNS lookup system is a bad idea (due to performance issues) You have the habit of dismissing anything that you don't understand as irrelevant. This is just another example. Frankly it's getting old. Keith Dave Crocker said: > Keith, > >>> KM> * Ambiguous and overloaded. Quite often, a DNS name doesn't >>> refer to >>> KM> a host. >>> So? What problem does that cause? Specifically, please provide a >>> usage >>> example that would cause a problem. > > KM> Name EXAMPLE.COM maps to hosts B and C. Hosts B ausing addresses B= 1 > and C1, > KM> respectively. Host A looks up EXAMPLE.COM, gets addresses B1 and C= 1, > chooses > KM> B1, and starts talking to it. The application now has some state t= hat > is only > KM> accessible to host B. > KM> For some reason the connection gets broken. Maybe host B changes i= ts > KM> address from B1 to B2. A needs to re-establish a connection to hos= t B > - > KM> host C will not work because the application now relies on state th= at > only > KM> B can access. EXAMPLE.COM does not name host B uniquely; > > > I am guessing that you have not read the MAST proposal and have not bee= n > noting the details that a number of us are seeking about actual > requirements > for an endpoint identifier.. I'm suspecting you also are not familiar w= ith > the > other proposals. > > So, yes, you have invented a scenario that uses domain names in a way t= hat > will not work. Unfortunately, no one is proposing such a broken scenar= io. > > So let me rephrase the question more simply and more rigidly: > > What is it that _requires_ specifying using domain names in a way > that > causes problems? > > If that question is not clear enough, then try: > > What is _inherent_ in domain names that prevents their use as > endpoint > identifiers? Inherent, not merely "possible". > > It is always possible to create a broken design. Citing such an exampl= e > is > not overly helpful. > > However I really should thank you. Much of these discussions have been > marked > by attempts to make design choices based on very abstract issues, rathe= r > than > on looking on plausible and probable actual usage. This makes much of t= he > discussion fundamentally not grounded, both literally and figuratively. > > We now have quite a few concrete proposals and specifications. We shoul= d > make > a point of using these data points as concrete examples of the solution > space. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:13:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26499 for ; Tue, 30 Mar 2004 18:13:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjU-0006Zv-OS for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i247nm9V017027 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 02:49:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aync4-0004PI-Bv for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 02:49:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24526 for ; Thu, 4 Mar 2004 02:49:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynbl-0005zK-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:49:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynal-0005mJ-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:48:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AynZx-0005av-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:47:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynZS-0003mI-Hp; Thu, 04 Mar 2004 02:47:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynYP-0003aV-3a for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 02:46:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24100 for ; Thu, 4 Mar 2004 02:45:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynYL-0005Av-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:45:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynXH-0004tf-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:44:52 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AynWI-0004af-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:43:50 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 03 Mar 2004 23:47:27 -0800 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 i247hJh0011655 for ; Thu, 4 Mar 2004 02:43:19 -0500 (EST) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-91.cisco.com [10.86.242.91]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGM98062; Thu, 4 Mar 2004 02:43:16 -0500 (EST) Message-Id: <4.3.2.7.2.20040304023041.029dc170@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Mar 2004 02:33:23 -0500 To: ipv6@ietf.org From: Ralph Droms Subject: Re: [rfc2462bis] M/O flags and DHCPv6 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 02:19 AM 3/4/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >In the wg meeting on Tuesday, several concerns were raised regarding >this issue (and the proposed resolution). To summarize (some of) >them, > >1. the resolution proposes to say "the stateful protocol is DHCPv6" > clearly, without leaving other possibilities. This would require > RFC3315 (DHCPv6) to be listed as a normative reference. However, > we'll then face a reference dependency issue, since rfc2462bis is > soon expected to be recycled as a DS while RFC3315 is still a PS. > (BTW: I could not find a direct source of this dependency issue. > Could someone give me a pointer?) Do you mean that a DS spec cannot have an informative reference to a PS spec? - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:13:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26603 for ; Tue, 30 Mar 2004 18:13:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjU-0006Xa-Lo for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RM8kHE007664 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 17:08:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq9y-0001zW-AX for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 17:08:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27643 for ; Fri, 27 Feb 2004 17:08:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awq9w-0005cf-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 17:08:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awq91-0005Uy-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 17:07:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awq88-0005OR-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 17:06:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq7P-0000vG-8X; Fri, 27 Feb 2004 17:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq72-0000n5-CX for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 17:05:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27464 for ; Fri, 27 Feb 2004 17:05:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awq70-0005GP-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:05:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awq67-0005B5-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:04:44 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1Awq5t-00055N-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:04:29 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i1RM3u0J028703; Fri, 27 Feb 2004 14:03:57 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i1RM3sQ10923; Fri, 27 Feb 2004 23:03:54 +0100 (MET) Date: Fri, 27 Feb 2004 13:32:46 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [2461bis issue 250] Reception of prefix option with prefix length > 64 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Soliman Hesham , IETF Mailing List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > However, I think the receiving node should still consider the prefix > as valid in terms of ND (i.e., consider it as "on-link") and modify > the next-hop determination accordingly. > > The questions are: > > 1. is this a correct understanding of the intention of RFC2461? > 2. if yes, is this a reasonable behavior? > 3. if yes (for both 1 and 2), should this explicitly be documented in > rfc2461bis? This separation was the intent AFAIK, thus I answer "yes" on 1. If implementors have missed this then it sure should be clarified in the spec. If all or almost all of the implementors have missed this and we don't have a good reason for this behavior we should consider changing the specification. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:14:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26897 for ; Tue, 30 Mar 2004 18:14:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjU-0006Xa-06 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220PBmW019955 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 19:25:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxih-0005Bl-Ce for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:25:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15101 for ; Mon, 1 Mar 2004 19:25:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxif-0006iw-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:25:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxhn-0006cY-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:24:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxhM-0006W4-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 19:23:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxgc-0004Qk-U0; Mon, 01 Mar 2004 19:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxg0-0004P8-Ot for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 19:22:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14940 for ; Mon, 1 Mar 2004 19:22:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxfz-0006Op-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:22:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxf6-0006H6-00 for ipv6@ietf.org; Mon, 01 Mar 2004 19:21:28 -0500 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1AxxeQ-00066H-00; Mon, 01 Mar 2004 19:20:47 -0500 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id i220KBL27812; Mon, 1 Mar 2004 16:20:11 -0800 Received: from innovationslab.net (WXP-LAPBRIANH.dhcp.ietf59.or.kr [218.37.230.133]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id i220WLQP025755 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 1 Mar 2004 16:32:25 -0800 Message-ID: <4043D333.4010101@innovationslab.net> Date: Mon, 01 Mar 2004 19:20:03 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "" , agenda@ietf.org Subject: Updated IPv6 WG Agenda Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Introduction, Agenda Bashing, Document Status 05 Charter Update , Hinden 10 Node Requirements, Loughney 10 2461bis, Soliman 15 2462bis, Tatuya 15 ICMP Updates, Gupta/Hinden 15 Multi-protocol getnameinfo, Jun-ichiro 05 Load Sharing, Thaler 05 Optimistic DAD, N. Moore, D. Park 20 ND Proxy, D. Thaler 10 SIOCGIFaaa ioctls and IPv6 interfaces 10 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:15:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27085 for ; Tue, 30 Mar 2004 18:15:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjT-0006WI-8T for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ME6wCO017931 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 09:06:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Q4u-0004ev-8f for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 09:06:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25371 for ; Mon, 22 Mar 2004 09:06:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Q4n-0005TI-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 09:06:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Q3e-0005Fc-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 09:05:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Q2a-00055N-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 09:04:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Q1n-0003L3-2l; Mon, 22 Mar 2004 09:03:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Q0l-0003Hw-Cx for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 09:02:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25035 for ; Mon, 22 Mar 2004 09:02:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Q0j-0004pL-00 for ipv6@ietf.org; Mon, 22 Mar 2004 09:02:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Pzl-0004io-00 for ipv6@ietf.org; Mon, 22 Mar 2004 09:01:37 -0500 Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1B5Pz2-0004Y5-00 for ipv6@ietf.org; Mon, 22 Mar 2004 09:00:52 -0500 Received: from ssprunk (ip144.post-vineyard.dfw.ygnition.net [66.135.181.144]) by ns2.sea (8.12.11/8.12.5) with SMTP id i2ME0GxW031637; Mon, 22 Mar 2004 06:00:17 -0800 Message-ID: <004a01c41016$018efed0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "william\(at\)elan.net" Cc: "Bill Manning" , "IETF IPv6 WG" , "ARIN Policy" References: Subject: Re: [ppml] Re: ASN-based prefixes for leaf ASes Date: Mon, 22 Mar 2004 07:52:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "william(at)elan.net" > On Mon, 22 Mar 2004, Stephen Sprunk wrote: > > My proposal was that automatic /48 allocations be made to anyone with an > > ASN, based on the premise that every AS will advertise at least one PI > > block. > > If I remember right /48 is not a PI block (or rather it may not be within > ARIN region which uses different terminology), /48 are expected to be > allocated by ISPs (LIRs) to customers with their own network (rather when > its individual device and then its /64) but its provider-dependent > (i.e. PA) as far as its being assigned by ISP where as PI would be > micro-allocation directly by RIR /48 is the size ISPs are supposed to hand out to leaf sites (with or without an ASN), so that's the logical size of direct allocations to leaf sites. This also allows encoding a 32-bit ASN in the prefix while only consuming a /16 overall. I say 32-bit ASN because it's clear the 16-bit space will run out before IPv6 is retired; this could be changed to a 16-bit ASN if we really want to assign a /32 to each leaf AS, but that seems like overkill. > Now as far as assigning /48 for every ASN, lets not do it just yet - some > ASNs may need larger blocks then just /48 It's hard to envision a leaf AS needing more than 64k subnets, but in that case they could request a "normal" allocation from their RIR. 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 exim@www1.ietf.org Tue Mar 30 18:15:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27115 for ; Tue, 30 Mar 2004 18:15:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjT-0006Xa-BQ for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL8cowJ025761 for ipv6-archive@odin.ietf.org; Fri, 21 Nov 2003 03:38:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6oT-0006hQ-U1 for ipv6-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 03:38:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05262 for ; Fri, 21 Nov 2003 03:38:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN6oQ-0006E7-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 03:38:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN6oQ-0006E4-00 for ipv6-web-archive@ietf.org; Fri, 21 Nov 2003 03:38:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6nj-0006L7-9P; Fri, 21 Nov 2003 03:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6mr-0006BR-Dz for ipv6@optimus.ietf.org; Fri, 21 Nov 2003 03:37:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05232 for ; Fri, 21 Nov 2003 03:36:56 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN6mo-0006CX-00 for ipv6@ietf.org; Fri, 21 Nov 2003 03:37:06 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AN6mo-0006CT-00 for ipv6@ietf.org; Fri, 21 Nov 2003 03:37:06 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAL8b6618035 for ; Fri, 21 Nov 2003 10:37:06 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 21 Nov 2003 10:37:04 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Nov 2003 10:37:06 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 21 Nov 2003 10:37:06 +0200 Message-ID: Thread-Topic: Node Req: Issue31: DHCPv6 text (ignore previous mails) Thread-Index: AcOvn7i0ikHq2Z/JQeSCAQibW+dHDgAarRyQ To: Cc: X-OriginalArrivalTime: 21 Nov 2003 08:37:06.0457 (UTC) FILETIME=[A537E090:01C3B00A] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Bob, > > For those IPv6 nodes that implement DHCP, those nodes MUST use = DHCP > > upon the receipt of a Router Advertisement with the 'M' flag set = (see > > section 5.5.3 of RFC2462). In addition, in the absence of a = router, > > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. > >to: > > Nodes that implement DHCP MUST use DHCP upon the receipt of a > > Router Advertisement with the 'M' flag set (see section 5.5.3 of > > RFC2462). In addition, in the absence of a router, > > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this > > context, 'use DHCP' means trying to obtain both address(es) and > > other configuration information through DHCP. >=20 > Please remind me why the "in the absence of a router" text is there. = I am=20 > having a hard time thinking about a scenario where there would be a = DHCP=20 > server, but no router. The presences of a DHCP relay agent would also = need=20 > a router to be useful. Agreed. The text is bad. Thinking further, it should be something like if an RA is not received, then DHCP is used. However, thinking about = this further, if no RA is received, maybe someone might like to be prompted = to use manual configuration, not DHCP. Would that be possible? John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:15:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27157 for ; Tue, 30 Mar 2004 18:15:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjT-0006Xa-22 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q7Ahod016560 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 02:10:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFfP-0004Iv-Aq for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 02:10:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22378 for ; Thu, 26 Feb 2004 02:10:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwFfL-0000Tw-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 02:10:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwFeU-0000Kz-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 02:09:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwFdM-0000Dv-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 02:08:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFcp-00031T-2Z; Thu, 26 Feb 2004 02:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwFcC-0002ft-0K for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 02:07:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18377 for ; Thu, 26 Feb 2004 02:07:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwFc8-00006Y-00 for ipv6@ietf.org; Thu, 26 Feb 2004 02:07:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwFbD-00001I-00 for ipv6@ietf.org; Thu, 26 Feb 2004 02:06:23 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AwFaT-0007kR-00 for ipv6@ietf.org; Thu, 26 Feb 2004 02:05:37 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id C122315210; Thu, 26 Feb 2004 16:05:27 +0900 (JST) Date: Thu, 26 Feb 2004 16:05:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jari Arkko Cc: ipv6@ietf.org Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies In-Reply-To: <403B3272.4040202@kolumbus.fi> References: <200402241026.i1OAQtSj029701@givry.rennes.enst-bretagne.fr> <403B3272.4040202@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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Tue, 24 Feb 2004 13:16:02 +0200, >>>>> Jari Arkko said: >> So I really believe in the DAD usefulness and if you'd like to remove >> or "optimize" DAD on one of my networks my answer will be "NO!". > I believe the optimistic DAD folks are very keen on keeping the DAD > functional. That is, it is a requirement that networks and nodes must > be able to recover from a collision situation. No one is proposing > removing DAD. > Since most folks appear to agree that any optimization is not > a part of 2462bis and that Jinmei's option 1 is reasonable, I > think we can close the issue for 2462bis. > As for the rest, I believe we should discuss optimistic or optimized > DAD schemes under a different thread, since this really has nothing > to do with 2462bis. And for that discussion, let's not label someone's > method a priori as "removal". There may be specific concerns in the > specific methods, but if that's the case then they have to be > corrected or rejected. I totally agree with you, especially in the sense that whether optimistic DAD is good or not can/should be discussed separately from this particular issue for rfc2462bis. Thanks for the prudent clarification. 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 exim@www1.ietf.org Tue Mar 30 18:15:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27219 for ; Tue, 30 Mar 2004 18:15:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjT-0006WI-1B for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK8cTqT006612 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 03:38:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMkKS-0001iB-TV for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 03:38:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25278 for ; Thu, 20 Nov 2003 03:38:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMkKR-0006nN-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:38:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMkKP-0006nG-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 03:38:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMkJB-0001Dg-Qh; Thu, 20 Nov 2003 03:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMkIO-0001Az-EB for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 03:36:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25178 for ; Thu, 20 Nov 2003 03:35:59 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMkIM-0006kg-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:36:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMkIM-0006kd-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:36:10 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK8a9609414 for ; Thu, 20 Nov 2003 10:36:09 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Nov 2003 10:36:09 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 20 Nov 2003 10:36:09 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Node Req: Issue31: DHCPv6 text X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 20 Nov 2003 10:36:09 +0200 Message-ID: Thread-Topic: Issue 29: AD REVIEW: IPv6 Node Requirements Thread-Index: AcOux1B4G1HE4C0cQz2KBK0zYQ058QAeIsbAAABRquA= To: , X-OriginalArrivalTime: 20 Nov 2003 08:36:09.0223 (UTC) FILETIME=[58B0E970:01C3AF41] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, I forgot other text that Pekka suggested, here is all of the text: reword: For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. to: =20 Nodes that implement DHCPv6 MUST use DHCP upon the receipt of a=20 Router Advertisement with the 'M' flag set (see section 5.5.3 of=20 RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCPv6 MUST attempt to use DHCPv6. In this = context, 'use DHCP' means trying to obtain both address(es) and=20 other configuration information through DHCP. and: reword: For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. to: Nodes that implement DHCP MUST use DHCP upon the receipt of a=20 Router Advertisement with the 'M' flag set (see section 5.5.3 of=20 RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this=20 context, 'use DHCP' means trying to obtain both address(es) and=20 other configuration information through DHCP. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:15:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27246 for ; Tue, 30 Mar 2004 18:15:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006WI-VD for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NMbVXp002098 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 17:37:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOhf-0000Xl-Cb for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 17:37:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28096 for ; Mon, 23 Feb 2004 17:37:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOhc-0005a9-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 17:37:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvOgc-0005VH-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 17:36:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvOfi-0005RA-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 17:35:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOfH-0008QW-Do; Mon, 23 Feb 2004 17:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvOem-0008PO-6m for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 17:34:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28038 for ; Mon, 23 Feb 2004 17:34:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvOej-0005NL-00 for ipv6@ietf.org; Mon, 23 Feb 2004 17:34:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvOdp-0005KD-00 for ipv6@ietf.org; Mon, 23 Feb 2004 17:33:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AvOd0-0005Gn-00 for ipv6@ietf.org; Mon, 23 Feb 2004 17:32:42 -0500 Received: from [220.240.241.2] (helo=anchovy.zoic.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AvOcz-0004aL-Ab for ipv6@ietf.org; Mon, 23 Feb 2004 17:32:41 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 77A3A701E6E; Tue, 24 Feb 2004 09:27:08 +1100 (EST) Date: Tue, 24 Feb 2004 09:27:08 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: comments on draft-moore-ipv6-optimistic-dad-04.txt Message-ID: <20040223222707.GA29653@zoic.org> Mail-Followup-To: ipv6@ietf.org, "JINMEI Tatuya / ?$B?@L@C#:H" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-23, JINMEI Tatuya / ?$B?@L@C#:H wrote: > Here are comments on draft-moore-ipv6-optimistic-dad-04.txt. I have > one relatively-substantial comment and several editorial ones. Thanks heaps for your careful reading ... I won't comment on _all_ the editorial stuff here, but it's appreciated and I'll make sure the changes end up in the next draft. ----- > The relatively-substantial comment is: > I don't see the strong need for the unsolicited neighbor > advertisements described in Section 3.1: [...] > In particular, I don't understand why we SHOULD send the unsolicited > NA in the latter case. Yep. They're there to bootstrap the neighbour cache of the access router in the case of a predictive handover. But you're right, they should be MAYs and I need to add some text to explain why the mobile node would bother with the extra signalling. They could also be unicast to the AR or multicast to All-Routers rather than LL broadcast, I guess. Actually, since they're not generally applicable, maybe they shouldn't be in Opti-DAD at all, and I should leave it to those doing predictive handovers to say 'send an NA as soon as you can'. (Opti-DAD clause 3.2 (iii) still says O MUST= 0 though). > Well-Distributed Address - Address suffixes used for Optimistic DAD > should be well distributed, eg: there should be an equal > probability of any given suffix occuring. This minimizes the > probability of an address collision. > > I would say this is a requirement, not a definition. I'd also like > to point out "well distributed" is not really clear in a > definition, but this is probably a minor issue (I can live with the > wording). Yep, down in 3.3 (iii) the draft requires: | | * Otherwise, or when creating a new address in the case of a | collision, a well-distributed suffix MUST be chosen. ... and I was seeking to define "well-distributed" for those who hadn't heard the term. I've noted that I need to improve that definition. A lot :-). Earlier versions of the draft spoke of 'strongly random' generators, but I changed it in order to be explicitly compatible with SEND CGA, whose hash-generated suffixes are well-distributed but not at all random. > I guess MN stands for "mobile node" (see my first comment BTW), but I > don't see why we need to use this word here. As far as I can see, > there is nothing specific to a mobile node in this context. Yep, that's another artifact of my work with MobileIP, the terminology has crawled into my ear. I'll make sure I get rid of it all. > * (modifies 5.5) If an initial suffix is not supplied, a new suffix > SHOULD be generated as per "Address Generation" below. > > What does "initial suffix" mean? RFC2462 (or its bis) doesn't use > this wording. Ah, I need to reorder some bits of 3. It's a reference to 3.3 (ii). > What does "a fixed interface identifier" mean? (e.g.) An interface > identifier derived from a hardware address like EUI-64? FYI, > the latest rfc2462bis draft contains the following sentence in Section > 5.4.5: > > If the address is a link-local address > formed from an interface identifier based on the hardware address > (e.g., EUI-64), the interface SHOULD be disabled. I'll adopt that wording. > This is not very clear to me. What exactly does "a supposedly > globally unique" mean? For instance, is an EUI-64 based IPv6 address > supposedly globally unique? Yep, that's what I meant. I'll clarify it. > 9. In Section 3.3 [...] > Does more than once mean "two times or more" (the answer should be yes > in the literal sense)? If so, why don't we need a delay after the > first failure? It was my intention that if it failed once, it should be allowed to retry immediately, but if it fails again it should fall back to only trying every RETRANS_TIMER (since multiple failures are so astronomically unlikely that it's almost certainly DoS.) > 10. In Section 3.4 > > ... In order to minimize the probability of an undetected > address collision, it would seem prudent to always configure and > check the link-local address for any given suffix as well as checking > the actual address being configured. > > I'm not really sure what "the actual address" means. Do you mean "non > link-local address"? Yeah. I should be clearer there. > 11. In Section 4.2 > > ... An NA with O=0,S=0 and no LLAO may [Note 1], > however cause the NC entry to be set to STALE, causing NUD to be > performed on the address. > > Shouldn't the "no LLAO" really be "with LLAO"? If not, what is the > purpose of this NA (O=0,S=0, no LLAO)? Yes, you are right :-) NA(O=0,S=0,no LLAO) will do nothing! I've updated that. ----- Thanks again for all this input, I will followup soon with my proposed changes. This kind of debugging is exactly why I want Optimistic DAD to be looked at in this WG! -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:16:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27335 for ; Tue, 30 Mar 2004 18:16:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006Xa-UN for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACNnC5B012901 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 18:49:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4jY-0003M0-Lw for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 18:49:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17906 for ; Wed, 12 Nov 2003 18:48:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4jV-0001HG-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 18:49:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK4jV-0001HD-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 18:49:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4jN-0003Cp-1M; Wed, 12 Nov 2003 18:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4iP-0003BI-0t for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 18:48:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17851 for ; Wed, 12 Nov 2003 18:47:46 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4iL-0001Fp-00 for ipv6@ietf.org; Wed, 12 Nov 2003 18:47:57 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AK4iK-0001Fm-00 for ipv6@ietf.org; Wed, 12 Nov 2003 18:47:56 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACNluA12005 for ; Thu, 13 Nov 2003 01:47:56 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 01:47:55 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 01:47:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: comments on draft-hain-templin-ipv6-localcomm-03.txt Date: Thu, 13 Nov 2003 01:47:54 +0200 Message-ID: Thread-Topic: comments on draft-hain-templin-ipv6-localcomm-03.txt Thread-Index: AcOpdzNVrpUWY2P2S4+KgaTDvAvmqAAAAufQ To: Cc: X-OriginalArrivalTime: 12 Nov 2003 23:47:55.0402 (UTC) FILETIME=[64CF5EA0:01C3A977] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Keith, > it would really seem odd to me to use a "local address" to talk to a=20 > host that is halfway across the world. I read my local paper (from West Caldwell, NJ) on line at work (Helsinki, Finland). I still call it my local paper ... John > that, and I'm concerned that people will think that "local" means, or=20 > is intended for, only the portion of the network that uses that same=20 > prefix - and/or that it's reasonable to expect traffic to be filtered=20 > at the edges of that portion of the network. >=20 >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:16:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27360 for ; Tue, 30 Mar 2004 18:16:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006WI-TA for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACK7fAH022414 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:07:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1HA-0005nO-Nm for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:07:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05315 for ; Wed, 12 Nov 2003 15:07:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1Gr-0004zR-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:07:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1Gq-0004zN-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:07:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1GZ-0005Yl-MB; Wed, 12 Nov 2003 15:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1GU-0005XS-Lj for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 15:06:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05241 for ; Wed, 12 Nov 2003 15:06:45 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1GR-0004yI-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:06:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AK1GQ-0004yD-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:06:55 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACK6r621334 for ; Wed, 12 Nov 2003 22:06:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 22:06:53 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 22:06:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Date: Wed, 12 Nov 2003 22:06:53 +0200 Message-ID: Thread-Topic: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt Thread-Index: AcOpV6ji5VbA3+nySqesm8hDZA0AtgAAMoQQ To: , X-OriginalArrivalTime: 12 Nov 2003 20:06:53.0526 (UTC) FILETIME=[841DAF60:01C3A958] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Christian, > The section "5.4.5 When Duplicate Address Detection Fails" currently > says: >=20 > A tentative address that is determined to be a duplicate as = described > above, MUST NOT be assigned to an interface and the node SHOULD log = a > system management error. If the address is a link-local address > formed from an interface identifier, the interface SHOULD be > disabled. >=20 > The part about disabling the interface enables a DOS attack: wait for = a > target to come on line and send a DAD packet, reply with a deliberate > collision, and poof the target is disconnected from the network.=20 >=20 > Proposed resolution: write "MAY be disabled" instead. I strongly agree, for the reasons you give. John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:16:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27389 for ; Tue, 30 Mar 2004 18:16:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006Xa-SF for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QLPxW8020866 for ipv6-archive@odin.ietf.org; Thu, 26 Feb 2004 16:25:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwT15-0005QT-2X for ipv6-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 16:25:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10075 for ; Thu, 26 Feb 2004 16:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwT13-0007ZP-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 16:25:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwT07-0007OR-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 16:25:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwSzG-0007HI-00 for ipv6-web-archive@ietf.org; Thu, 26 Feb 2004 16:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwSym-0004PA-IG; Thu, 26 Feb 2004 16:23:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRr2-0005kt-Vw for ipv6@optimus.ietf.org; Thu, 26 Feb 2004 15:11:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07151 for ; Thu, 26 Feb 2004 15:11:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRqx-0007WC-00 for ipv6@ietf.org; Thu, 26 Feb 2004 15:11:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRpo-0007If-00 for ipv6@ietf.org; Thu, 26 Feb 2004 15:10:16 -0500 Received: from dsl-2.241.240.220.dsl.comindico.com.au ([220.240.241.2] helo=anchovy.zoic.org) by ietf-mx with esmtp (Exim 4.12) id 1AwRol-00074Q-00 for ipv6@ietf.org; Thu, 26 Feb 2004 15:09:12 -0500 Received: by anchovy.zoic.org (Postfix, from userid 1000) id 77A5F70C3F0; Fri, 27 Feb 2004 07:09:02 +1100 (EST) Date: Fri, 27 Feb 2004 07:09:02 +1100 From: "Nick 'Sharkey' Moore" To: ipv6@ietf.org Cc: Markku Savela Subject: Re: [rfc2462bis issue 275] DAD text inconsistencies Message-ID: <20040226200901.GB23217@zoic.org> Mail-Followup-To: ipv6@ietf.org, Markku Savela References: <200402260946.i1Q9kwo8006390@burp.tkv.asdf.org> <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402261325.i1QDPDcR008250@burp.tkv.asdf.org> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 On 2004-02-26, Markku Savela wrote: > > Yes, DIID probably (or something similar). I believe that simplest > solution is that a specific ID value can be allowed only for single > node on the link. Any use of same ID part with any prefix by another > node should be viewed as an address collision. I can see where you are coming from: for DAD to safely interoperate with DIID it must send even more messages: wouldn't it be nice to just send a single NS/NA pair? After all, DIID is already compatible with DIID. I'm convinced that a change needs to be made to the wording to resolve this issue, but I'm not sure which is the better option. I'm also dubious about relying on votes at IETF meetings for technical issues ... because often an option which seems 'obvious' at the time actually isn't once the drafts have been considered in detail. And most of the WG attendees won't have considered them in detail before the meeting. Sad but true. Questions for the group: * DIID offers less signalling. What advantages does DAD offer? * Does DAD retain these advantages when made compatible with DIID? (by testing/defending LL::X, as per my earlier suggestion) * Can backwards compatibility be dispensed with? (I'm going to be a hard sell on that one ...) To be honest, unless there's some advantage to DAD which I haven't thought of, I'm starting to lean back towards DIID ... although since I'm keen on crypto and privacy addresses, I guess that's really Duplicate Suffix Detection (DSD), eh? -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:16:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27544 for ; Tue, 30 Mar 2004 18:16:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006ZK-MB for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MKBQeY002900 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 15:11:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VlK-0000i0-0Z for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 15:11:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16812 for ; Mon, 22 Mar 2004 15:10:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Vl7-00048r-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 15:10:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5VkI-00040Q-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 15:10:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5VjQ-0003rX-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 15:09:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Vgp-0006lX-DX; Mon, 22 Mar 2004 15:06:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VgA-0006T5-Se for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 15:05:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16099 for ; Mon, 22 Mar 2004 15:05:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Vg7-0003OW-00 for ipv6@ietf.org; Mon, 22 Mar 2004 15:05:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5VfH-0003IN-00 for ipv6@ietf.org; Mon, 22 Mar 2004 15:04:52 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1B5Veb-00038C-00 for ipv6@ietf.org; Mon, 22 Mar 2004 15:04:09 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2MK3bWA010204; Mon, 22 Mar 2004 12:03:38 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2MK3ZQ21139; Mon, 22 Mar 2004 21:03:35 +0100 (MET) Date: Mon, 22 Mar 2004 12:03:35 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: rfc2462bis: new section 5.7 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 > Good point, thanks. How about changing the first sentence of Section > 5.7 as follows? > > It is reasonable that implementations that have stable storage retain > their addresses and the expiration times of the preferred and valid > lifetimes if the addresses were acquired using stateless address > autoconfiguration. ok > Meanwhile, I have more fundamental questions: > > 1. it is probably not adequate to describe this in the body of > rfc2462bis, since it's a kind of extension, not a bug fix or a > clarification to the existing specification. Shouldn't we rather > move this section to appendix entitled (e.g.) "future possible > extensions"? Or should we describe this in rfc2462bis in the first > place? I myself do not have a particular preference, but if we > cannot reach consensus, I'd rather remove this section from > rfc2462bis. I understand your concern. Given that there are some implementations that store the prefix in a file there is a risk (and perhaps even implementations) that do not retain the lifetimes together with the prefix I think we should at least add a clarification that if the prefix is retained in stable storage in such a way that it might remain in stable storage after the lifetimes might have expired, the end of lifetimes must also be retauned in stable storage. Thus I agree that the extension to suggest that implementations retrain the prefix doesn't belong, but given that some implementations already do having the warning about the lifetimes makes sense. > 2. this extension may conflict with the rule that "if no router > exists, then stateful configuration MUST be performed" (though we > are now discussing the requirement level on this). Assuming the > current requirement level, should we also describe the relationship > (or ordering) between the two alternatives? For example, should we > require that this extension (i.e., retaining the address) be used > only after the attempt of stateful address configuration fails? If we take your suggestion that the extension is out of scope for the clarifications then we can defer this issue to a separate draft. That of course doesn't answer your technical question. I think the answer to the technical question lies in the DNA world. If you can detect that you are still connected to the same link it would be ok (when the lifetimes haven't expired) to verify and continue to use the old configuration. But the question is whether DNA can easily verify it is attached to the same link when there is not a router - the schemes proposed so far seem to assume a router (and/or a dhcp agent if stateful is used) just to do the verification that you are on the same link as before. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:16:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27575 for ; Tue, 30 Mar 2004 18:16:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006ZK-OY for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJElJHa024212 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 09:47:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTby-0006IK-Ni for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 09:47:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18399 for ; Wed, 19 Nov 2003 09:47:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTbu-0000JE-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 09:47:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMTbr-0000J9-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 09:47:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTbh-00064a-Oi; Wed, 19 Nov 2003 09:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTbW-00064B-R3 for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 09:46:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18384 for ; Wed, 19 Nov 2003 09:46:36 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTbU-0000IW-00 for ipv6@ietf.org; Wed, 19 Nov 2003 09:46:49 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMTbU-0000IS-00 for ipv6@ietf.org; Wed, 19 Nov 2003 09:46:48 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJEkkA24970 for ; Wed, 19 Nov 2003 16:46:46 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Nov 2003 16:46:46 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Nov 2003 16:46:46 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Node Req. Issue 28: Security Considerations X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 19 Nov 2003 16:46:46 +0200 Message-ID: Thread-Topic: Issue 19 of draft-ietf-ipv6-node-requirements-05.txt Thread-Index: AcOup/5qFKL//MLsR4KLp78xAZaZSgAAmcKwAABLzgA= To: X-OriginalArrivalTime: 19 Nov 2003 14:46:46.0546 (UTC) FILETIME=[F4C15F20:01C3AEAB] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Margaret asked 2 points: 11. Security Considerations >> In the IPsec section, you mention that other security issues >> will be covered in the Security Considerations section, but >> I don't see any issues here... =20 >> >> Why aren't privacy addresses covered in this document? Should this be covered in the security section? Already, section 4.5.3 talks about privacy extensions. Do we need more? 4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] SHOULD be supported. It is recommended that this behavior be configurable on a connection basis within each application when available. It is noted that a number of applications do not work with addresses generated with this method, while other applications work quite well with them. >> Also, did you consider a recommendation that IPv6 nodes should >> implement SEND? Perhaps you should at least mention the=20 >> security issues with ND and indicate that the SEND group is >> working to resolve them? I believe we did not want this kind of forward reference to stuff that is on-going. However, if people feel that the SEND stuff is stable enough, we could put in a reference. thanks, John -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:17:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27682 for ; Tue, 30 Mar 2004 18:17:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006WI-Fp for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4MbDqo015018 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 17:37:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9nU-0003tz-8s for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 17:37:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09260 for ; Tue, 4 Nov 2003 17:36:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9nR-00070z-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:37:09 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH9nR-00070w-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 17:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9nJ-0003ih-Vk; Tue, 04 Nov 2003 17:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9mr-0003iA-7Q for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 17:36:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09253 for ; Tue, 4 Nov 2003 17:36:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9mo-00070X-00 for ipv6@ietf.org; Tue, 04 Nov 2003 17:36:30 -0500 Received: from alicia.nttmcl.com ([216.69.69.10]) by ietf-mx with esmtp (Exim 4.12) id 1AH9mo-00070S-00 for ipv6@ietf.org; Tue, 04 Nov 2003 17:36:30 -0500 Received: from nttmcl.com (daal.nttmcl.com [216.69.69.11]) by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id hA4MZwHB085716; Tue, 4 Nov 2003 14:35:59 -0800 (PST) (envelope-from gene@nttmcl.com) Message-ID: <3FA829CB.3020801@nttmcl.com> Date: Tue, 04 Nov 2003 14:35:55 -0800 From: "Eugene M. Kim" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en, ko-kr, ko MIME-Version: 1.0 To: "Eugene M. Kim" CC: Keith Moore , ipv6@ietf.org Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG) References: <20031103083650.67297afd.moore@cs.utk.edu> <20031103151626.GB21430@sverresborg.uninett.no> <20031103104202.08e7a1a3.moore@cs.utk.edu> <20031103170605.GA24355@castlerea.stdlib.net.> <20031103162255.61563fcb.moore@cs.utk.edu> <20031104085701.X37922@mignon.ki.iif.hu> <20031104073514.61046c34.moore@cs.utk.edu> <3FA7F703.3060904@nttmcl.com> <20031104141639.1c9d1d56.moore@cs.utk.edu> <3FA824FD.2040807@nttmcl.com> In-Reply-To: <3FA824FD.2040807@nttmcl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eugene M. Kim wrote: > But the fact that applications are doing a wrong thing means we can > just ignore them as if they weren't there. Oh God. s/means/doesn't mean/ *blush* Eugene -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:17:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27710 for ; Tue, 30 Mar 2004 18:17:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006a4-8l for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJbxAs015154 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 14:37:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHrI-0003wB-G6 for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 14:37:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07964 for ; Mon, 10 Nov 2003 14:37:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHrF-00032P-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 14:37:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJHrF-00032M-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 14:37:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHqQ-0003QF-MG; Mon, 10 Nov 2003 14:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHph-0003Mh-Vp for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 14:36:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07830 for ; Mon, 10 Nov 2003 14:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHpd-0002ze-00 for ipv6@ietf.org; Mon, 10 Nov 2003 14:36:13 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AJHpc-0002zV-00 for ipv6@ietf.org; Mon, 10 Nov 2003 14:36:12 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAAJaB5u015843 for ; Mon, 10 Nov 2003 12:36:11 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HO5007W0IGBM4@edgemail1.Central.Sun.COM> for ipv6@ietf.org; Mon, 10 Nov 2003 12:36:11 -0700 (MST) Received: from sun.com ([129.146.11.166]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HO50094AIGAQH@mail.sun.net> for ipv6@ietf.org; Mon, 10 Nov 2003 12:36:11 -0700 (MST) Date: Mon, 10 Nov 2003 11:36:10 -0800 From: Alain Durand Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" To: Bob Hinden Cc: Geoff Huston , ipv6@ietf.org Message-id: <3FAFE8AA.6010009@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <4.3.2.7.2.20031110104020.03642440@mailhost.iprg.nokia.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT I think that if you were to drop entirely the randomly self generated addresses and do not say anything about the fee scruture except it has to be low cost, it would be a much more swallable pill. - Alain. Bob Hinden wrote: > Geoff, > >> After thinking about this and looking at the evident need to make >> some progress >> here I'd like to believe that this level of resolution of potential >> ambiguity >> is adequate, given that there is always the option to use a central >> registry draw to >> obtain a global id that is assuredly unique. >> >> My other issues with the current rev of the draft are still on the >> table, and of course >> I'd be happy to work with the authors to come up with some revised >> words that may find >> some reasonable (rough) wg consensus, and still remain within the >> overall spirit >> and intent of this proposal. > > > Thanks. That would be very helpful. I will contact you off list and > see if we can get together to come with some wording that could be > presented to the w.g. during the Thursday session. > > Bob > > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Tue Mar 30 18:17:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27740 for ; Tue, 30 Mar 2004 18:17:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006WI-3w for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M6ihQd005401 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 02:44:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCjZ-0001P2-7E for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 02:44:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26470 for ; Wed, 22 Oct 2003 02:44:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACCjV-00015i-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 02:44:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACCjV-00015f-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 02:44:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCiv-00015E-HC; Wed, 22 Oct 2003 02:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCi2-0000mx-ON for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 02:43:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26453 for ; Wed, 22 Oct 2003 02:42:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACChy-00014c-00 for ipv6@ietf.org; Wed, 22 Oct 2003 02:43:02 -0400 Received: from batch16.uni-muenster.de ([128.176.188.114]) by ietf-mx with esmtp (Exim 4.12) id 1ACChx-00014Z-00 for ipv6@ietf.org; Wed, 22 Oct 2003 02:43:02 -0400 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch16.uni-muenster.de (Postfix) with ESMTP id D6BB61122; Wed, 22 Oct 2003 08:42:21 +0200 (MES) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 1BCE1312D7; Wed, 22 Oct 2003 08:42:21 +0200 (CEST) Received: from kummerog.uni-muenster.de (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 5FB4D312E4; Wed, 22 Oct 2003 08:42:20 +0200 (CEST) Subject: Re: IPv6 adoption behavior From: "Christian Strauf (JOIN)" To: Tim Chown Cc: ipv6@ietf.org In-Reply-To: <20031021143041.GM27817@login.ecs.soton.ac.uk> References: <20031021143041.GM27817@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=iso-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1066804980.9292.23.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 22 Oct 2003 08:43:00 +0200 X-Virus-Scanned: by AMaViS 0.3.12pre7 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA26454 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > But if I want a VoIP communication from me (behind a NAT) to some user=20 > behind a NAT, not using a 3rd party "location" server, how does v4 deli= ver,=20 > without the receiving user having the pain of port forwarding configura= tion=20 > on their NAT? Good point. I experienced that end-users in the GnomeMeeting (H.323 client) community that never had anything to do with v6 suddenly started asking questions about how to get IPv6 connectivity because they heard that even as a normal end user you can get a /64 from tunnel brokers or your ISP (in some cases) which solves the end-to-end connectivity problem that exists with IPv4+NAT because you can get a global v6 address. IPv4+NAT problems are the most common problems in this community. 80% of all problems that people have with GnomeMeeting can be traced back to a NAT. What I'm trying to say is that there are applications that can raise a demand for IPv6 due to easier to achieve end-to-end connectivity. And Skype is not a good example for end-to-end communication "over NAT" because it wouldn't work without non-NAT-ed nodes. > How do I do the same in v4 where I want end-to-end encryption on the=20 > application? Another good example for a field where end-users will eventually realise the use of IPv6 w/o NAT vs. IPv4 w/ NAT. The point is: there are a good number of everyday applications where end-users are painfully reminded that they live behind a NAT. And those users would definitely appreciate getting rid of IPv4+NAT if they can achieve what they want with IPv6. In this case, the adoption of IPv6 is simply a logical consequence. Christian --=20 JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westf=E4lische Wilhelms-Universit=E4t M=FC= nster http://www.join.uni-muenster.de Zentrum f=FCr Informationsverarbeitung Team: join@uni-muenster.de R=F6ntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 M=FCnster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31= 653 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:17:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27783 for ; Tue, 30 Mar 2004 18:17:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006WI-DV for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i218Uawc001840 for ipv6-archive@odin.ietf.org; Mon, 1 Mar 2004 03:30:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxikS-0007oL-Bf for ipv6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 03:26:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01554 for ; Mon, 1 Mar 2004 03:25:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxikB-00054o-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 03:25:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxijH-0004xD-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 03:24:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxiiW-0004pn-00 for ipv6-web-archive@ietf.org; Mon, 01 Mar 2004 03:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigv-0006Qq-KQ; Mon, 01 Mar 2004 03:22:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axify-0006Ht-Ft for ipv6@optimus.ietf.org; Mon, 01 Mar 2004 03:21:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01105 for ; Mon, 1 Mar 2004 03:21:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiWM-0003eO-00 for ipv6@ietf.org; Mon, 01 Mar 2004 03:11:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiVO-0003XM-00 for ipv6@ietf.org; Mon, 01 Mar 2004 03:10:26 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AxiUP-0003OF-00 for ipv6@ietf.org; Mon, 01 Mar 2004 03:09:25 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2188sdO005340; Mon, 1 Mar 2004 00:08:55 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2188oQ01009; Mon, 1 Mar 2004 09:08:50 +0100 (MET) Date: Mon, 1 Mar 2004 00:08:54 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: additional agenda item To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > Fair enough, but let me make a quick check: is this a direct response > to my request for a slot (positive or negative), or just a general > input on this issue itself? Latter. On the former; Getting the API for the list of addresses documented seems quite useful so I think it makes sense spending face time on this. > u_int ifa_flags; /* Interface flags */ Aren't the flags implementation specific? > The ifa_data field references address family specific data. For AF_LINK > addresses it contains a pointer to the struct if_data (as defined in > include file ) which contains various interface attributes and > statistics. For all other address families, it contains a pointer to > the struct ifa_data (as defined in include file ) which > contains per-address interface statistics. The actual statistics that are provided might be implementation specific. Do we want an API that can be provided for non-BSD IP stacks? Windows? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:17:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27836 for ; Tue, 30 Mar 2004 18:17:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006ZK-B8 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RM8msM007686 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 17:08:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwqA2-0001zn-5v for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 17:08:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27652 for ; Fri, 27 Feb 2004 17:08:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwqA0-0005dH-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 17:08:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awq97-0005Vr-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 17:07:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awq8L-0005P8-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 17:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq8M-0001Cq-7f; Fri, 27 Feb 2004 17:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq7u-00015s-Uz for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 17:06:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27501 for ; Fri, 27 Feb 2004 17:06:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awq7s-0005M3-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:06:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awq6u-0005FW-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:05:32 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1Awq5v-00055O-00 for ipv6@ietf.org; Fri, 27 Feb 2004 17:04:31 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1RM3xdO020084; Fri, 27 Feb 2004 14:04:00 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i1RM3vQ10927; Fri, 27 Feb 2004 23:03:57 +0100 (MET) Date: Fri, 27 Feb 2004 13:47:35 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipv6@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > Which one is correct? Is the length of IF IDs determined by the link > type, or the address format, or both? If the answer is "both", there > may be inconsistency in future specification. For example, what if a > future IPv6-over-FOO document specifies like this? > > An IPv6 address prefix used for stateless autoconfiguration [ACONF] > of a FOO interface must have a length of 80 bits. > > Will we then have to give up using stateless address autoconfiguration > with unicast prefixes beginning with "000" in this link? I think you meant "unless the unicast prefix begins with 000 ..." > Technically, this is not necessary a contradiction. [IPv6-ETHER] only > requires 64-bit IF IDs for stateless address autoconfiguration, so the > above (imaginary) IPv6-over-FOO document and the addr-arch document > can coexist without conflicting each other if we give up stateless > autoconfiguration in this link. But is this a realistic option? I personally think we should hard-code the /64 boundary in as few places as possible to allow for future evolution. Your 80 bit interface ID on some new links is one example of possible future evolution. Another example is cases where 20 years from now having less than 64 bit interface IDs (or addresses allocated with DHCP from a >64 bit subnet prefix) might fill a useful role. Hard-coding the /64 address too me sounds like the original Arpanet design with 8 bit network numbers and 24 bit host numbers; which was revised/relaxed first with class A/B/C and later with CIDR. I don't know of a technical reason why /64 needs to be a hard limit. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:18:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27896 for ; Tue, 30 Mar 2004 18:18:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006a4-0g for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ME7cX2018944 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 09:07:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Q5Z-0004vL-R5 for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 09:07:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25485 for ; Mon, 22 Mar 2004 09:07:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Q5Y-0005dY-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 09:07:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Q4V-0005QV-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 09:06:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Q3R-0005DV-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 09:05:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Q34-0003ro-6z; Mon, 22 Mar 2004 09:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Lr9-0007h7-H1 for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 04:36:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12159 for ; Mon, 22 Mar 2004 04:36:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Lr6-0005hs-00 for ipv6@ietf.org; Mon, 22 Mar 2004 04:36:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Lq9-0005au-00 for ipv6@ietf.org; Mon, 22 Mar 2004 04:35:26 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx with esmtp (Exim 4.12) id 1B5LpR-0005V4-00 for ipv6@ietf.org; Mon, 22 Mar 2004 04:34:41 -0500 Received: from sokol.elan.net (localhost.localdomain [127.0.0.1]) by sokol.elan.net (8.12.5/8.12.5) with ESMTP id i2MAg2dw015472; Mon, 22 Mar 2004 02:42:02 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.12.5/8.12.5/Submit) with ESMTP id i2MAg2FS015468; Mon, 22 Mar 2004 02:42:02 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 22 Mar 2004 02:42:02 -0800 (PST) From: "william(at)elan.net" To: Stephen Sprunk cc: Bill Manning , IETF IPv6 WG , ARIN Policy Subject: Re: [ppml] Re: ASN-based prefixes for leaf ASes In-Reply-To: <004f01c40feb$eff3ccc0$6401a8c0@ssprunk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 22 Mar 2004, Stephen Sprunk wrote: > Thus spake "Stephen Sprunk" > > I agree and invite input from ARIN members. NOTE: Please include in your > > comments whether you're a leaf or non-leaf AS. > > I forgot that PPML wasn't copied on the original message... To clarify: > > My proposal was that automatic /48 allocations be made to anyone with an > ASN, based on the premise that every AS will advertise at least one PI > block. If I remember right /48 is not a PI block (or rather it may not be within ARIN region which uses different terminology), /48 are expected to be allocated by ISPs (LIRs) to customers with their own network (rather when its individual device and then its /64) but its provider-dependent (i.e. PA) as far as its being assigned by ISP where as PI would be micro-allocation directly by RIR Now if you compare the policies for IPv4 ARIN does have a policy that multihoming (i.e. = has ASN) is an automatic justification for /24 from one of the upstreams. Its not unreasonable to expect this to be extended to IPv6 and say that multihoming is justification for /48 from one of the upstreams or from RIR - however saying that is redundant as running independent network with multiple devices is already justification for /48 from the LIR or upstream no matter if network it is multihomed or not :) Now as far as assigning /48 for every ASN, lets not do it just yet - some ASNs may need larger blocks then just /48 and besides that there are way too many ASNs out there that are not used at all (getting close to 50%) and for those that are used some are used for special network preferences by the same provider that may not need separate /48. So just having ASN out in whois does not mean they really need an /48 - that ASN holder must actually ask for it! However, what I would be for is allowing for micro-allocations from ARIN (and this can/should be larger then /48 probably) so as to boostart use of IPv6. Currently if ASN holder is not a member of ARIN, they should request ip block from their ISP or become member of ARIN and pay for that IPv6 block $2500/year, I think we should allow for companies with ASN to be able to directly request IPv6 space from ARIN (micro-allocation) if their ISP does not have yet have IPv6 space and that "ipv6 startup micro-allocations" should cost less then regular full ipv6 blocks - possibly no extra money if they are already paying yearly maintanance fee of $100/yr for ASN). -- William Leibzon Elan Networks william@elan.net -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:18:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28031 for ; Tue, 30 Mar 2004 18:18:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjR-0006WI-W6 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJEjPFS023001 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 09:45:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTa8-0005yc-1V for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 09:45:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18319 for ; Wed, 19 Nov 2003 09:45:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTa4-0000EW-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 09:45:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMTa3-0000ET-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 09:45:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTZm-0005l3-A4; Wed, 19 Nov 2003 09:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTYr-0005iQ-E6 for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 09:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18280 for ; Wed, 19 Nov 2003 09:43:51 -0500 (EST) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTYp-0000DB-00 for ipv6@ietf.org; Wed, 19 Nov 2003 09:44:03 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMTYo-0000Cq-00 for ipv6@ietf.org; Wed, 19 Nov 2003 09:44:02 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJEhx606967 for ; Wed, 19 Nov 2003 16:43:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Nov 2003 16:43:58 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 16:43:59 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Issue 29: AD REVIEW: IPv6 Node Requirements X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 19 Nov 2003 16:43:59 +0200 Message-ID: Thread-Topic: Issue 29: AD REVIEW: IPv6 Node Requirements Thread-Index: AcOuq5DpFeDeRv59T7WBgzHdITs9fA== To: X-OriginalArrivalTime: 19 Nov 2003 14:43:59.0622 (UTC) FILETIME=[9142CA60:01C3AEAB] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable NITS, my comments preceded by : As it is not always possible for an implementer to know the exact usage of IPv6 in a node, an overriding requirement for IPv6 nodes is that they should adhere to John Postel's Robustness Principle: Be conservative in what you do, be liberal in what you accept from others. [RFC-793]. >> s/John Postel/Jon Postel/ ack. >> General comment: The organization of this document is a bit >> awkward. It would probably read better to start with the >> IP layer and put the Sub-IP Layer at the end. recommendation, no change. 3. Sub-IP Layer An IPv6 node must follow the RFC related to the link-layer that is sending packets. By definition, these specifications are required based upon what layer-2 is used. In general, it is reasonable to be a conformant IPv6 node and NOT support some legacy interfaces. >> It is not clear to me what this paragraph is trying to indicate. >> Perhaps: >> An IPv6 node must include support for one or more IPv6 link-layer >> specifications. Which link-layer specifications are included=20 >> will depend upon what link-layers are supported by the hardware >> available on the system. It is possible for a conformant IPv6 >> node to support IPv6 on some of its interfaces and not on others. proposed text is good. The capability of being a final destination MUST be supported, whereas the capability of being an intermediate destination MAY be supported (i.e. - host functionality vs. router functionality). >> Is there a reason for this particular wording? "Intermediate=20 >> destination" is not a term that I'm familiar with. Perhaps >> this could be better said: "All conformant IPv6 implementations >> MUST be capable of sending and receving IPv6 packets; forwarding >> functionality MAY be supported"? Or are you trying to say more >> here? proposed text is good. 4.5 Addressing Currently, there is discussion on support for site-local addressing. >> Either say more or leave this out? When published as an RFC, this >> document will live long term, so the word "currently" is a bit >> vague. Since we are deprecating site-local, I think that you >> could just omit any mention of it. proposal is good. 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 If an application is going to join any-source multicast group addresses, it SHOULD implement MLDv1. When MLD is used, the rules in "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be followed. >> If I understand correctly, these nodes could support either >> MLDv1 or MLDv2. MLDv2 includes MLDv1 functionality, no change needed. 5.1 Transport Layer 5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 This specification MUST be supported if jumbograms are implemented [RFC-2675]. One open issue is if this document needs to be updated, as it refers to an obsoleted document. >> An open issue for whom? I wouldn't include open issues for >> other documents in this document. Remove open issue text. Format for Literal IPv6 Addresses in URL's" [RFC-2732] MUST be supported if applications on the node use URL's. >> s/Format/"Format/ ?? 5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 RFC 2732 MUST be supported if applications on the node use URL's. >> This is redundant with the last line of the previous section. deleted last line of previous section. 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 >> I think that you should be explicit, throughout this section, >> that you are talking about DHCPv6. In other words, replace >> all occurances of DHCP with DHCPv6. It is possible that nodes >> may implement DHCP(v4), but not DHCPv6. Thought that would go without saying, but I'll be explicit noone=20 gets confused. 10.1 Management Information Base Modules (MIBs) =20 The following two MIBs SHOULD be supported MIBs by nodes that support an SNMP agent. >> s/supported MIBs by/supported by/ ok -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:19:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28390 for ; Tue, 30 Mar 2004 18:19:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjR-0006a4-GG for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B8VMgj018656 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 03:31:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Lb7-0004qn-G0 for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 03:31:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19070 for ; Thu, 11 Mar 2004 03:31:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Lb5-0006oa-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 03:31:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1La6-0006eJ-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 03:30:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1LZC-0006Vt-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 03:29:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1LYv-0002nk-9n; Thu, 11 Mar 2004 03:29:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1LYH-0001gO-1L for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 03:28:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18994 for ; Thu, 11 Mar 2004 03:28:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1LYE-0006O7-00 for ipv6@ietf.org; Thu, 11 Mar 2004 03:28:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1LXL-0006Fy-00 for ipv6@ietf.org; Thu, 11 Mar 2004 03:27:28 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B1LWc-00067q-00 for ipv6@ietf.org; Thu, 11 Mar 2004 03:26:42 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 813FD8996E; Thu, 11 Mar 2004 10:26:41 +0200 (EET) Message-ID: <4050223B.7050301@kolumbus.fi> Date: Thu, 11 Mar 2004 10:24:27 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham Cc: "Mattias Pettersson L (KI/EAB)" , ipv6@ietf.org Subject: Re: Multiple DRs on a link References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hesham, > => I think even the nodes that implement 3484 may make the > wrong decision. The text that Alper sent is not "standards text" > and I suspect there are implementations (e.g. BSD) that don't > follow this. Right. > > But I have a question about the NEMO case. I had assumed that mobile > > routers move around and attach their egress interface to various > > place in the internet. And that their ingress interface serves > > a number of hosts, unaware of the movements. I don't see the > > default router selection as an issue in this scenario, as the > > hosts will stick to the same mobile router all the time, and > > the mobile router acts like a host on its egress interface. So > > if the visited link works for hosts, it should work for mobile > > routers. > > => The problem is when you have 2 MRs, each advertising a different > prefix (i.e. different home prefix). They are advertising a different prefix on the _ingress_ interface, and the two MRs both use the _same_ ingress interface? Is it the same because it was configured to do so, as in somehow load- balancing/fault-tolerant MR configuration? Or because their ingress links happened to randomly merge, or the incapability of the link layer to keep the two MRs on different links? --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:20:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28788 for ; Tue, 30 Mar 2004 18:20:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006Zv-RF for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N9vA15030132 for ipv6-archive@odin.ietf.org; Mon, 23 Feb 2004 04:57:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvCpl-0007pc-4m for ipv6-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 04:57:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16253 for ; Mon, 23 Feb 2004 04:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvCpi-0002sE-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 04:57:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvCok-0002pD-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 04:56:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvCoD-0002mm-00 for ipv6-web-archive@ietf.org; Mon, 23 Feb 2004 04:55:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvCno-0007XB-Jj; Mon, 23 Feb 2004 04:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvCmr-0007Ux-0f for ipv6@optimus.ietf.org; Mon, 23 Feb 2004 04:54:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16213 for ; Mon, 23 Feb 2004 04:54:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvCmn-0002j0-00 for ipv6@ietf.org; Mon, 23 Feb 2004 04:54:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvClr-0002fF-00 for ipv6@ietf.org; Mon, 23 Feb 2004 04:53:03 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AvCky-0002cb-00 for ipv6@ietf.org; Mon, 23 Feb 2004 04:52:09 -0500 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4043015210; Mon, 23 Feb 2004 18:52:08 +0900 (JST) Date: Mon, 23 Feb 2004 18:52:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Nick 'Sharkey' Moore" Cc: ipv6@ietf.org Subject: Re: Optimistic DAD _again!_ In-Reply-To: <20040219085228.GA22803@zoic.org> References: <20040219085228.GA22803@zoic.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Thu, 19 Feb 2004 19:52:28 +1100, >>>>> "Nick 'Sharkey' Moore" said: > You might recall some time ago I stirred up some interest > in my Optimistic DAD draft, which seeks to eliminate DAD delay > without significantly increasing the risk involved in address > collision. In the meantime it's picked up a couple of independant > implementations[1] and a couple of conference publications[2]. (snip) > Please let me know what you think ... and if there's enough > interest maybe we can discuss it further at Seoul. I'd like to know if there has been a consensus to pursue any sort of DAD optimization in the first place. There have surely been lots of discussions related to this issue, and, as far as I can recall, the idea of optimization has never been adopted. One fundamental question that I remember is whether optimizing DAD really makes much sense while there are other kinds of delays such as random delay (up to 1 second) for the first RS and random delay at routers before responding to an RS. Without addressing the fundamental question(s), we'd simply restart similar divergent discussions, waisting lots of energy and time without seeing progress. p.s. I've read the latest draft and have some (mainly editorial) comments. I'll post the comments in a separate message. 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 exim@www1.ietf.org Tue Mar 30 18:20:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28791 for ; Tue, 30 Mar 2004 18:20:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006Zv-HS for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16BdlM0021499 for ipv6-archive@odin.ietf.org; Fri, 6 Feb 2004 06:39:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4Kp-0005ag-8j for ipv6-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 06:39:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21489 for ; Fri, 6 Feb 2004 06:39:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Kl-0005dd-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:39:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap4Jq-0005ZL-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:38:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4J8-0005Vp-00 for ipv6-web-archive@ietf.org; Fri, 06 Feb 2004 06:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4JB-0004z3-1b; Fri, 06 Feb 2004 06:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap4Io-0004n9-1k for ipv6@optimus.ietf.org; Fri, 06 Feb 2004 06:37:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21366 for ; Fri, 6 Feb 2004 06:37:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4Ik-0005U3-00 for ipv6@ietf.org; Fri, 06 Feb 2004 06:37:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap4Hp-0005RZ-00 for ipv6@ietf.org; Fri, 06 Feb 2004 06:36:42 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Ap4HF-0005PB-00 for ipv6@ietf.org; Fri, 06 Feb 2004 06:36:05 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 90E996A905; Fri, 6 Feb 2004 13:36:00 +0200 (EET) Message-ID: <40237BBF.5060701@kolumbus.fi> Date: Fri, 06 Feb 2004 13:34:23 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JINMEI Tatuya Cc: ipv6@ietf.org, Erik Nordmark Subject: Re: [rfc2462bis issue 271] retaining addresses in stable storage References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit JINMEI Tatuya wrote: > To address rfc2462bis issue 271, "An implementation may want to use > stable storage for autoconfigured addresses", I've added the following > new (sub)section: > > ================================================================ > 5.7 Retaining Configured Addresses for Stability > > It is reasoanble that implementations that have stable storage retain nit: reasonable > their addresses and the preferred and valid lifetimes if the > addresses were acquired using the stateless address > autoconfiguration. Assuming the lifetimes used are reasonable, this > technique implies that a temporary outage (less than the preferred > lifetime) will never result in the node loosing its global address > even if the node were to reboot. This will particularly be useful in > "zeroconf" environments where nodes are configuring their addresses > by the stateless address autoconfiguration but all communication is > closed in a single link. In such a case, the failure of a "router" > (that provides the prefix for address configuration) is not > significant, but loosing the global addresses might be a pain. > > When an implementation tries to reuse a retained address after > rebooting, it MUST run Duplicate Address Detection for the address > under the criteria described in Section 5.4, as though the address > were just configured by stateless address autoconfiguration. The > reason for this is because a different host may have started using > the address while the rebooting host cannot respond to Duplicate > Address Detection from the other host. So the host stores its address on stable storage across reboots? That's fine in general, I think, but I read the original issue slightly differently, quoting from what Erik wrote in the e-mail stored at rt.psg.com: > Another thing that can be contemplated relates to the "zeroconf" case > (where some implementations might end up unnecessarily using smaller scope > addresses when the "home" temporarily is disconnected) would be a > recommendation that implementations try to provide address stability using > stable storage. For instance, I think it is quite reasoanble that > implementations that have stable storage retain their addresses and expiry > times (preferred and valid) whether the addresses were acquired using > RFC 2462 > or DHCP. Assuming the lifetimes used are reasonable this techniques implies > that a temporary outage (less than the preferred lifetime) will > never result in the node loosing its global address even if the > node were to reboot. Perhaps there was a discussion about this on the list that I missed, but I think there are two separate issues here: 1) Router and connectivity goes away for a while. 2) Host itself reboots. Stable storage as such addresses primarily the second scenario. But I think the proposed text may not be very clear with respect to what exactly is going to be done to assist the first scenario. For instance, if you delete your only router from the Default Router list, what is impact on the global addresses do you wish to have? Deprecate the addresses, remove them, continue as-is, or what? What if the host does NOT reboot but the router just goes away for a while, hopefully we are using the stable storage in this case too, but what about DAD? --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:21:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28956 for ; Tue, 30 Mar 2004 18:21:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006WI-JO for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGwGuV002934 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 11:58:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbqK-0000lE-3D for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 11:58:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09857 for ; Tue, 11 Nov 2003 11:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbq6-00060K-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:58:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJbq6-00060H-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbq6-0000R3-3S; Tue, 11 Nov 2003 11:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbpf-0000In-Nv for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 11:57:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09812 for ; Tue, 11 Nov 2003 11:57:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbpe-0005zl-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:57:34 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbpd-0005zd-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:57:33 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA10467 for ; Tue, 11 Nov 2003 16:57:26 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA14573 for ; Tue, 11 Nov 2003 16:57:25 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hABGvPB21298 for ipv6@ietf.org; Tue, 11 Nov 2003 16:57:25 GMT Date: Tue, 11 Nov 2003 16:57:25 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Message-ID: <20031111165725.GD21061@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <5.1.0.14.2.20031023182433.00b4ec48@kahuna.telstra.net> <2147483647.1066997649@dhcp-074-101.cns.ohiou.edu> <6DFADCA0-07CE-11D8-95B0-00039388672E@muada.com> <01ea01c3a7c7$598c8e20$6401a8c0@ssprunk> <3FAFFA9E.C52B2F39@zurich.ibm.com> <20031111033346.3E0F87E1E9@server2.messagingengine.com> <3FB1125A.399F23CF@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB1125A.399F23CF@zurich.ibm.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, Nov 11, 2003 at 05:46:18PM +0100, Brian E Carpenter wrote: > "Private" implies security virtues that they don't have. > "Local" implies geographical limitations that they don't have. > "Site" ditto. > "Organizational" implies usage limitations that they don't have. > "Limited scope" upsets people because of the complexity of the scope debate. > "Entity" really isn't different from "organization". > > Does anybody have a thesaurus handy? Well, we have Autonomous Systems so maybe autonomous addressing? Or does that have too much ASN baggage/confusion, or hint too much at independence? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:21:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29094 for ; Tue, 30 Mar 2004 18:21:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006ZK-ER for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D9LwPk001782 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 04:21:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZWH-0000Sf-QB for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 04:21:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29870 for ; Fri, 13 Feb 2004 04:21:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZW9-0003T5-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 04:21:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZVD-0003OQ-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 04:20:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArZUg-0003Jw-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 04:20:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZUR-0008WB-Fq; Fri, 13 Feb 2004 04:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArZUG-0008Uv-UW for ipv6@optimus.ietf.org; Fri, 13 Feb 2004 04:19:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29801 for ; Fri, 13 Feb 2004 04:19:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArZU8-0003JI-00 for ipv6@ietf.org; Fri, 13 Feb 2004 04:19:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArZTB-0003FS-00 for ipv6@ietf.org; Fri, 13 Feb 2004 04:18:46 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ArZSU-0003Bv-00 for ipv6@ietf.org; Fri, 13 Feb 2004 04:18:02 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 5E3326A907; Fri, 13 Feb 2004 11:18:04 +0200 (EET) Message-ID: <402C95E0.1000205@kolumbus.fi> Date: Fri, 13 Feb 2004 11:16:16 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mukesh.Gupta@nokia.com Cc: ipv6@ietf.org Subject: Re: ICMPv3: Security Consideration Section. References: <8D260779A766FB4A9C1739A476F84FA42ABE9B@daebe009.americas.nokia.com> In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABE9B@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mukesh.Gupta@nokia.com wrote: > Jari, > > >>There may be some additional ICMP issues related to DoS that you >>should mention. There are two exceptions in the multicast rule >>e.2 in Section 2.4. In theory, you could cause a very large number >>of nodes to send you Packet Too Bigs or Parameter Problems. For >>instance, just send a multicast packet with an unknown option marked >>as mandatory. Fortunately, it turns out that its relatively hard to >>get the multicast routers to carry your fake multicast packet unless >>you are on the correct multicast path, i.e. very near the legitimate >>sender. But perhaps you should say something about this too. > > > Even when you are on the correct path, won't this fake multicast > packet with an unknown option marked as mandatory be dropped by > the next hop multicast router ? If the next hop router (or a bunch > of them) itself is gonna drop this packet and send you ICMP error > message, why would you receive ICMP error messages from a large > number of nodes ?? Yes, if we are talking about Packet Too Big or unknown option in a hop-by-hop options header. An unknown option in a destination options header might reach a lot of recipients, however. --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:22:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29194 for ; Tue, 30 Mar 2004 18:22:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006ZK-QS for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12MLtQS024340 for ipv6-archive@odin.ietf.org; Mon, 2 Feb 2004 17:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmS2-0006KS-VP for ipv6-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 17:21:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18066 for ; Mon, 2 Feb 2004 17:21:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmS0-0005IT-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 17:21:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmRA-0005Ci-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 17:21:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnmQW-00056q-00 for ipv6-web-archive@ietf.org; Mon, 02 Feb 2004 17:20:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmQG-0005vG-VV; Mon, 02 Feb 2004 17:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnmPG-0005qv-71 for ipv6@optimus.ietf.org; Mon, 02 Feb 2004 17:19:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17930 for ; Mon, 2 Feb 2004 17:18:58 -0500 (EST) From: shawn.routhier@windriver.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnmPD-0004wa-00 for ipv6@ietf.org; Mon, 02 Feb 2004 17:19:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnmOT-0004oH-00 for ipv6@ietf.org; Mon, 02 Feb 2004 17:18:14 -0500 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx with esmtp (Exim 4.12) id 1AnmNS-0004Xe-00 for ipv6@ietf.org; Mon, 02 Feb 2004 17:17:11 -0500 Received: from ala-mta03.windriver.com (ala-mta03 [147.11.57.132]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA21844; Mon, 2 Feb 2004 14:14:21 -0800 (PST) Received: by ala-mta03.wrs.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Feb 2004 14:14:27 -0800 Message-ID: <47DD7107796EF94CBE7873B8F31DF2C3CB0625@ala-mail01.wrs.com> To: brian@innovationslab.net, heard@pobox.com Cc: bwijnen@lucent.com, j.schoenwaelder@iu-bremen.de, dperkins@dsperkins.com, ipv6@ietf.org Subject: RE: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt Date: Mon, 2 Feb 2004 14:14:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 So I think we are all agreed to change this to (0..2040) in the TC itself? Can we make the required change to 2011 & 2096 as part of any IESG required changes or should they be respun before going to the IESG? Shawn >-----Original Message----- >From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org]On >Behalf Of Brian >Haberman >Sent: Monday, February 02, 2004 1:54 PM >To: C. M. Heard >Cc: Wijnen, Bert (Bert); 'j.schoenwaelder@iu-bremen.de'; David Perkins >(E-mail); ipv6@ietf.org >Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt > > > > >C. M. Heard wrote: > >> On Mon, 2 Feb 2004, Wijnen, Bert (Bert) wrote: >> >>>>So what do we do? >>>> >>>>a) Add the range (0..2040) to the InetPrefixLength TC? (Now >>>>is the right >>>> time to do this.) >>>> >>>>b) Add the range (0..2040) just to the objects in question >>>>that use the >>>> InetPrefixLength TC? >>>> >>>>c) Do both? >>>> >>>>I think I prefer a) at the moment. >>>> >>> >>>I agree that a) is the best solution. >> >> >> That is my opinion, too. > >I prefer a) as well. It makes it cleaner for all the docs involved. > >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 exim@www1.ietf.org Tue Mar 30 18:22:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29365 for ; Tue, 30 Mar 2004 18:22:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006YH-5C for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B9LPZl007915 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 04:21:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MNY-00023Y-Ko for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 04:21:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21246 for ; Thu, 11 Mar 2004 04:21:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1MNV-0007no-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 04:21:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1MMa-0007dr-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 04:20:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1MLi-0007TT-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 04:19:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MLG-0001fy-NT; Thu, 11 Mar 2004 04:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MKc-0001dv-Ne for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 04:18:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21084 for ; Thu, 11 Mar 2004 04:18:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1MKZ-0007GB-00 for ipv6@ietf.org; Thu, 11 Mar 2004 04:18:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1MJd-00073p-00 for ipv6@ietf.org; Thu, 11 Mar 2004 04:17:21 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B1MIf-0006lI-00 for ipv6@ietf.org; Thu, 11 Mar 2004 04:16:21 -0500 content-class: urn:content-classes:message Subject: RE: Multiple DRs on a link Date: Thu, 11 Mar 2004 04:15:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Multiple DRs on a link X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQHQpjQj53paCxyT6GHECneio7xwgABPUzQ From: "Soliman Hesham" To: "Jari Arkko" , "Soliman Hesham" Cc: "Mattias Pettersson L (KI/EAB)" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jari, > > But I have a question about the NEMO case. I had=20 > assumed that mobile > > > routers move around and attach their egress interface to various > > > place in the internet. And that their ingress interface serves > > > a number of hosts, unaware of the movements. I don't see the > > > default router selection as an issue in this scenario, as the > > > hosts will stick to the same mobile router all the time, and > > > the mobile router acts like a host on its egress interface. So > > > if the visited link works for hosts, it should work for mobile > > > routers. > >=20 > > =3D> The problem is when you have 2 MRs, each advertising a = different > > prefix (i.e. different home prefix). >=20 > They are advertising a different prefix on the _ingress_ interface, > and the two MRs both use the _same_ ingress interface?=20 =3D> Correct. Is it the > same because it was configured to do so, as in somehow load- =3D> "same" above refers to the link I guess. > balancing/fault-tolerant MR configuration? Or because their > ingress links happened to randomly merge, or the incapability > of the link layer to keep the two MRs on different links? =3D> There are many different reasons. I sent a verly long=20 email about this to nemo (monet back then). One simple=20 scenario is that you might be walking around with a PAN that happens to have 2 MRs on a single link (e.g. a laptop and a mobile phone). The two MRs could share the same ingress link and have different egress links. For instance your laptop might have a WLAN card and your mobile might have a cellular interface. Once you walk into an airport lounge or starbucks you'll suddenly have a multihomed PAN. By definition, each MR must have a separate home prefix. So each will advertise=20 a different prefix on the ingress side.=20 Other uses my include redundancy (e.g. a train company providing WLAN access on the train). In this case two MRs may be used and they have to advertise different home prefixes.=20 Of course you can imagine other scenarios but this is the=20 basic idea.=20 Hesham >=20 > --Jari >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:23:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29489 for ; Tue, 30 Mar 2004 18:23:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006a4-N0 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIBa2Au024131 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 06:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM49J-0006H5-6d for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 06:36:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16745 for ; Tue, 18 Nov 2003 06:35:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM49F-0003FT-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 06:35:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM49E-0003FQ-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 06:35:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM48O-0005tu-9I; Tue, 18 Nov 2003 06:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM47o-0005sz-0O for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 06:34:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16649 for ; Tue, 18 Nov 2003 06:34:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM47j-0003Di-00 for ipv6@ietf.org; Tue, 18 Nov 2003 06:34:23 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AM47j-0003D3-00 for ipv6@ietf.org; Tue, 18 Nov 2003 06:34:23 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id hAIBXqpI016304 for ; Tue, 18 Nov 2003 12:33:52 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hAIBXqR7006481 for ; Tue, 18 Nov 2003 12:33:52 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hAIBXq08006480 for ipv6@ietf.org; Tue, 18 Nov 2003 12:33:52 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 18 Nov 2003 12:33:52 +0100 From: Stig Venaas To: ipv6@ietf.org Subject: Re: IPv4 compatible deprecation? (addr-arch-v4) Message-ID: <20031118113352.GA6467@sverresborg.uninett.no> References: <20031118102453.GE18738@login.ecs.soton.ac.uk> <3FB9FE19.60604@innovationslab.net> <20031118112719.GX18738@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031118112719.GX18738@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Tue, Nov 18, 2003 at 11:27:19AM +0000, Tim Chown wrote: > Good point, section 6.2 would need massaging on the next update of this spec. > > I'll run a check against other documents. I don't think RFC 3493 is a problem. I had a quick look, and all I can find is that if getnameinfo() is passed a compatible address, it's supposed to extract the IPv4 address and do a lookup on that. That it describes what should happen when passed a compatible address, doesn't prevent deprecating it I think. Don't think it needs to be updated. Stig > > Tim > > On Tue, Nov 18, 2003 at 06:10:17AM -0500, Brian Haberman wrote: > > [wg co-chair hat off] > > > > What about their use in the basic socket API (rfc 3493)? > > > > Brian > > > > Tim Chown wrote: > > > > >Hi, > > > > > >A discussion on v6ops made me realise that while I thought we were > > >deprecating IPv4 compatible addresses, this actually isn't the case. > > >I have a feeling many people have assumed their use is "deprecated" > > >but this isn't formally documented? > > > > > >IPv4 compatibles have now been removed from the latest update of the > > >Basic Transition Mechanisms document that is just going through v6ops: > > >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt > > > > > >If we want to deprecate IPv4-compatible addressing, then we need to look > > >at section 2.5.5 of the addressing architecture document that was > > >re-released with site local updates last month: > > >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt > > > > > >We should catch this one while the text is being updated for site locals. > > >We would presumably update the text in a similar way to the site local > > >text update to section 2.5.7. > > > > > >If a separate deprecation document is required as per site local > > >deprecation > > >I would be happy to author/help on that. For reference, the site local > > >deprecation is defined here: > > >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-01.txt > > > > > >This deprecation would not affect mapped addresses. > > > > > >Tim > > > > > >-------------------------------------------------------------------- > > >IETF IPv6 working group mailing list > > >ipv6@ietf.org > > >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > >-------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:23:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29510 for ; Tue, 30 Mar 2004 18:23:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006a4-DQ for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J8pCFG017729 for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 03:51:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atjtm-0004bp-33 for ipv6-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 03:51:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05880 for ; Thu, 19 Feb 2004 03:51:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atjtj-0005Xf-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 03:51:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atjsl-0005U9-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 03:50:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atjs6-0005RE-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 03:49:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atjri-0003xq-Jd; Thu, 19 Feb 2004 03:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atjqq-0003w8-1K for ipv6@optimus.ietf.org; Thu, 19 Feb 2004 03:48:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05777 for ; Thu, 19 Feb 2004 03:48:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atjqn-0005N1-00 for ipv6@ietf.org; Thu, 19 Feb 2004 03:48:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atjpp-0005KK-00 for ipv6@ietf.org; Thu, 19 Feb 2004 03:47:06 -0500 Received: from a.mx.kooks.net ([204.152.189.141] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AtjpR-0005HY-00 for ipv6@ietf.org; Thu, 19 Feb 2004 03:46:41 -0500 Received: from a.mx.kooks.net (a.mx.kooks.net [204.152.189.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.kooks.net (Postfix) with ESMTP id 4545223C2A; Thu, 19 Feb 2004 00:46:41 -0800 (PST) Date: Thu, 19 Feb 2004 00:46:41 -0800 (PST) From: Chris Yarnell To: john.loughney@nokia.com Cc: Mark_Andrews@isc.org, ipv6@ietf.org Subject: RE: I-D ACTION:draft-ietf-ipv6-node-requirements-08.txt In-Reply-To: Message-ID: <20040219004544.H15661@lame.kooks.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > > Just don't mention DNAME at all. Note DNAME support will > > be manditory with DNSSEC so the only issue is whether we > > discourage the use under IP6.ARPA which I (and lots of others > > in dnsext) now believe we got wrong. > > > > "Those nodes are NOT RECOMMENDED to support the experimental A6 > > Resource Records [RFC-3363]." > > That would be OK with me. Any other opinions? I agree with Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:23:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29614 for ; Tue, 30 Mar 2004 18:23:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006a4-49 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H7weis012912 for ipv6-archive@odin.ietf.org; Wed, 17 Mar 2004 02:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Vwj-0003Ff-Lj for ipv6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 02:58:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24231 for ; Wed, 17 Mar 2004 02:58:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3VwQ-0005BR-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 02:58:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3VvW-00055S-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 02:57:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Vuz-0004zU-00 for ipv6-web-archive@ietf.org; Wed, 17 Mar 2004 02:56:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VuM-0002z0-2z; Wed, 17 Mar 2004 02:56:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Vtg-0002xt-5k for ipv6@optimus.ietf.org; Wed, 17 Mar 2004 02:55:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24105 for ; Wed, 17 Mar 2004 02:55:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Vtb-0004sD-00 for ipv6@ietf.org; Wed, 17 Mar 2004 02:55:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Vsq-0004lG-00 for ipv6@ietf.org; Wed, 17 Mar 2004 02:54:37 -0500 Received: from thrintun.hactrn.net ([66.92.66.67]) by ietf-mx with esmtp (Exim 4.12) id 1B3Vs4-0004XY-00 for ipv6@ietf.org; Wed, 17 Mar 2004 02:53:48 -0500 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id DED8218EE for ; Wed, 17 Mar 2004 02:53:18 -0500 (EST) Date: Wed, 17 Mar 2004 02:53:18 -0500 From: Rob Austein To: ipv6@ietf.org Subject: Re: AD Evaluation of draft-ietf-ipv6-unique-local-addr-03.txt In-Reply-To: <200403170347.i2H3lFqW093779@drugs.dv.isc.org> References: <9C0F03A6-76AB-11D8-9F71-00039376A6AA@sun.com> <200403170347.i2H3lFqW093779@drugs.dv.isc.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040317075318.DED8218EE@thrintun.hactrn.net> Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At Wed, 17 Mar 2004 14:47:15 +1100, Mark Andrews wrote: > At Mon, 15 Mar 2004 10:07:23 -0800, Alain Durand wrote: > > > > I too would like to see the reverse tree DNS being > > delegated. However, as there is no structure, the entire /8 to /48 > > address space would have to be within one single zone... I'm > > afraid we are going to create a monster zone that will be very > > difficult to sign with DNSsec. > > No it doesn't have to be within one zone. You can split > the namespace between as many zones / servers as are required > to make the job managable. Furthermore, the signed unit in DNSSEC is an RRset, so it's almost always possible to sign incrementally (even during an emergency key rollover, if one has the foresight to generate spare keys and signatures in advance). > How this is done really should be left to the authority > which is managing the space. Unsurprisingly, I agree. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:23:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29637 for ; Tue, 30 Mar 2004 18:23:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006WI-Vk for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1R9RnAU005432 for ipv6-archive@odin.ietf.org; Fri, 27 Feb 2004 04:27:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweHc-0001PX-St for ipv6-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 04:27:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22091 for ; Fri, 27 Feb 2004 04:27:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AweHa-0002NG-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 04:27:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AweGh-0002Cy-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 04:26:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AweFf-00022R-00 for ipv6-web-archive@ietf.org; Fri, 27 Feb 2004 04:25:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AweE3-0000GI-8Z; Fri, 27 Feb 2004 04:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwdKs-0005fg-QA for ipv6@optimus.ietf.org; Fri, 27 Feb 2004 03:27:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20386 for ; Fri, 27 Feb 2004 03:27:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwdKq-0004J9-00 for ipv6@ietf.org; Fri, 27 Feb 2004 03:27:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwdJs-0004EU-00 for ipv6@ietf.org; Fri, 27 Feb 2004 03:26:04 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AwdIt-00046K-00 for ipv6@ietf.org; Fri, 27 Feb 2004 03:25:03 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 49D8C15214 for ; Fri, 27 Feb 2004 17:25:03 +0900 (JST) Date: Fri, 27 Feb 2004 17:25:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipv6@ietf.org Subject: [rfc2462bis issue 281] Requirement for 64bit I/F ID 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I've been thinking about this issue for a while. Currently, I'm not sure if we need to do something in rfc2462bis for this issue. I originally thought RFC2462 had some sort of assumption that an interface identifier is 64 bits long at least for some cases. Looking at RFC2462 again, however, I've not found such an assumption. The only parts in RFC2462 that mentions "64 bits" are as follows: Note that interface identifiers will typically be 64-bits long and based on EUI-64 identifiers as described in [ADDR-ARCH]. (Section 5.3 of RFC2462) And section 5.5.3 bullet d) has exactly the same sentence. (BTW: the latest rfc2462bis draft lacks this part by an accident. I'll recover it in the next revision.) None of them assumes anything about the prefix length. In this sense, I guess we could take the option of "do nothing". However, I still see some unclear points around the issue. According to Section 2 of RFC2462, the length of an interface identifier is dependent on the corresponding link: interface identifier - a link-dependent identifier for an interface that is (at least) unique per link [ADDR-ARCH]. Stateless address autoconfiguration combines an interface identifier with a prefix to form an address. From address autoconfiguration's perspective, an interface identifier is a bit string of known length. The exact length of an interface identifier and the way it is created is defined in a separate link-type specific document that covers issues related to the transmission of IP over a particular link type (e.g., [IPv6-ETHER]). ... And, in fact, [IPv6-ETHER] (RFC2464) specifies that the length of interface identifiers for an Ethernet link is 64 bits: The Interface Identifier [AARCH] for an Ethernet interface is based on the EUI-64 identifier [EUI64] derived from the interface's built- in 48-bit IEEE 802 address. ... An IPv6 address prefix used for stateless autoconfiguration [ACONF] of an Ethernet interface must have a length of 64 bits. (Section 4 of RFC2464) (Note: the latter part actually specifies the length of the prefix, but the result is the same: interface IDs are also 64(=128-64) bits.) On the other hand, the IPv6 address architecture document seems to say the length of interface IDs is (at least partly) determined by the address format. For example, draft-ietf-ipv6-addr-arch-v4-00.txt says in Section 2.5.1 that: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. RFC3587 (Global Unicast Address Format) also adopts this convention: [ARCH] also requires that all unicast addresses, except those that start with binary value 000, have Interface IDs that are 64 bits long and to be constructed in Modified EUI-64 format. (Section 3 of RFC3587) Which one is correct? Is the length of IF IDs determined by the link type, or the address format, or both? If the answer is "both", there may be inconsistency in future specification. For example, what if a future IPv6-over-FOO document specifies like this? An IPv6 address prefix used for stateless autoconfiguration [ACONF] of a FOO interface must have a length of 80 bits. Will we then have to give up using stateless address autoconfiguration with unicast prefixes beginning with "000" in this link? Technically, this is not necessary a contradiction. [IPv6-ETHER] only requires 64-bit IF IDs for stateless address autoconfiguration, so the above (imaginary) IPv6-over-FOO document and the addr-arch document can coexist without conflicting each other if we give up stateless autoconfiguration in this link. But is this a realistic option? Please someone clarify this point. Then I'll consider what is necessary for rfc2462bis (or whether we need to do something in the first place) for this matter. 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 exim@www1.ietf.org Tue Mar 30 18:24:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29704 for ; Tue, 30 Mar 2004 18:24:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006a4-Vl for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NCBJ3Q020577 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 07:11:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5kkV-0005La-Jn for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 07:11:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21892 for ; Tue, 23 Mar 2004 07:11:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5kkR-0006SQ-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 07:11:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5kjX-0006Ml-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 07:10:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5kjD-0006Gn-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 07:09:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5kiM-00051k-QD; Tue, 23 Mar 2004 07:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5khn-00050G-Ot for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 07:08:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21736 for ; Tue, 23 Mar 2004 07:08:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5khj-000682-00 for ipv6@ietf.org; Tue, 23 Mar 2004 07:08:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5kgl-00060u-00 for ipv6@ietf.org; Tue, 23 Mar 2004 07:07:24 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B5kg5-0005rZ-00 for ipv6@ietf.org; Tue, 23 Mar 2004 07:06:41 -0500 content-class: urn:content-classes:message Subject: RE: ND-proxy applicability and loop-prevention Date: Tue, 23 Mar 2004 07:06:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: ND-proxy applicability and loop-prevention Thread-Index: AcQQxxxyUCoKrdUbTDetXgTkkyKh+QABjfKg From: "Soliman Hesham" To: "Pekka Savola" Cc: "Erik Nordmark" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 > > =3D> I think it's a bad signal, _if_ detected. I.e. An average > > user is not even going to know that they have 100% link > > utilisation. And _if_ they do, I actually think that neither > > the user, nor the help desk first line of support will > > have the faintest idea (having been a regular with help > > desk people that work for a couple of major operators > > in different countries). >=20 > The user knows that all of his communication attempts fail. =20 > That's a=20 > good signal that there's something wrong. If the user knows nothing=20 > more of this, he calls helpdesk or some support, which may=20 > be able to=20 > identify the problem and eliminate it. =3D> "may" is the key word. I basically don't believe it. I think it'll be problematic enough to be always disabled. >=20 > Maybe the shop knows something about how the device operates -- they=20 > certainly should! --=20 =3D> Maybe shops in your vicinity employ technicians to sell this stuff but I certainly _never_ saw a shop assistant=20 who knows anymore than the text on the box.=20 or you read documentation, which should=20 > certainly=20 > describe this feature. =3D> I don't think you understant what an "average user" means. It means, get the box, plug it in, it works!=20 I know people that struggle with connecting a DVD to the TV....let's be realistic.=20 > For the average user, it doesn't have to be more intuitive than that, > right? He only cares whether it works or not. In the first place > 99.9% of people wouldn't be plugging these boxes in=20 > triangles=20 =3D> I disagree with making assumptions about what deployment scenarios will be like in the next 5-7 years. Thus, I disagree with your premise about 99.9 % of scenarios. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:24:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29722 for ; Tue, 30 Mar 2004 18:24:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006WI-Lu for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DAtePH001226 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 05:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArayY-0000Ht-9x for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 05:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03744 for ; Fri, 13 Feb 2004 05:54:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aray8-0003y9-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:54:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arax8-0003pV-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:53:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Araw4-0003hp-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:52:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aravc-0007DT-RI; Fri, 13 Feb 2004 05:52:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTJo-0006Lx-2L for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 21:44:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03917 for ; Thu, 12 Feb 2004 21:44:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTJj-0000AD-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:44:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTIm-000029-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:43:37 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArTHv-0007kV-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:42:43 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1ArTHx-0003oH-NC for ipv6@ietf.org; Fri, 13 Feb 2004 02:42:45 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2461bis@rt.psg.com RT-Ticket: psg.com #247 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2461bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: h.soliman@flarion.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #247] [2461bis issue 247] On-link assumption harmful for dual stack nodes In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Fri, 13 Feb 2004 02:42:45 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Issue: On-link assumptions in 2461 considered harmful. This issue was raised by Alain and documented in: draft-ietf-v6ops-onlinkassumption-00.txt draft-ietf-v6ops-v6onbydefault-00.txt Also see related issue in section 2.4 of: http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt Suggestion: Remove on-link assumption from section 5.2. This sentence was removed from section 5.2. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:24:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29726 for ; Tue, 30 Mar 2004 18:24:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006a4-Lc for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DAteEx001221 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 05:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArayY-0000Hu-9v for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 05:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03747 for ; Fri, 13 Feb 2004 05:54:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aray8-0003yE-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:54:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arax8-0003pd-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:53:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Araw4-0003hq-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:52:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AravR-00074c-Ai; Fri, 13 Feb 2004 05:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArT9F-0005ZE-Ji for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 21:33:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03212 for ; Thu, 12 Feb 2004 21:33:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArT9A-0006wS-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:33:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArT88-0006rc-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:32:36 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArT7q-0006nF-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:32:18 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1ArT7t-0001tB-8E for ipv6@ietf.org; Fri, 13 Feb 2004 02:32:21 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2461bis@rt.psg.com RT-Ticket: psg.com #248 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2461bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: h.soliman@flarion.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #248] [2461bis issue 248] Inconsistencies in router lifetime values In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Fri, 13 Feb 2004 02:32:21 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Issue description from Pete Barany's email: > What I mean to say is that the parameter AdvDefaultLifetime MUST be > either zero or between MaxRtrAdvInterval and 9000 seconds (IPv6) per > RFC 2461. Same thing for IPv4 per RFC 1256 (only the parameter is > Advertisement Lifetime). The inconsistency (for lack of a better word) > is that the Router Lifetime field is 16 bits and if set to anything > greater than 9000 seconds then this would violate the specifications. > So, if it is set to 18.2 hours (e.g., for some wireless cellular > links) it violates the specs. Suggested resolution from Erik Nordmark: So if we change the sentence in 4.2 from: The maximum value corresponds to 18.2 hours. to The field can contain values up to 65535 and receivers should handle any value, while the sending rules in section 6 limit the lifetime to 9000 seconds. would that be better? Cuurent text in the doc: Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in section 6 limit the lifetime to 9000 seconds. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:24:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29821 for ; Tue, 30 Mar 2004 18:24:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006WI-O5 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DAtehA001222 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 05:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArayY-0000Hw-9h for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 05:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03750 for ; Fri, 13 Feb 2004 05:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aray9-0003yK-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:54:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arax9-0003pl-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:53:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Araw6-0003hm-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:52:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aravb-0007CE-2n; Fri, 13 Feb 2004 05:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTJn-0006Ls-7z for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 21:44:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03914 for ; Thu, 12 Feb 2004 21:44:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTJi-0000A8-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:44:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTIm-00001z-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:43:36 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArTHu-0007kU-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:42:43 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1ArTHx-0003oE-FY for ipv6@ietf.org; Fri, 13 Feb 2004 02:42:45 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2461bis@rt.psg.com RT-Ticket: psg.com #247 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2461bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: h.soliman@flarion.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #247] [2461bis issue 247] On-link assumption harmful for dual stack nodes In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Fri, 13 Feb 2004 02:42:45 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Issue: On-link assumptions in 2461 considered harmful. This issue was raised by Alain and documented in: draft-ietf-v6ops-onlinkassumption-00.txt draft-ietf-v6ops-v6onbydefault-00.txt Also see related issue in section 2.4 of: http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt Suggestion: Remove on-link assumption from section 5.2. This sentence was removed from section 5.2. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:24:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29842 for ; Tue, 30 Mar 2004 18:24:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006ZK-Kf for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE316b3030369 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 22:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUCk-0007sh-W9 for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 22:01:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07929 for ; Thu, 13 Nov 2003 22:00:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUCe-0003pl-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 22:00:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKUCc-0003pX-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 22:00:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUBz-0007e2-OL; Thu, 13 Nov 2003 22:00:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUBb-0007WE-R9 for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 21:59:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07848 for ; Thu, 13 Nov 2003 21:59:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUBY-0003mP-00 for ipv6@ietf.org; Thu, 13 Nov 2003 21:59:48 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx with esmtp (Exim 4.12) id 1AKUBX-0003lt-00 for ipv6@ietf.org; Thu, 13 Nov 2003 21:59:47 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAE2xHT2077938; Fri, 14 Nov 2003 02:59:17 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAE2xGw2251508; Fri, 14 Nov 2003 03:59:16 +0100 Received: from zurich.ibm.com ([9.145.140.250]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id DAA51252; Fri, 14 Nov 2003 03:59:13 +0100 Message-ID: <3FB444DB.497FB2ED@zurich.ibm.com> Date: Fri, 14 Nov 2003 03:58:35 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: ipv6@ietf.org, Christian Huitema Subject: Re: SL deprecation draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Thu, 13 Nov 2003, Bob Hinden wrote: > > So my take is that only the Address Architecture and Default Address > > Selection documents need to be listed. > > FWIW, totally agree here. Listing those which had no issues of substance > only confuse the reader. That isn't completely clear to me. We could say something like: This deprecation will require substantive updates to the Address Architecture and Default Address Selection documents [ref, ref]. The site local prefix is also mentioned in several other documents which need at most minor editorial updates [ref, ref, ref...]. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:24:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29847 for ; Tue, 30 Mar 2004 18:24:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006a4-JQ for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DAteGg001225 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 05:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArayY-0000Hx-K1 for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 05:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03753 for ; Fri, 13 Feb 2004 05:54:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArayA-0003yR-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:54:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AraxA-0003pu-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:53:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Araw6-0003hn-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:52:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AravT-00074w-6W; Fri, 13 Feb 2004 05:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArT9G-0005ZK-9P for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 21:33:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03215 for ; Thu, 12 Feb 2004 21:33:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArT9B-0006wY-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:33:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArT89-0006rk-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:32:37 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArT7q-0006nG-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:32:19 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1ArT7t-0001tE-Fo for ipv6@ietf.org; Fri, 13 Feb 2004 02:32:21 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2461bis@rt.psg.com RT-Ticket: psg.com #248 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2461bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: h.soliman@flarion.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #248] [2461bis issue 248] Inconsistencies in router lifetime values In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Fri, 13 Feb 2004 02:32:21 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Issue description from Pete Barany's email: > What I mean to say is that the parameter AdvDefaultLifetime MUST be > either zero or between MaxRtrAdvInterval and 9000 seconds (IPv6) per > RFC 2461. Same thing for IPv4 per RFC 1256 (only the parameter is > Advertisement Lifetime). The inconsistency (for lack of a better word) > is that the Router Lifetime field is 16 bits and if set to anything > greater than 9000 seconds then this would violate the specifications. > So, if it is set to 18.2 hours (e.g., for some wireless cellular > links) it violates the specs. Suggested resolution from Erik Nordmark: So if we change the sentence in 4.2 from: The maximum value corresponds to 18.2 hours. to The field can contain values up to 65535 and receivers should handle any value, while the sending rules in section 6 limit the lifetime to 9000 seconds. would that be better? Cuurent text in the doc: Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in section 6 limit the lifetime to 9000 seconds. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:25:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29915 for ; Tue, 30 Mar 2004 18:25:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006ZK-AS for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DAtex3001224 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 05:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArayY-0000Hr-AO for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 05:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03741 for ; Fri, 13 Feb 2004 05:54:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aray7-0003y4-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:54:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arax7-0003pM-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:53:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Araw4-0003hl-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:52:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AravV-00075K-U1; Fri, 13 Feb 2004 05:52:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTD2-0005xD-6x for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 21:37:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03381 for ; Thu, 12 Feb 2004 21:37:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTCx-0007JK-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:37:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTCD-0007Ep-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:36:50 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArTBc-0007A4-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:36:12 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1ArTBe-0002P7-Su for ipv6@ietf.org; Fri, 13 Feb 2004 02:36:14 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2461bis@rt.psg.com RT-Ticket: psg.com #246 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2461bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: h.soliman@flarion.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #246] [2461bisissue 246] Preferred lifetime > valid lifetime In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Fri, 13 Feb 2004 02:36:14 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Issue: What is the handling for the case where a prefix's preferred lifetime exceeds the valid lifetime? Suggestion: Specify that a router MUST NOT send a prefix option containing preferred lifetime > valid lifetime Current text in Preferred Lifetime description (sec 4.2): Preferred Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred [ADDRCONF]. A value of all one bits (0xffffffff) represents infinity. See [ADDRCONF]. Note that the value of this field MUST NOT exceed the Valid Lifetime field to avoid preferring addresses that are no longer valid. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:25:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29964 for ; Tue, 30 Mar 2004 18:25:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006a4-D8 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAg7RP002059 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:42:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1v5-0000X8-1b for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:42:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11419 for ; Sat, 28 Feb 2004 05:42:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1v1-0003a5-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:42:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1u8-0003SS-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:41:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1tL-0003Kd-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:40:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1tC-0008D5-St; Sat, 28 Feb 2004 05:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1sX-0008Ae-3E for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:39:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11283 for ; Sat, 28 Feb 2004 05:39:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1sT-0003CK-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:39:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1rd-00033H-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:38:33 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1qz-0002tE-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:37:53 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1r0-000CvK-IX for ipv6@ietf.org; Sat, 28 Feb 2004 10:37:54 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #268 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #268] Deprecated Addresses and Source address selection In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:37:54 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 No objection to the proposed resolution, so the issue is closed. Please revisit the issue if you have a different opinion. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:25:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29987 for ; Tue, 30 Mar 2004 18:25:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006a4-FB for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAg8E9002074 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1v6-0000XN-Je for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:42:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11422 for ; Sat, 28 Feb 2004 05:42:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1v3-0003aI-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:42:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1u8-0003Sc-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:41:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1tL-0003Ke-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:40:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1t8-0008CM-8o; Sat, 28 Feb 2004 05:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1sV-0008AU-R0 for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:39:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11277 for ; Sat, 28 Feb 2004 05:39:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1sS-0003C8-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:39:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1rc-00032z-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:38:32 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1qy-0002tB-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:37:52 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1qz-000Cv8-V0 for ipv6@ietf.org; Sat, 28 Feb 2004 10:37:53 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #268 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #268] Deprecated Addresses and Source address selection In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:37:53 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 No objection to the proposed resolution, so the issue is closed. Please revisit the issue if you have a different opinion. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:25:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00024 for ; Tue, 30 Mar 2004 18:25:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006a4-8c for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOJDFW5006753 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 14:13:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOM92-0001jN-Jk for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 14:13:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22179 for ; Mon, 24 Nov 2003 14:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOM8t-0002cq-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 14:13:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOM8t-0002cn-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 14:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOM8r-0001e7-HT; Mon, 24 Nov 2003 14:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOM8n-0001df-42 for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 14:12:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22174 for ; Mon, 24 Nov 2003 14:12:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOM8k-0002cj-00 for ipv6@ietf.org; Mon, 24 Nov 2003 14:12:54 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AOM8k-0002cg-00 for ipv6@ietf.org; Mon, 24 Nov 2003 14:12:54 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 98162AFEB8; Mon, 24 Nov 2003 14:12:54 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25762-10; Mon, 24 Nov 2003 14:12:53 -0500 (EST) Received: from cs.utk.edu (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 45587AFEB6; Mon, 24 Nov 2003 14:12:53 -0500 (EST) Date: Mon, 24 Nov 2003 14:13:40 -0500 Subject: Re: draft-hain-templin-ipv6-localcomm-03 comments Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: Keith Moore , Pekka Savola , ipv6@ietf.org To: Brian E Carpenter From: Keith Moore In-Reply-To: <3FC1C557.50733BA8@zurich.ibm.com> Message-Id: <5005EA5C-1EB2-11D8-89BF-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I hate NATs, and the delusion that private addresses are a security > feature, > as much as you do. This draft suffers from many more delusions than that. If it's going to be viable it needs to treat commonly held network managers' beliefs as distinct from reality. I'm all for trying to fashion a message in a form that network managers can understand and accept. But we can't do good engineering if we either adopt their delusions or if we pretend that non-global addresses should be used in the same way as private addresses. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:25:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00073 for ; Tue, 30 Mar 2004 18:25:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006WI-9l for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DAtejt001248 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 05:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Araya-0000Hz-1b for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 05:55:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03759 for ; Fri, 13 Feb 2004 05:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArayB-0003yc-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:54:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AraxB-0003qB-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:53:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Araw9-0003jl-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:52:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AravU-000758-G3; Fri, 13 Feb 2004 05:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTD1-0005x0-Hz for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 21:37:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03378 for ; Thu, 12 Feb 2004 21:37:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTCw-0007JF-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:37:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTCC-0007Eh-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:36:49 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArTBc-0007A3-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:36:12 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1ArTBe-0002Oy-JM for ipv6@ietf.org; Fri, 13 Feb 2004 02:36:14 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2461bis@rt.psg.com RT-Ticket: psg.com #246 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2461bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: h.soliman@flarion.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #246] [2461bisissue 246] Preferred lifetime > valid lifetime In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Fri, 13 Feb 2004 02:36:14 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Issue: What is the handling for the case where a prefix's preferred lifetime exceeds the valid lifetime? Suggestion: Specify that a router MUST NOT send a prefix option containing preferred lifetime > valid lifetime Current text in Preferred Lifetime description (sec 4.2): Preferred Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred [ADDRCONF]. A value of all one bits (0xffffffff) represents infinity. See [ADDRCONF]. Note that the value of this field MUST NOT exceed the Valid Lifetime field to avoid preferring addresses that are no longer valid. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:26:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00117 for ; Tue, 30 Mar 2004 18:26:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjO-0006ZK-8M for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKh5UN008456 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:43:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1pQ-0002C0-C4 for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:43:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08203 for ; Wed, 12 Nov 2003 15:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1pN-0005ij-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:43:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1pM-0005ig-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1oS-0001pu-Qk; Wed, 12 Nov 2003 15:42:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1oH-0001i5-GC for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 15:41:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08137 for ; Wed, 12 Nov 2003 15:41:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1oF-0005gT-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:41:52 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AK1oD-0005fl-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:41:50 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hACKf3a04263; Wed, 12 Nov 2003 12:41:03 -0800 X-mProtect: <200311122041> Nokia Silicon Valley Messaging Protection Received: from danira-pool05159.americas.nokia.com (10.241.51.59, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdsD9Cpb; Wed, 12 Nov 2003 12:41:02 PST Message-ID: <3FB29AD2.6040702@iprg.nokia.com> Date: Wed, 12 Nov 2003 12:40:50 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: pekkas@netcore.fi, huitema@windows.microsoft.com, ipv6@ietf.org Subject: Re: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt References: <20031112202652.7C40A9B@coconut.itojun.org> In-Reply-To: <20031112202652.7C40A9B@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino wrote: > my suggestion is to leave it SHOULD. you didnt justify why. makes no sense on an unprotected network. Vijay -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:26:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00257 for ; Tue, 30 Mar 2004 18:26:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006a4-S4 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19CLGlc010037 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 07:21:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAPc-0002bo-I8 for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 07:21:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14971 for ; Mon, 9 Feb 2004 07:21:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqAPc-00069u-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:21:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqAOh-00062d-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:20:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqAO3-0005vd-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:19:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAMW-0001JY-3F; Mon, 09 Feb 2004 07:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq3te-0004ly-Ju for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 00:23:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18545 for ; Mon, 9 Feb 2004 00:23:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq3tc-0001Rl-00 for ipv6@ietf.org; Mon, 09 Feb 2004 00:23:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq3si-0001Nn-00 for ipv6@ietf.org; Mon, 09 Feb 2004 00:22:53 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Aq3sK-0001JB-00 for ipv6@ietf.org; Mon, 09 Feb 2004 00:22:28 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Aq3sK-0002p2-Vj for ipv6@ietf.org; Mon, 09 Feb 2004 05:22:28 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #321 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #321] preferred lifetime and the 'two-hour' rule In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Mon, 09 Feb 2004 05:22:28 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Proposed Resolution (revised): update section 5.5.3 e) as attached below. Reason: based on the recent discussion on the wg list. Key changes are: - make it clear that the preferred lifetime is always resest to the advertised value - note the difference between the two lifetimes and explain the reason Revised text: e) If the advertised prefix matches the prefix of an autoconfigured address (i.e., one obtained via stateless or stateful address autoconfiguration) in the list of addresses associated with the interface, the preferred lifetime of the address is reset to the Preferred Lifetime in the received advertisement. The specific action to perform for the valid lifetime of the address depends on the Valid Lifetime in the received advertisement and the remaining time to the valid lifetime expiration of the previously autoconfigured address. We call the remaining time "RemainingLifetime" in the following discussion: 1. If the received Valid Lifetime is greater than 2 hours or greater than RemainingLifetime, set the valid lifetime of the corresponding address to the advertised Valid Lifetime. 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 IPSec [1]). If the Router Advertisement was authenticated, the valid lifetime of the corresponding address should be set to the Valid Lifetime in the received option. 3. Otherwise, reset the valid lifetime of the corresponding address to two hours. The above rules address a specific denial of service attack in which a bogus advertisement could contain prefixes with very small Valid Lifetimes. Without the above rules, a single unauthenticated advertisement containing bogus Prefix Information options with short Valid Lifetimes could cause all of a node's addresses to expire prematurely. The above rules ensure that legitimate advertisements (which are sent periodically) will "cancel" the short Valid Lifetimes before they actually take effect. Note that the preferred lifetime of the corresponding address is always reset to the Preferred Lifetime in the received Prefix Information option, regardless of whether the valid lifetime is also reset or ignored. The difference comes from the fact that the possible attack for the preferred lifetime is relatively minor. Additionally, it is even undesirable to ignore the preferred lifetime when a valid administrator wants to deprecate a particular address by sending a short lifetime (and the valid lifetime is ignored by accident). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:26:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00280 for ; Tue, 30 Mar 2004 18:26:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006a4-Th for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19CLHDh010067 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 07:21:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAPd-0002cI-Nu for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 07:21:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14977 for ; Mon, 9 Feb 2004 07:21:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqAPd-0006A5-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:21:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqAOj-00062u-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:20:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqAO3-0005vh-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:19:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAMX-0001Jk-C1; Mon, 09 Feb 2004 07:18:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq3tf-0004m3-9K for ipv6@optimus.ietf.org; Mon, 09 Feb 2004 00:23:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18548 for ; Mon, 9 Feb 2004 00:23:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq3tc-0001Rq-00 for ipv6@ietf.org; Mon, 09 Feb 2004 00:23:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq3sj-0001Nv-00 for ipv6@ietf.org; Mon, 09 Feb 2004 00:22:54 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Aq3sK-0001JC-00 for ipv6@ietf.org; Mon, 09 Feb 2004 00:22:28 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Aq3sL-0002p7-Er for ipv6@ietf.org; Mon, 09 Feb 2004 05:22:29 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #321 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #321] preferred lifetime and the 'two-hour' rule In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Mon, 09 Feb 2004 05:22:29 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Proposed Resolution (revised): update section 5.5.3 e) as attached below. Reason: based on the recent discussion on the wg list. Key changes are: - make it clear that the preferred lifetime is always resest to the advertised value - note the difference between the two lifetimes and explain the reason Revised text: e) If the advertised prefix matches the prefix of an autoconfigured address (i.e., one obtained via stateless or stateful address autoconfiguration) in the list of addresses associated with the interface, the preferred lifetime of the address is reset to the Preferred Lifetime in the received advertisement. The specific action to perform for the valid lifetime of the address depends on the Valid Lifetime in the received advertisement and the remaining time to the valid lifetime expiration of the previously autoconfigured address. We call the remaining time "RemainingLifetime" in the following discussion: 1. If the received Valid Lifetime is greater than 2 hours or greater than RemainingLifetime, set the valid lifetime of the corresponding address to the advertised Valid Lifetime. 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 IPSec [1]). If the Router Advertisement was authenticated, the valid lifetime of the corresponding address should be set to the Valid Lifetime in the received option. 3. Otherwise, reset the valid lifetime of the corresponding address to two hours. The above rules address a specific denial of service attack in which a bogus advertisement could contain prefixes with very small Valid Lifetimes. Without the above rules, a single unauthenticated advertisement containing bogus Prefix Information options with short Valid Lifetimes could cause all of a node's addresses to expire prematurely. The above rules ensure that legitimate advertisements (which are sent periodically) will "cancel" the short Valid Lifetimes before they actually take effect. Note that the preferred lifetime of the corresponding address is always reset to the Preferred Lifetime in the received Prefix Information option, regardless of whether the valid lifetime is also reset or ignored. The difference comes from the fact that the possible attack for the preferred lifetime is relatively minor. Additionally, it is even undesirable to ignore the preferred lifetime when a valid administrator wants to deprecate a particular address by sending a short lifetime (and the valid lifetime is ignored by accident). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:26:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00298 for ; Tue, 30 Mar 2004 18:26:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006a4-QC for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DAteBI001227 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 05:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArayZ-0000Hy-Be for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 05:55:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03756 for ; Fri, 13 Feb 2004 05:54:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArayA-0003yW-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:54:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AraxB-0003q2-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:53:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Araw6-0003ho-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:52:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AravZ-0007Az-Ez; Fri, 13 Feb 2004 05:52:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTFy-0006Eg-M2 for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 21:40:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03464 for ; Thu, 12 Feb 2004 21:40:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTFt-0007Zd-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:40:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTF0-0007V2-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:39:42 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArTEj-0007Pn-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:39:25 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1ArTEm-00039Y-8D for ipv6@ietf.org; Fri, 13 Feb 2004 02:39:28 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2461bis@rt.psg.com RT-Ticket: psg.com #259 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2461bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: h.soliman@flarion.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #259] [2461bis issue 259] Add flags from MIPv6 spec In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Fri, 13 Feb 2004 02:39:28 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Issue: This issue was raised to include MIPv6 extensions of the Router Advertisement in 2461bis. Suggestion: Most people objected to this since there would be no reason to pick some flags and not other extensions. Also, ND extensions are likely to happen in other specifications and there is no need to update ND every time this happens. Therefore this issue is rejected. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:26:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00336 for ; Tue, 30 Mar 2004 18:26:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006a4-Np for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DAteFg001243 for ipv6-archive@odin.ietf.org; Fri, 13 Feb 2004 05:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Araya-0000I0-OU for ipv6-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 05:55:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03762 for ; Fri, 13 Feb 2004 05:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArayC-0003yh-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:54:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AraxD-0003qP-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:53:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArawA-0003kq-00 for ipv6-web-archive@ietf.org; Fri, 13 Feb 2004 05:52:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AravY-00079j-05; Fri, 13 Feb 2004 05:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTFy-0006EV-0k for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 21:40:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03461 for ; Thu, 12 Feb 2004 21:40:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTFt-0007ZY-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:40:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTEz-0007Uu-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:39:41 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArTEj-0007Pm-00 for ipv6@ietf.org; Thu, 12 Feb 2004 21:39:25 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1ArTEm-00039V-0g for ipv6@ietf.org; Fri, 13 Feb 2004 02:39:28 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2461bis@rt.psg.com RT-Ticket: psg.com #259 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2461bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: h.soliman@flarion.com X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #259] [2461bis issue 259] Add flags from MIPv6 spec In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Fri, 13 Feb 2004 02:39:28 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Issue: This issue was raised to include MIPv6 extensions of the Router Advertisement in 2461bis. Suggestion: Most people objected to this since there would be no reason to pick some flags and not other extensions. Also, ND extensions are likely to happen in other specifications and there is no need to update ND every time this happens. Therefore this issue is rejected. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:27:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00377 for ; Tue, 30 Mar 2004 18:27:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006a4-5a for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR0xDeZ002468 for ipv6-archive@odin.ietf.org; Wed, 26 Nov 2003 19:59:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAUr-0000aS-S8 for ipv6-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 19:59:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07270 for ; Wed, 26 Nov 2003 19:58:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APAUp-0000FJ-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 19:59:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APAUp-0000FG-00 for ipv6-web-archive@ietf.org; Wed, 26 Nov 2003 19:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAUp-0000QV-I3; Wed, 26 Nov 2003 19:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APAPq-0008Ec-6o for ipv6@optimus.ietf.org; Wed, 26 Nov 2003 19:53:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07026 for ; Wed, 26 Nov 2003 19:53:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APAPo-00008w-00 for ipv6@ietf.org; Wed, 26 Nov 2003 19:53:52 -0500 Received: from woozle.fnal.gov ([131.225.9.22]) by ietf-mx with esmtp (Exim 4.12) id 1APAPn-00008Q-00 for ipv6@ietf.org; Wed, 26 Nov 2003 19:53:51 -0500 Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HOZ00M01JO8H1@woozle.fnal.gov> for ipv6@ietf.org; Wed, 26 Nov 2003 18:53:12 -0600 (CST) Received: from [216.214.16.228] (na-216-214-16-228.chcg3.il.corecomm.net [216.214.16.228]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPSA id <0HOZ00EY8JSNFF@woozle.fnal.gov>; Wed, 26 Nov 2003 18:53:12 -0600 (CST) Date: Wed, 26 Nov 2003 18:53:07 -0600 From: Matt Crawford Subject: Re: routers - (was: Re: "ROUTERS" vs. "routers") In-reply-to: <3FC52E31.8050008@iprg.nokia.com> To: Fred Templin Cc: ipv6@ietf.org Message-id: <10CD5932-2074-11D8-8D67-000A95A0BF96@fnal.gov> MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <3FC4FB34.7050909@iprg.nokia.com> <3FC52E31.8050008@iprg.nokia.com> Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT On Nov 26, 2003, at 4:50 PM, Fred Templin wrote: > 139 ICMP Node Information Query [Crawford] > 140 ICMP Node Information Response [Crawford] > > I see that the Router Renumbering option is used by RFC 2894, > but does anyone know if the other options are used anywhere? > [...] > Matt, can you comment as to the availability of the Type codes? There are multiple implementations of node informations queries (and responses, of course). You could define new query types that might do what you want; I can't comment on the fit of your application to this mechanism without doing a lot of background reading. Matt Crawford -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:27:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00398 for ; Tue, 30 Mar 2004 18:27:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006ZK-Kg for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOM3bpq023093 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 17:03:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOnw-0005z5-Av for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 17:03:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05470 for ; Mon, 24 Nov 2003 17:03:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOnm-0006fq-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 17:03:27 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOOnm-0006fd-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 17:03:26 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AOOni-0000Lh-66 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 17:03:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOnO-0005fg-Hp; Mon, 24 Nov 2003 17:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOn4-0005fD-Bi for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 17:02:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05410 for ; Mon, 24 Nov 2003 17:02:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOn1-0006eC-00 for ipv6@ietf.org; Mon, 24 Nov 2003 17:02:40 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOn1-0006dV-00 for ipv6@ietf.org; Mon, 24 Nov 2003 17:02:39 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA14286; Mon, 24 Nov 2003 22:02:25 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA16450; Mon, 24 Nov 2003 22:02:24 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAOM2O330729; Mon, 24 Nov 2003 22:02:24 GMT Date: Mon, 24 Nov 2003 22:02:24 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: draft-hain-templin-ipv6-localcomm-03 comments Message-ID: <20031124220224.GI29789@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, Nov 24, 2003 at 11:44:12PM +0200, Pekka Savola wrote: > On Mon, 24 Nov 2003, Tony Hain wrote: > > Brian E Carpenter wrote: > > > ... > > > Now, I would be completely happy for us to throw away the Hain/Templin > > > draft as long as we immediately standardize the Hinden/Haberman solution. > > > But if we want to address (pun intended) the problems of the real world, > > > we cannot ignore the fact that most corporate network managers are > > > profoundly convinced of the need for private addressing. > > > > In many cases I would agree with Brian, but in this specific one we have an > > example of lost discussion from many years ago about why network managers > > 'need' a private space, and FEC0 was allocated for it. We need to document > > why Hinden/Haberman is needed to solve today's problems, so we don't end up > > arguing about it 5 years from now. > > If you know the result in advance, why bother to write a > requirements/goals document? You seem to want such documents a lot when you're wearing your v6ops hat :) Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:27:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00435 for ; Tue, 30 Mar 2004 18:27:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006a4-Jj for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAjHxH004173 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:45:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1y9-000146-B4 for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:45:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11591 for ; Sat, 28 Feb 2004 05:44:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1xq-0003yM-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:44:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1wt-0003qI-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:43:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1vz-0003iA-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1w0-0000cE-L5; Sat, 28 Feb 2004 05:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1v9-0000Xm-M8 for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:42:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11428 for ; Sat, 28 Feb 2004 05:42:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1v6-0003am-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:42:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1uA-0003St-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:41:10 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1tN-0003Ko-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:40:21 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1tO-000DIc-BO for ipv6@ietf.org; Sat, 28 Feb 2004 10:40:22 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #269 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #269] Deprecated Address Handling In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:40:22 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 No objection to the proposed resolution, and the issue is closed. Please revisit the issue if you have a different opinion. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:27:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00540 for ; Tue, 30 Mar 2004 18:27:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006a4-Hd for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAjH9A004158 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:45:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1y8-000145-PB for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:45:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11588 for ; Sat, 28 Feb 2004 05:44:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1xq-0003yH-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:44:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1ws-0003qA-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:43:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1vz-0003i3-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1vx-0000Z7-IH; Sat, 28 Feb 2004 05:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1v8-0000Xe-2V for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:42:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11425 for ; Sat, 28 Feb 2004 05:42:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1v4-0003aV-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:42:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1u9-0003Sl-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:41:10 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1tM-0003Ki-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:40:20 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1tN-000DIM-ND for ipv6@ietf.org; Sat, 28 Feb 2004 10:40:21 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #269 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #269] Deprecated Address Handling In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:40:21 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 No objection to the proposed resolution, and the issue is closed. Please revisit the issue if you have a different opinion. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:27:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00578 for ; Tue, 30 Mar 2004 18:27:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006WI-6X for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19CLFTA010020 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 07:21:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAPb-0002bX-2D for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 07:21:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14968 for ; Mon, 9 Feb 2004 07:21:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqAPa-00069h-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:21:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqAOh-00062S-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:20:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqAO2-0005vc-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:19:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAMU-0001JM-Rq; Mon, 09 Feb 2004 07:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq3Jp-0002gm-A3 for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 23:46:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17486 for ; Sun, 8 Feb 2004 23:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq3Jn-0006Mz-00 for ipv6@ietf.org; Sun, 08 Feb 2004 23:46:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq3Iv-0006Is-00 for ipv6@ietf.org; Sun, 08 Feb 2004 23:45:54 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Aq3IK-0006Dk-00 for ipv6@ietf.org; Sun, 08 Feb 2004 23:45:17 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Aq3IL-000OED-Ik for ipv6@ietf.org; Mon, 09 Feb 2004 04:45:17 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #276 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #276] Possible DoS Attacks In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Mon, 09 Feb 2004 04:45:17 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Proposed Resolution: do nothing for this. Reason: this is actually a non issue (see the previous comment on the trucker). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:28:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00604 for ; Tue, 30 Mar 2004 18:28:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjM-0006a4-Nx for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO9AgJM015149 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 04:10:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCju-0003vz-LH for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 04:10:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00727 for ; Mon, 24 Nov 2003 04:10:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOCjr-0000si-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 04:10:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOCjr-0000sf-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 04:10:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCjU-0003jf-I6; Mon, 24 Nov 2003 04:10:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCj7-0003eg-SO for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 04:09:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00689 for ; Mon, 24 Nov 2003 04:09:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOCj5-0000rl-00 for ipv6@ietf.org; Mon, 24 Nov 2003 04:09:47 -0500 Received: from 227.cust7.nsw.dsl.ozemail.com.au ([203.102.234.227] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AOCj4-0000rh-00 for ipv6@ietf.org; Mon, 24 Nov 2003 04:09:46 -0500 Received: from Dupy2.nosense.org (227.cust7.nsw.dsl.ozemail.com.au [203.102.234.227]) by nosense.org (Postfix) with SMTP id 9A9383F07B; Mon, 24 Nov 2003 19:40:30 +1030 (CST) Date: Mon, 24 Nov 2003 19:40:30 +1030 From: Mark Smith To: "EricLKlein" Cc: ericlklein@softhome.net, ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) Message-Id: <20031124194030.7cd122b7.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: <005d01c3b269$2b0f9ea0$ec061eac@ttitelecom.com> References: <001201c3b255$76922780$ec061eac@ttitelecom.com> <20031124083756.GB16883@login.ecs.soton.ac.uk> <005d01c3b269$2b0f9ea0$ec061eac@ttitelecom.com> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 24 Nov 2003 10:58:43 +0200 "EricLKlein" wrote: > Tim Chown wrote > > > > It is not unlikely that people will be lazy and just use fd00::/48 for > sites, > > and thus add back in great ambiguity to the probabilisticly unique address > > space. > > First you ask a question, and then answer it. I am concerned that the many > network "experts" out there that are trained in a 2 week certification > course will take what is taught to them as an example and will make it > gospel, and thus use the exact same addresses in multiple networks in close > geographic proximity, and thus on the same Carrier edge router. Consider > what happens when a carrier implements IPv6 in a city, and suddenly there > are 10 companies connected by inexperienced network "experts" (and they have > the certificate to prove it) that all follow the exact same course > "template". Now this one carrier edge router is connected to 10 incorrectly > configured routers all using the exact same "probabilistically unique > address". this is where the original need for RFC1918 came from. That is an education problem, not a technical one. They weren't taught what they needed, or should have expected to be taught. They need to ask their training provider for their money back. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:28:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00650 for ; Tue, 30 Mar 2004 18:28:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjM-0006WI-Up for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAe8CF031528 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:40:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1t9-0008CP-60 for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:40:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11305 for ; Sat, 28 Feb 2004 05:40:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1t5-0003I9-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:40:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1sD-00039o-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:39:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1rP-00030v-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:38:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1qB-0007EZ-5H; Sat, 28 Feb 2004 05:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1pO-0006tr-VA for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:36:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11040 for ; Sat, 28 Feb 2004 05:36:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1pH-0002j4-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:36:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1oR-0002cH-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:35:16 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1nv-0002Uu-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:34:43 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1nx-000CZh-11 for ipv6@ietf.org; Sat, 28 Feb 2004 10:34:45 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #267 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #267] Site Local Addresses In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:34:45 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 An editorial fix. This issue is now closed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:28:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00690 for ; Tue, 30 Mar 2004 18:28:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006WI-0M for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAeB3b031560 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1tC-0008Cv-AA for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:40:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11308 for ; Sat, 28 Feb 2004 05:40:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1t8-0003Ie-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:40:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1sE-0003A4-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:39:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1rP-000314-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:38:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1qE-0007Hj-Df; Sat, 28 Feb 2004 05:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1pO-0006tu-US for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:36:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11049 for ; Sat, 28 Feb 2004 05:36:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1pK-0002jW-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:36:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1oT-0002cf-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:35:18 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1nw-0002Uy-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:34:44 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1nx-000CZv-Lv for ipv6@ietf.org; Sat, 28 Feb 2004 10:34:45 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #267 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #267] Site Local Addresses In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:34:45 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 An editorial fix. This issue is now closed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:28:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00771 for ; Tue, 30 Mar 2004 18:28:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjM-0006WI-Sn for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAcHds030255 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:38:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1rJ-0007eY-2J for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:38:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11151 for ; Sat, 28 Feb 2004 05:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1rD-0002zD-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1qK-0002rR-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:37:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1pn-0002kT-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:36:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1pD-0006eF-FN; Sat, 28 Feb 2004 05:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1oD-0006MU-3s for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:35:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10918 for ; Sat, 28 Feb 2004 05:34:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1o9-0002Zb-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:34:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1nA-0002SC-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:33:57 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1mD-0002LP-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:32:57 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1mE-000CIr-8u for ipv6@ietf.org; Sat, 28 Feb 2004 10:32:58 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #266 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #266] Stored Lifetime In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:32:58 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is an editorial fix, and was approved by Pekka Savola who originally raised the issue. This issue is now closed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:28:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00892 for ; Tue, 30 Mar 2004 18:28:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjM-0006a4-Lf for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SAcHeE030258 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 05:38:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1rJ-0007ej-2L for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 05:38:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11154 for ; Sat, 28 Feb 2004 05:38:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1rE-0002zH-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:38:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1qK-0002ra-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:37:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1po-0002kU-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 05:36:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1pF-0006gG-R2; Sat, 28 Feb 2004 05:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1oE-0006Mj-CE for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 05:35:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10923 for ; Sat, 28 Feb 2004 05:34:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1oA-0002Zl-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:34:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1nB-0002SR-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:33:58 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ax1mE-0002LY-00 for ipv6@ietf.org; Sat, 28 Feb 2004 05:32:58 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Ax1mF-000CL6-7z for ipv6@ietf.org; Sat, 28 Feb 2004 10:32:59 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #266 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #266] Stored Lifetime In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Sat, 28 Feb 2004 10:32:59 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is an editorial fix, and was approved by Pekka Savola who originally raised the issue. This issue is now closed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:29:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00930 for ; Tue, 30 Mar 2004 18:29:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjM-0006a4-Eu for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19CLHvx010052 for ipv6-archive@odin.ietf.org; Mon, 9 Feb 2004 07:21:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAPd-0002c3-4L for ipv6-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 07:21:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14974 for ; Mon, 9 Feb 2004 07:21:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqAPc-00069z-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:21:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqAOi-00062m-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:20:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqAO3-0005vg-00 for ipv6-web-archive@ietf.org; Mon, 09 Feb 2004 07:19:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqAMT-0001JA-JT; Mon, 09 Feb 2004 07:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq3Jo-0002gh-Mr for ipv6@optimus.ietf.org; Sun, 08 Feb 2004 23:46:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17483 for ; Sun, 8 Feb 2004 23:46:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq3Jm-0006Mu-00 for ipv6@ietf.org; Sun, 08 Feb 2004 23:46:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq3Iv-0006Ik-00 for ipv6@ietf.org; Sun, 08 Feb 2004 23:45:53 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Aq3IK-0006Di-00 for ipv6@ietf.org; Sun, 08 Feb 2004 23:45:16 -0500 Received: from www by psg.com with local (Exim 4.30; FreeBSD) id 1Aq3IK-000OE2-Ty for ipv6@ietf.org; Mon, 09 Feb 2004 04:45:16 +0000 X-RT-Original-Encoding: utf-8 Message-Id: From: rt+ipv6-2462bis@rt.psg.com RT-Ticket: psg.com #276 X-Mailer: Perl5 Mail::Internet v1.60 Reply-To: rt+ipv6-2462bis@rt.psg.com CC: ipv6@ietf.org RT-Originator: jinmei@isl.rdc.toshiba.co.jp X-RT-Loop-Prevention: psg.com Content-Type: text/plain; charset="utf-8" Subject: [psg.com #276] Possible DoS Attacks In-Reply-To: Managed-BY: RT 3.0.8 (http://www.bestpractical.com/rt/) Precedence: bulk MIME-Version: 1.0 Date: Mon, 09 Feb 2004 04:45:16 +0000 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Proposed Resolution: do nothing for this. Reason: this is actually a non issue (see the previous comment on the trucker). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:29:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00958 for ; Tue, 30 Mar 2004 18:29:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjM-0006a4-1e for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TKPTIW032727 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 15:25:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwsi-0008Va-Fv for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 15:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04141 for ; Wed, 29 Oct 2003 15:25:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwsa-0002Y2-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 15:25:20 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEwsZ-0002Xy-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 15:25:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwsM-0008Hy-3L; Wed, 29 Oct 2003 15:25:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwrm-0008BM-0h for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 15:24:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04123 for ; Wed, 29 Oct 2003 15:24:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwrk-0002XF-00 for ipv6@ietf.org; Wed, 29 Oct 2003 15:24:28 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AEwrj-0002Wc-00 for ipv6@ietf.org; Wed, 29 Oct 2003 15:24:28 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9TKMka13024; Wed, 29 Oct 2003 12:22:46 -0800 X-mProtect: <200310292022> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBRTYHb; Wed, 29 Oct 2003 12:22:44 PST Message-ID: <3FA022D5.2070705@iprg.nokia.com> Date: Wed, 29 Oct 2003 12:28:05 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" CC: Markku Savela , suresh.krishnan@ericsson.ca, john.loughney@nokia.com, jari.arkko@kolumbus.fi, Alain.Durand@sun.com, ipv6@ietf.org Subject: Re: RFC 2460 issue References: <9C422444DE99BC46B3AD3C6EAFC9711B051222D1@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bound, Jim wrote: >I believe same as Savela here. Pretty obvious to me. >/jim > Yep - same here. Fred ftemplin@iprg.nokia.com >>-----Original Message----- >>From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On >>Behalf Of Markku Savela >>Sent: Tuesday, October 28, 2003 3:21 PM >>To: suresh.krishnan@ericsson.ca >>Cc: john.loughney@nokia.com; jari.arkko@kolumbus.fi; >>Alain.Durand@Sun.COM; ipv6@ietf.org >>Subject: Re: RFC 2460 issue >> >> >> >> >> >>>Off the top of my head I know that RFC3493 needs to be >>> >>> >>updated since >> >> >>>the IPV6_UNICAST_HOPS socket option now accepts 0 as a valid hop >>>count. I really do not understand what a hop count of 0 implies and >>>why we should bother updating the RFCs. >>> >>> >>Heh, yes. I too wondered about what I should do if >>application sets TTL = 0. There are two choices >> >> a) Packets go to /dev/null (perhaps some obscure testing feature?) >> >> b) Just let packets with TTL=0 go out. >> >>I chose (b), because >> >> - TTL is naturally checked only on fowarding, not when sending >> own packets out. Thus, any TTL just gets accepted and sent. >> >>If packet with TTL=0 is for this node, it is accepted (again, >>because TTL test is only for forwarding). >> >>Forwarding decrements TTL and if result is 0 or < 0, packet >>dropped (with appropriate ICMP if needed). >> >>I'm happy with above semantics. I don't see any need to worry >>about it too much. >> >> >>-------------------------------------------------------------------- >>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 exim@www1.ietf.org Tue Mar 30 18:29:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00977 for ; Tue, 30 Mar 2004 18:29:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjM-0006WI-5U for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCPRcK001880 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 08:25:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI3L-0000IT-1j for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:25:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05186 for ; Wed, 22 Oct 2003 08:24:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACI30-0004HE-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACI2z-0004H4-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI25-00083E-Ry; Wed, 22 Oct 2003 08:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGwL-0001ll-KY for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 07:14:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03637 for ; Wed, 22 Oct 2003 07:13:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGwL-0003kQ-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:14:09 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1ACGwK-0003jX-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:14:08 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9MBDaV08814 for ; Wed, 22 Oct 2003 04:13:36 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9MBFqtX000383 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 Oct 2003 04:15:55 -0700 Message-ID: <3F96664E.2080909@innovationslab.net> Date: Wed, 22 Oct 2003 07:13:18 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" References: <3F96629C.1090809@innovationslab.net> In-Reply-To: <3F96629C.1090809@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please ignore this message. The correct Last Call announcement is in a separate message. Brian Brian Haberman wrote: > This is a IPv6 working group last call for comments on advancing the > following document as an Proposed Standard: > > Title : Deprecating Site Local Addresses > Author(s) : C. Huitema, B. Carpenter > Filename : draft-ietf-ipv6-deprecate-site-local-01.txt > Pages : 10 > Date : 2003-10-13 > > Please send substantive comments to the ipv6 mailing list, and minor > editorial comments to the authors. This last call period will end on 4 > November 2003. > > Brian Haberman / Bob Hinden > IPv6 W.G. Chairs > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:29:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01013 for ; Tue, 30 Mar 2004 18:29:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjM-0006WI-3b for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCPQuK001873 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 08:25:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI3K-0000L8-Lm for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:25:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05194 for ; Wed, 22 Oct 2003 08:24:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACI32-0004HP-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACI2z-0004H5-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI28-00083c-5R; Wed, 22 Oct 2003 08:24:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGxA-0001sQ-EJ for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 07:15:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03658 for ; Wed, 22 Oct 2003 07:14:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGx9-0003kv-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:15:00 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1ACGx8-0003ke-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:14:59 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9MBERV08820 for ; Wed, 22 Oct 2003 04:14:27 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9MBGgtX000386 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 Oct 2003 04:16:46 -0700 Message-ID: <3F966680.7030106@innovationslab.net> Date: Wed, 22 Oct 2003 07:14:08 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" References: <3F96648C.6050302@innovationslab.net> In-Reply-To: <3F96648C.6050302@innovationslab.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please ignore this message. The correct Last Call announcement is in a separate message. Brian Brian Haberman wrote: > This is a IPv6 working group last call for comments on advancing the > following document as an Proposed Standard: > > Title : IPv6 Scoped Address Architecture > Author(s) : S. Deering et al. > Filename : draft-ietf-ipv6-scoping-arch-00.txt > Pages : 22 > Date : 2003-6-24 > > Please send substantive comments to the ipv6 mailing list, and minor > editorial comments to the authors. This last call period will end on 4 > November 2003. > > Brian Haberman / Bob Hinden > IPv6 W.G. Chairs > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:30:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01214 for ; Tue, 30 Mar 2004 18:30:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjL-0006WI-IY for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A0N0To023989 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 19:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rUy-0006Eo-Gm for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 19:23:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09091 for ; Tue, 9 Mar 2004 19:22:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0rUx-0003kH-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 19:22:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0rU1-0003Z7-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 19:22:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0rT3-0003Oy-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 19:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rT4-0005r4-Lc; Tue, 09 Mar 2004 19:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rS6-0005eV-Rn for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 19:20:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08944 for ; Tue, 9 Mar 2004 19:19:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0rS5-0003FI-00 for ipv6@ietf.org; Tue, 09 Mar 2004 19:20:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0rRF-00036R-00 for ipv6@ietf.org; Tue, 09 Mar 2004 19:19:10 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B0rQe-0002u0-00 for ipv6@ietf.org; Tue, 09 Mar 2004 19:18:33 -0500 content-class: urn:content-classes:message Subject: RE: Multiple DRs on a link Date: Tue, 9 Mar 2004 19:17:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Multiple DRs on a link X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQGEkHlL2Yriuw/RTapQwl05+toJAAIXWqQ From: "Soliman Hesham" To: "Mattias Pettersson" , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > So the question is: am I correct to regard this scenario as=20 > broken and=20 > say it should not be encouraged?=20 =3D> Apparently, yes. We had this discussion in nemo some time=20 ago. It's unfortunate that this situation is not made clear in the current specs. I also think that nobody=20 > plans to build=20 > fixed networks like this, just for these reasons. However,=20 > people may=20 > want to build NEMO-type of networks just like this, as it is=20 > convenient=20 > when mobile routers are rather independent, they come and=20 > go, and each=20 > connects to one ISP and each only advertises a prefix from its ISP.=20 =3D> Even if they connect to the same ISP, each MR is likely to advertise a different home prefix. > Awkwardly, then it is more important than ever that the=20 > mobile routers=20 > are cooperating otherwise legacy IPv6 hosts won't be able to=20 > get plain=20 > connectivity. =3D> It might be better to require the MRs to be aware of each others' existence and forward traffic with Pa as a src to Ra and vice versa. Hesham >=20 > /Mattias >=20 >=20 >=20 >=20 >=20 > This communication is confidential and intended solely for=20 > the addressee(s). Any unauthorized review, use, disclosure=20 > or distribution is prohibited. If you believe this message=20 > has been sent to you in error, please notify the sender by=20 > replying to this transmission and delete the message without=20 > disclosing it. Thank you. >=20 > E-mail including attachments is susceptible to data=20 > corruption, interruption, unauthorized amendment, tampering=20 > and viruses, and we only send and receive e-mails on the=20 > basis that we are not liable for any such corruption,=20 > interception, amendment, tampering or viruses or any=20 > consequences thereof. >=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 exim@www1.ietf.org Tue Mar 30 18:30:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01222 for ; Tue, 30 Mar 2004 18:30:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjK-0006a4-0L for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIASusQ003848 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 05:28:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM36L-0000zk-93 for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 05:28:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13212 for ; Tue, 18 Nov 2003 05:28:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM36H-00028d-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:28:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM36G-00028U-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:28:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM34c-0000Fe-O3; Tue, 18 Nov 2003 05:27:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM0El-0005gW-6P for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 02:25:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08423 for ; Tue, 18 Nov 2003 02:25:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM0Eh-0007Fd-00 for ipv6@ietf.org; Tue, 18 Nov 2003 02:25:19 -0500 Received: from h007.c001.snv.cp.net ([209.228.32.121] helo=c001.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AM0Eg-0007Fa-00 for ipv6@ietf.org; Tue, 18 Nov 2003 02:25:18 -0500 Received: (cpmta 2263 invoked from network); 17 Nov 2003 23:25:18 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.121) with SMTP; 17 Nov 2003 23:25:18 -0800 X-Sent: 18 Nov 2003 07:25:18 GMT Message-ID: <00a701c3ada5$4616e320$ec061eac@ttitelecom.com> From: "EricLKlein" To: "Brian E Carpenter" Cc: References: <4.3.2.7.2.20031113151322.03379ef8@mailhost.iprg.nokia.com> <3FB42CFF.2020105@it.su.se> <003d01c3ad0d$4d8a1160$ec061eac@ttitelecom.com> <3FB8E7F3.5A41C5E1@zurich.ibm.com> Subject: Re: SL deprecation draft Date: Tue, 18 Nov 2003 09:26:23 +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.2720.3000 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > While I'd personally love to declare RFC 1918 "Historic", it really is > completely IPv4 specific so we have no reason to reference it. I would agree that RFC1918 is pure v4 issue, but we will need take into account that when these IPv4 networks are connected as part of IPv6 networks we could get flooded with a lot of the ::10.x.x.x addresses that are supposed to be "site local" under IPv4, but are now neither site local nor unique under IPv6. This is where we need to put in text in the Depriciation document, othewise we will end up with a lot of congestion and leakage from what used to be behind NATv4 or just local RFC1918 local site addresses. > > Where can I find the NATv6 group? I have a few things I'd like to > say to them... It looks like v6ops@ops.ietf.org or ngtrans@ops.ietf.org the group working on the NAT issues. > > Brian > > EricLKlein wrote: > > > > I think the most basic RFC one was missed from the list: RFC1918. Especially > > since the NATv6 group is probably working under the presumptions that these > > addresses, or ones like them, still exist in IPv6. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:30:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01319 for ; Tue, 30 Mar 2004 18:30:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjK-0006WI-TQ for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO8cVHc005698 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 03:38:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCEl-0001QY-62 for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 03:38:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29913 for ; Mon, 24 Nov 2003 03:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOCEf-0000WU-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 03:38:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOCEf-0000WO-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 03:38:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCEN-0001Fn-Pl; Mon, 24 Nov 2003 03:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOCEJ-0001FY-HB for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 03:37:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29904 for ; Mon, 24 Nov 2003 03:37:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOCEH-0000WB-00 for ipv6@ietf.org; Mon, 24 Nov 2003 03:37:57 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOCEG-0000W8-00 for ipv6@ietf.org; Mon, 24 Nov 2003 03:37:56 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA22210 for ; Mon, 24 Nov 2003 08:37:56 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA08494 for ; Mon, 24 Nov 2003 08:37:56 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAO8bue17099 for ipv6@ietf.org; Mon, 24 Nov 2003 08:37:56 GMT Date: Mon, 24 Nov 2003 08:37:56 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Local addresses and security? (was: SL deprecation draft) Message-ID: <20031124083756.GB16883@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <001201c3b255$76922780$ec061eac@ttitelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201c3b255$76922780$ec061eac@ttitelecom.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, Nov 24, 2003 at 08:37:39AM +0200, EricLKlein wrote: > > I am still have 2 concerns with these concepts: > 1. People do not want to register their secure internal network nodes (bank > central computes etc) so the "registered unique local addreses" may not meet > their needs. They do not want to have even theoritically reachable addresses > on a Cash machine or other secure node that needs to be connected as part of > the private network. So they can use addresses from the probabilistically unique range under the space fd00::/8. There is, in terms of raw usage, no difference between using fd00::/8 or fec0::/10. External networks would still have to route the prefixes back to you for you to be reachable, which is just as hard/easy under either system. > 2. For the "approxiamtely" or "probably" unique local addresses I am > concerned that these addresses will eventually be assigned as part of the > registered addresses and can then be in conflict with "legitimate" nodes. No, the registered address space is under fc00::/8. The two spaces are distinct, as per section 3.2 of http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-01.txt It'll be many, many years before additional space needs to be allocated for these local address types. > So between the 2, I do not see a solution that will work better than a > RFC1918 type of address space. The more I hear about these options the more > I want to bring back site local addresses. Well, addresses under fd00::/8 and fd00::/8 can be used locally just like site-local addresses, only they have the nice property of significantly reduced (probabilisticly unique) or complete removal of (registered unique) ambiguity, so I don't see where your concern is? It is not unlikely that people will be lazy and just use fd00::/48 for sites, and thus add back in great ambiguity to the probabilisticly unique address space. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:31:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01445 for ; Tue, 30 Mar 2004 18:31:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjJ-0006YH-DK for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEdBVx027821 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:39:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpxd-0007ED-1U for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:39:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06377 for ; Thu, 20 Nov 2003 09:38:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpxb-0003x8-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:39:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpxa-0003x3-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:39:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpwg-0006mr-Az; Thu, 20 Nov 2003 09:38:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpwM-0006gn-QE for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 09:37:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06301 for ; Thu, 20 Nov 2003 09:37:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpwK-0003ve-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:37:49 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMpwK-0003up-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:37:48 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 Nov 2003 06:37:50 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAKEbEAt011320; Thu, 20 Nov 2003 06:37:15 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-332.cisco.com [10.82.225.76]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AED19368; Thu, 20 Nov 2003 09:37:12 -0500 (EST) Message-Id: <4.3.2.7.2.20031120092906.01ed4fb8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Nov 2003 09:37:10 -0500 To: Soliman Hesham From: Ralph Droms Subject: RE: Node Req: Issue31: DHCPv6 text (ignore previous mails) Cc: john.loughney@nokia.com, ipv6@ietf.org In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F042015@ftmail.lab.flarion. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hesham, At 09:27 AM 11/20/2003 -0500, Soliman Hesham wrote: > > I strongly suggest the use of "Nodes" (unqualified) in the text > > about the 'O' bit: > >=> To be clear, I was suggesting substitusting "Nodes (acting as hosts)". >I'm not sure if you're replying to my comment or in general. Thanks for the clarification; I don't think I precisely understood your substitution. And, now that I think about the problem a little more carefully, esp. after reading the text you cite below from RFC 2461 (thanks for looking up the reference), I've convinced myself the problem is a little more complicated than I thought at first glance. In the case of routers, I think the 'M' and 'O' bits should be used conditionally based on configuration in the router. That is, I can imagine situations in which an operator would want to control the behavior of several routers on a link through the 'M' and 'O' bits, while in other situations an operator would want to configure each router manually, ignoring the 'M' and 'O' bits... > > However, there is some question about any discussion of "nodes" and > > RAs, as there may be text in RFC 2461 (I'm working from > > memory, here, which > > in my case is a remarkably unreliable service; I hope > > someone more familiar > > with RFC 2461 can confirm or deny) that allows or requires > > routers to ignore RAs. > >=> In 6.2.7 : > > Routers SHOULD inspect valid Router Advertisements sent by other > routers and verify that the routers are advertising consistent > information on a link. Detected inconsistencies indicate that one or > more routers might be misconfigured and SHOULD be logged to system or > network management. The minimum set of information to check > includes: > > - Cur Hop Limit values (except for the unspecified value of zero). > > - Values of the M or O flags. > > - Reachable Time values (except for the unspecified value of zero). > >Whether that means routers can also act upon the information >they receive is of course a separate issue. But at least >it is clear that routers are not required to automatically drop RAs. > >Hesham > > > > > > > > > - Ralph > > > > At 09:06 AM 11/20/2003 -0500, Soliman Hesham wrote: > > > > > > > > Is there a reason to differentiate between nodes acting as > > > > hosts here, but > > > > not in the paragraph describing the behavior in response to > > > > the 'M' bit? > > > > > >=> In general, unless previously discussed and rejected for some > > >reason, I'd globally: s/Nodes (acting as hosts)/host > > > > > >It's a bit clumsy to read as it is. > > > > > >Hesham > > > > > > -------------------------------------------------------------------- > > 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 exim@www1.ietf.org Tue Mar 30 18:31:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01454 for ; Tue, 30 Mar 2004 18:31:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjI-0006WI-MK for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RIeAA8005113 for ipv6-archive@odin.ietf.org; Mon, 27 Oct 2003 13:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECHh-0001IR-KO for ipv6-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 13:40:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29327 for ; Mon, 27 Oct 2003 13:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECHf-0001lS-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 13:40:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AECHe-0001lP-00 for ipv6-web-archive@ietf.org; Mon, 27 Oct 2003 13:40:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECHc-0001BW-LP; Mon, 27 Oct 2003 13:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECHU-0001Ac-CY for ipv6@optimus.ietf.org; Mon, 27 Oct 2003 13:39:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29317 for ; Mon, 27 Oct 2003 13:39:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECHS-0001lF-00 for ipv6@ietf.org; Mon, 27 Oct 2003 13:39:54 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AECHR-0001ki-00 for ipv6@ietf.org; Mon, 27 Oct 2003 13:39:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h9RId8J14977; Mon, 27 Oct 2003 10:39:08 -0800 X-mProtect: <200310271839> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBZLPb7; Mon, 27 Oct 2003 10:39:06 PST Message-ID: <3F9D6780.50605@iprg.nokia.com> Date: Mon, 27 Oct 2003 10:44:16 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: "Bound, Jim" , Iljitsch van Beijnum , ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Pekka, However, I believe protocol designers/implementors would appreciate the flexibility afforded by a new option type. Fred ftemplin@iprg.nokia.com Pekka Savola wrote: >On Sat, 25 Oct 2003, Bound, Jim wrote: > > >>I believe there is another option. Develop new spec that does number 3 >>below to add to 2461 and leave 2461 alone. This would be a spec >>defining a new option for 2461. >> >> > >Or, even define the new interpretation for MTU over NA messages in a >separate spec and leave RFC 2461 untouched...? > > > >>>-----Original Message----- >>>From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On >>>Behalf Of Fred Templin >>>Sent: Friday, October 24, 2003 9:06 PM >>>To: Iljitsch van Beijnum >>>Cc: ipv6@ietf.org >>>Subject: Re: "RFC 2461bis" issue: MTU handling >>> >>> >>>I see (at least) three ways for the neighbor-to-neighbor MTU >>>negotiation; two were presented in my drafts and the third is >>>presented by Iljitsch here. The methods are: >>> >>> 1) Change RFC 2461 to allow NA messages to include MTU options: >>> Advantages: >>> - Unambiguous mechanism for NA's to inform of a >>>per-neighbor MTU value >>> Disadvantages: >>> - Requires modification to RFC 2461 >>> - May require extra ND messages, since the interpretation of >>> MTU options is different for RAs >>> >>> 2) No changes to RFC 2461; allow "IPv6-over-foo" documents to >>> specify different interpretations of the MTU option in RA's: >>> Advantages: >>> - No modifications to RFC 2461 >>> Disadvantages: >>> - Ambiguous interpretation of MTU options in RAs, or the >>> specified interpretation (MTU for the entire link) is disabled >>> - MTU option only available for RAs; not NAs >>> >>> 3) Change RFC 2461 to specify a new "NBR_MTU" option that >>> can be sent with either NA's or RAs: >>> Advantages: >>> - Unambiguous mechanism to inform of a per-neighbor MTU value >>> - Can be used with either NAs or RAs w/o altering the >>>interpretation >>> of the existing MTU option >>> - Maximum efficiency, since it can be used with either >>>NAs or RAs >>> Disadvantages: >>> - Requires modifications to RFC 2461 >>> >>>So, it should be clear from the above analysis that I support >>>Iljitsch's proposal in terms of what should go into RFC 2461. >>>It is a sensible approach for a valuable mechanism and I >>>think folks should give it the consideration it deserves. >>> >>>Fred >>>ftemplin@iprg.nokia.com >>> >>>Iljitsch van Beijnum wrote: >>> >>> >>> >>>>I'm not sure this should go into a replacement specification for RFC >>>>2461, but I'll bring it up anyway: >>>> >>>>Currently, routers can advertise an MTU for a link. That's nice. But >>>>what we really need is a way for hosts to find out the MTU each >>>>individual neighbor can handle. 100 Mbps and slower ethernet >>>>interfaces can typically handle only the standard 1500 byte >>>> >>>> >>>ethernet >>> >>> >>>>MTU, while gigabit ethernet interfaces usually support a >>>> >>>> >>>much larger MTU. >>> >>> >>>>However, in most cases hosts with different MTUs are present on the >>>>same subnet, so simply advertising a larger MTU wouldn't >>>> >>>> >>>solve this. >>> >>> >>>>(Not that this would work anyway as hosts are instructed to only >>>>listen to MTU advertisements where the MTU is between 1280 and 1500 >>>>(for ethernet).) >>>> >>>>But if hosts can tell each other the MTU they support, each >>>> >>>> >>>set of two >>> >>> >>>>hosts is always able to use the largest possible MTU between them. >>>>(This would also require a new link MTU option that conveys the >>>>maximum MTU the lower layer equipment supports. Switches have their >>>>own MTU and even some hubs start doing strange things when a larger >>>>than expected MTU is used.) >>>> >>>>BTW, some duplication seems to have crept into the document: >>>> >>>> variable MTU - a link that does not have a >>>> >>>> >>>well-defined MTU (e.g., >>> >>> >>>> IEEE 802.5 token rings). Many links (e.g., >>>> Ethernet) have a standard MTU defined >>>> >>>> >>>by the link- >>> >>> >>>> layer protocol or by the specific document >>>> describing how to run IP over the link layer. >>>> >>>> variable MTU - Neighbor Discovery allows routers to >>>> >>>> >>>specify a MTU >>> >>> >>>> for the link, which all nodes then >>>> >>>> >>>use. All nodes >>> >>> >>>> on a link must use the same MTU (or Maximum >>>> Receive Unit) in order for multicast to work >>>> properly. Otherwise when >>>> >>>> >>>multicasting a sender, >>> >>> >>>> which can not know which nodes will >>>> >>>> >>>receive the >>> >>> >>>> packet, could not determine a minimum >>>> >>>> >>>packet size >>> >>> >>>> all receivers can process. >>>> >>>> >>>>-------------------------------------------------------------------- >>>>IETF IPv6 working group mailing list >>>>ipv6@ietf.org >>>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>>-------------------------------------------------------------------- >>>> >>>> >>> >>> >>>-------------------------------------------------------------------- >>>IETF IPv6 working group mailing list >>>ipv6@ietf.org >>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>-------------------------------------------------------------------- >>> >>> >>> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >> >> >> > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:31:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01614 for ; Tue, 30 Mar 2004 18:31:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjJ-0006YH-4t for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i296eJpJ009851 for ipv6-archive@odin.ietf.org; Tue, 9 Mar 2004 01:40:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0auY-0002YZ-O7 for ipv6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 01:40:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26784 for ; Tue, 9 Mar 2004 01:40:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0auV-0001av-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 01:40:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0atf-0001RQ-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 01:39:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0ass-0001IX-00 for ipv6-web-archive@ietf.org; Tue, 09 Mar 2004 01:38:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0asL-0001sf-T9; Tue, 09 Mar 2004 01:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0arj-0001dF-3V for ipv6@optimus.ietf.org; Tue, 09 Mar 2004 01:37:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26619 for ; Tue, 9 Mar 2004 01:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0arg-00017I-00 for ipv6@ietf.org; Tue, 09 Mar 2004 01:37:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0aqq-0000xm-00 for ipv6@ietf.org; Tue, 09 Mar 2004 01:36:29 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0aqL-0000mz-00 for ipv6@ietf.org; Tue, 09 Mar 2004 01:35:57 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i296Yv804562; Tue, 9 Mar 2004 08:34:57 +0200 Date: Tue, 9 Mar 2004 08:34:56 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Ralph Droms , Subject: Re: reference dependency (DS to PS) (Re: [rfc2462bis] M/O flags and DHCPv6) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 9 Mar 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > Jinmei - I mistyped and you guessed what I had intended to ask. Good catch > > and thanks for the clarification. > > > Can anyone supply a direct reference to an explicit statement that "a DS > > spec cannot have a normative reference to a PS spec."? > > I've not seen any responses yet...I guess we could deal with the > original issue with leaving this open, but it's still very helpful to > clarify this point to make a realistic decision. > > If no one can give a concrete pointer, I'll assume "a DS spec cannot > have a normative reference to a PS spec" for safety. I'd look at RFC2026 and draft-ymbk-downref-01.txt. Especially the latter is meant to describe the problem at some length. -- 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 exim@www1.ietf.org Tue Mar 30 18:32:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01651 for ; Tue, 30 Mar 2004 18:32:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjI-0006a4-BT for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAALhmi6023868 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 16:43:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJp6-0006Ct-I2 for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 16:43:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15035 for ; Mon, 10 Nov 2003 16:43:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJp4-0005Db-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 16:43:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJp3-0005DY-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 16:43:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJoM-0005op-FE; Mon, 10 Nov 2003 16:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJnp-0005o5-3W for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 16:42:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14945 for ; Mon, 10 Nov 2003 16:42:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJnn-0005C2-00 for ipv6@ietf.org; Mon, 10 Nov 2003 16:42:27 -0500 Received: from ns2.sea.interquest.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1AJJnm-0005Bz-00 for ipv6@ietf.org; Mon, 10 Nov 2003 16:42:26 -0500 Received: from ssprunk (ip154.post-vineyard.dfw.interquest.net [66.135.181.154]) by ns2.sea (8.12.10/8.12.5) with SMTP id hAALgLJR013990; Mon, 10 Nov 2003 13:42:22 -0800 Message-ID: <027301c3a7d3$886982a0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Alain Durand" , "Brian E Carpenter" Cc: References: <3F96659F.4040702@innovationslab.net> <3FA0351E.37C3F0CA@zurich.ibm.com> <3FA065B8.3010003@sun.com> <3FA2883A.BA6A93CA@zurich.ibm.com> <3FA2A79F.4040203@sun.com> Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Date: Mon, 10 Nov 2003 15:38:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Alain Durand" > Brian E Carpenter wrote: > >I meant PA because that is all that is in the implementors and > >registries' hands today. Actually any form of PI would do (they are > >all equally unrouteable today). I regard the Hinden/Haberman addresses > >as an easy-to-create form of PI. > > I meant traceable, potentially routable PI. Hinden/Haberman addresses > are not traceable (in the sense that looking at the prefix I can tell > who it belongs to), and this is a big difference. I also object to this part of the draft as well. IMHO, the registry should list who the registrant is for a particular prefix, but not allow non-exact searches. Reverse DNS should also be available if particular registrants want to list servers. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:32:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01669 for ; Tue, 30 Mar 2004 18:32:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjI-0006WI-BP for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFIGBUg030493 for ipv6-archive@odin.ietf.org; Mon, 15 Dec 2003 13:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVxGM-0007vb-Qv for ipv6-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 13:16:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18983 for ; Mon, 15 Dec 2003 13:16:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVxGF-0001wH-00 for ipv6-web-archive@ietf.org; Mon, 15 Dec 2003 13:16:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVxFh-0001vu-00 for ipv6-web-archive@ietf.org; Mon, 15 Dec 2003 13:15:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVxFM-0007bE-Un; Mon, 15 Dec 2003 13:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVxEM-0007YH-B0 for ipv6@optimus.ietf.org; Mon, 15 Dec 2003 13:14:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18903 for ; Mon, 15 Dec 2003 13:14:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVxEK-0001ua-00 for ipv6@ietf.org; Mon, 15 Dec 2003 13:14:04 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AVxEJ-0001ts-00 for ipv6@ietf.org; Mon, 15 Dec 2003 13:14:03 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hBFIDKN20254; Mon, 15 Dec 2003 10:13:20 -0800 X-mProtect: <200312151813> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdM31NYg; Mon, 15 Dec 2003 10:13:18 PST Message-ID: <3FDDF9BC.8040401@iprg.nokia.com> Date: Mon, 15 Dec 2003 10:13:16 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: hinden@iprg.nokia.com, ipv6@ietf.org Subject: Re: comments on draft-ietf-ipv6-addr-arch-v4-00.txt References: <20031215072640.07E70A0@coconut.itojun.org> <20031215072943.986EC93@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Last I heard, Steve Deering had gone walkabout - but surely, he must have a new e-mail address by now? Fred ftemplin@iprg.nokia.com Jun-ichiro itojun Hagino wrote: >> as an IAB i was asked to comment on draft-ietf-ipv6-addr-arch-v4-00.txt, >> so here it is. happy holidays. >> >> > > one more ;-) > >itojun > > >MINOR >===== > deering@cisco.com is no longer valid, so you may want to remove it > from the draft. > >-------------------------------------------------------------------- >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 exim@www1.ietf.org Tue Mar 30 18:32:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01755 for ; Tue, 30 Mar 2004 18:32:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjI-0006YH-BT for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACK3PtL017449 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:03:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1D3-0004XM-BK for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:03:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04704 for ; Wed, 12 Nov 2003 15:03:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1D0-0004rl-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:03:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1Cz-0004ri-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:03:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Ch-0004I8-3u; Wed, 12 Nov 2003 15:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1CH-00046h-Bn for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 15:02:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04605 for ; Wed, 12 Nov 2003 15:02:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1CE-0004pT-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:02:34 -0500 Received: from alpha2.its.monash.edu.au ([130.194.1.4]) by ietf-mx with esmtp (Exim 4.12) id 1AK1CD-0004pJ-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:02:33 -0500 Received: from localhost ([130.194.13.84]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01L2Z34BWIDA8ZRTR9@vaxc.its.monash.edu.au> for ipv6@ietf.org; Thu, 13 Nov 2003 07:02:19 +1100 Received: from blammo.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id BAF7039C003; Thu, 13 Nov 2003 07:02:19 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by blammo.its.monash.edu.au (Postfix) with ESMTP id AE8E42DC003; Thu, 13 Nov 2003 07:02:19 +1100 (EST) Date: Thu, 13 Nov 2003 07:02:19 +1100 From: Gregory Daley Subject: RFC2461 update and M/O flags. To: ipv6@ietf.org Cc: rdroms@cisco.com Message-id: <281761281a34.281a34281761@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Content-Transfer-Encoding: 7BIT Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, With reference to the roles of the M and O bits in RA messages, Jinmei mentioned that with these bits we should reference the DHCPv6 RFC. I made the statement at Wednesday's session that we may need a reference to the Stateless DHCPv6 document which is not an RFC. After talking to Ralph, I think that I was wrong about this. The stateless DHCP document specifies how to implement a stateless server which only handles a subset of messages. While these are the same messages required for the O bit, the DHCPv6 base specification supports all these message formats and will provide equivalent service for hosts interested in "Other" information even if stateful address config isn't required. So obviously a reference to RFC3315 is sufficient. Sorry about making unnecessary commotion. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:32:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01850 for ; Tue, 30 Mar 2004 18:32:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjH-0006YH-Qa for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALgMhf018720 for ipv6-archive@odin.ietf.org; Tue, 10 Feb 2004 16:42:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfeA-0004rr-5E for ipv6-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:42:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20507 for ; Tue, 10 Feb 2004 16:42:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfe8-0000WL-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 16:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfdE-0000Mx-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 16:41:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqfcW-0000En-00 for ipv6-web-archive@ietf.org; Tue, 10 Feb 2004 16:40:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqfbz-0004LR-VX; Tue, 10 Feb 2004 16:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfbW-0002IO-OP for ipv6@optimus.ietf.org; Tue, 10 Feb 2004 16:39:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20243 for ; Tue, 10 Feb 2004 16:39:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfbU-000037-00 for ipv6@ietf.org; Tue, 10 Feb 2004 16:39:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfaV-0007fT-00 for ipv6@ietf.org; Tue, 10 Feb 2004 16:38:36 -0500 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1AqfZJ-0007Qa-00 for ipv6@ietf.org; Tue, 10 Feb 2004 16:37:21 -0500 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1AqfZD-0000oZ-00 for ; Tue, 10 Feb 2004 21:37:15 +0000 Date: Tue, 10 Feb 2004 21:37:14 +0000 To: ipv6@ietf.org Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt Message-ID: <20040210213714.GA26451@fysh.org> References: <200402102029.PAA23656@ss10.danlan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402102029.PAA23656@ss10.danlan.com> User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dan Lanciani wrote: >As I recall, at one point someone set up a proof-of-concept auto-allocator >just to show how easy it was to hand out prefixes. It was shut down very >quickly. :( I'd like to know who ``requested'' this... As I recall, it was claiming to actually allocate prefixes. I don't intend to make any such unfounded claim. -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:33:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01875 for ; Tue, 30 Mar 2004 18:33:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjH-0006WI-Ah for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BANsIC028848 for ipv6-archive@odin.ietf.org; Thu, 11 Mar 2004 05:23:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1NLx-0007Uz-Ta for ipv6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 05:23:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23657 for ; Thu, 11 Mar 2004 05:23:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1NLt-00030I-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 05:23:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1NLE-0002q9-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 05:23:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1NKS-0002e1-00 for ipv6-web-archive@ietf.org; Thu, 11 Mar 2004 05:22:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1NKE-000790-Qq; Thu, 11 Mar 2004 05:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1NJz-000781-AI for ipv6@optimus.ietf.org; Thu, 11 Mar 2004 05:21:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23467 for ; Thu, 11 Mar 2004 05:21:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1NJv-0002Zt-00 for ipv6@ietf.org; Thu, 11 Mar 2004 05:21:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1NIp-0002O5-00 for ipv6@ietf.org; Thu, 11 Mar 2004 05:20:35 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1NI8-0002Ah-00 for ipv6@ietf.org; Thu, 11 Mar 2004 05:19:52 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i2BAJLj14638; Thu, 11 Mar 2004 12:19:21 +0200 Date: Thu, 11 Mar 2004 12:19:21 +0200 (EET) From: Pekka Savola To: Mukesh.Gupta@nokia.com cc: jari.arkko@kolumbus.fi, , Subject: RE: ICMPv6 echo reply to multicast packet thread In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F799CB@daebe009.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 11 Mar 2004 Mukesh.Gupta@nokia.com wrote: > I do not have any preferences here either. I agree with Pekka > that it should be either MUST or MUST NOT. Leaving it as a > SHOULD is not a good idea. > > Now, who can tell if multicast echo request is the primary > multicast debugging mechanism or not ?? It is extensively used for link-local at least, and used a bit for wider scopes as well. But IMHO the real question is this: as there are a number of ways how you could elicit this "response storm" from any node at all (e.g., using the parameter problem trick, using TCP/UDP which is bound to the wildcard address, etc.), I'm not sure if I see the need for expressly prohibiting ICMPv6 echo requests -- it would seem like (mostly) wasted effort to close one door, while leaving the other two dozen doors open. Whether there are 24 or 25 open doors doesn't really impact the overall security but only create more corner cases the implementations should get right. -- 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 exim@www1.ietf.org Tue Mar 30 18:33:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02000 for ; Tue, 30 Mar 2004 18:33:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjH-0006YH-6I for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEdBfD027811 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 09:39:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpxd-0007EK-Dn for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:39:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06379 for ; Thu, 20 Nov 2003 09:38:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpxb-0003x9-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:39:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpxa-0003x2-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 09:39:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpwa-0006jA-QD; Thu, 20 Nov 2003 09:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpwH-0006et-W0 for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 09:37:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06284 for ; Thu, 20 Nov 2003 09:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpwG-0003vN-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:37:44 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpwF-0003vK-00 for ipv6@ietf.org; Thu, 20 Nov 2003 09:37:43 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA14903 for ; Thu, 20 Nov 2003 14:37:40 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA20971 for ; Thu, 20 Nov 2003 14:37:40 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAKEbeE04654 for ipv6@ietf.org; Thu, 20 Nov 2003 14:37:40 GMT Date: Thu, 20 Nov 2003 14:37:40 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) Message-ID: <20031120143740.GB32107@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <9E3BA3946476AD4EB94672712B12A85F042015@ftmail.lab.flarion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F042015@ftmail.lab.flarion.com> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, Nov 20, 2003 at 09:27:27AM -0500, Soliman Hesham wrote: > > => In 6.2.7 : > > Routers SHOULD inspect valid Router Advertisements sent by other > routers and verify that the routers are advertising consistent > information on a link. Detected inconsistencies indicate that one or > more routers might be misconfigured and SHOULD be logged to system or > network management. The minimum set of information to check > includes: > > - Cur Hop Limit values (except for the unspecified value of zero). > > - Values of the M or O flags. > > - Reachable Time values (except for the unspecified value of zero). Presumably this means consistent RA information for the same prefix? I guess that's implicit, but it is quite possible that two prefixes will be seen, one with M bit clear and one with M bit set if you use two upstream providers with different address assignment policies? So I guess the question is what is "consistent information"? The same bits set for the same prefix? Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:33:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02048 for ; Tue, 30 Mar 2004 18:33:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjG-0006WI-SU for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SAkTV3009289 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 05:46:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERMr-0002Pk-4O for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 05:46:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15341 for ; Tue, 28 Oct 2003 05:46:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AERMn-00005z-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 05:46:25 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AERMn-00005w-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 05:46:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERMQ-00027D-J6; Tue, 28 Oct 2003 05:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERMK-00026U-Py for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 05:45:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15328 for ; Tue, 28 Oct 2003 05:45:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AERMH-000058-00 for ipv6@ietf.org; Tue, 28 Oct 2003 05:45:53 -0500 Received: from 177.cust14.nsw.dsl.ozemail.com.au ([203.102.109.177] helo=nosense.org) by ietf-mx with esmtp (Exim 4.12) id 1AERMG-00003q-00 for ipv6@ietf.org; Tue, 28 Oct 2003 05:45:52 -0500 Received: from Dupy2.nosense.org (177.cust14.nsw.dsl.ozemail.com.au [203.102.109.177]) by nosense.org (Postfix) with SMTP id 559173F017; Tue, 28 Oct 2003 21:16:15 +1030 (CST) Date: Tue, 28 Oct 2003 21:16:14 +1030 From: Mark Smith To: Erik Nordmark Cc: iljitsch@muada.com, pekkas@netcore.fi, ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling Message-Id: <20031028211614.353dd089.ipv6@c753173126e0bc8b057a22829880cf26.nosense.org> In-Reply-To: References: <05693FDE-08D5-11D8-AD90-00039388672E@muada.com> Organization: The No Sense Organisation X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 28 Oct 2003 11:36:58 +0100 (CET) Erik Nordmark wrote: > Just to restate what you are saying differently so that others might understand > it. Today with have a MTU specified in the IPv6 over foo documents. > We have an MTU option in router advertisements that can be used to > lower that number - which is useful(?) for the last century problem of > bridging Ethernet and FDDI together with half-broken fragmenting > bridges - can get the FDDI attached nodes to use 1500. > A minor note, being able to shrink the MTU on a link via a RA is would be very useful for avoiding packet fragmentation / PMTUD if the majority of traffic originating on that link is going to be encapsulated in a tunnel when going off-link eg VPN using ipsec, gre, etc. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:33:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02066 for ; Tue, 30 Mar 2004 18:33:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjH-0006WI-1L for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCPQAL001858 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 08:25:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI3K-0000LA-6F for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:25:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05201 for ; Wed, 22 Oct 2003 08:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACI32-0004HX-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACI2z-0004H6-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI1z-00081T-8G; Wed, 22 Oct 2003 08:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGtZ-0001OK-VS for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 07:11:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03596 for ; Wed, 22 Oct 2003 07:11:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGtV-0003iA-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:11:13 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1ACGtU-0003hj-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:11:12 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9MBAhV08797 for ; Wed, 22 Oct 2003 04:10:43 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9MBCutX000367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 Oct 2003 04:13:02 -0700 Message-ID: <3F96659F.4040702@innovationslab.net> Date: Wed, 22 Oct 2003 07:10:23 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a IPv6 working group last call for comments on advancing the following document as an Proposed Standard: Title : Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-unique-local-01.txt Pages : 15 Date : 2003-9-24 Please send substantive comments to the ipv6 mailing list, and minor editorial comments to the authors. This last call period will end on 5 November 2003. Brian Haberman / Bob Hinden IPv6 W.G. Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:33:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02083 for ; Tue, 30 Mar 2004 18:33:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjF-0006YH-OS for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F93Rik024838 for ipv6-archive@odin.ietf.org; Wed, 15 Oct 2003 05:03:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9hYx-0006SX-1U for ipv6-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 05:03:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21248 for ; Wed, 15 Oct 2003 05:03:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9hYs-0001XV-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 05:03:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9hYr-0001XS-00 for ipv6-web-archive@ietf.org; Wed, 15 Oct 2003 05:03:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9hXg-0006Ew-7O; Wed, 15 Oct 2003 05:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9hX2-0006BZ-4p for ipv6@optimus.ietf.org; Wed, 15 Oct 2003 05:01:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21188 for ; Wed, 15 Oct 2003 05:01:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9hWy-0001Vy-00 for ipv6@ietf.org; Wed, 15 Oct 2003 05:01:20 -0400 Received: from [202.20.142.13] (helo=ns.sait.samsung.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1A9hWx-0001VW-00 for ipv6@ietf.org; Wed, 15 Oct 2003 05:01:19 -0400 Received: from tyre (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h9F90hnV026317; Wed, 15 Oct 2003 18:00:45 +0900 (KST) Message-ID: <063401c392fb$d5dea250$e82f024b@tyre> From: "JinHyeock Choi" To: "Brian Haberman" , , , , "Nick 'Sharkey' Moore" , , References: <3F8404C6.30609@innovationslab.net> Subject: [Announce] RA issues for MD/ DNA I-D Date: Wed, 15 Oct 2003 18:07:59 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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 Content-Transfer-Encoding: base64 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBJUHY2IGdyb3VwLA0KDQpBIHdoaWxlIGFnbyB0aGVyZSB3YXMgc29tZSBkaXNjdXNzaW9u IGFib3V0IE5laWdoYm9yIERpc2NvdmVyeSBVcGRhdGUuIEdyZWcgRGFsZXkgDQphbmQgSSBjb2xs ZWN0ZWQgdGhlIFJBIGlzc3VlcyBmb3IgTW92ZW1lbnQgRGV0ZWN0aW9uLyBEZXRlY3Rpb24gb2Yg TmV0d29yayBBdHRhY2htZW50IA0KaW4gYSBkcmFmdDogDQoNClJvdXRlciBBZHZlcnRpc2VtZW50 IElzc3VlcyBmb3IgTW92ZW1lbnQgRGV0ZWN0aW9uLyBEZXRlY3Rpb24gb2YgTmV0d29yayBBdHRh Y2htZW50IA0KDQpUaGlzIGRyYWZ0IGRlc2NyaWJlcyB0aGUgcHJvYmxlbXMgd2UgZW5jb3VudGVy ZWQgd2hpbGUgd29ya2luZyBvbiBNb3ZlbWVudCBEZXRlY3Rpb24gDQphbmQgaW52ZXN0aWdhdGVz IHRoZSBwb3NzaWJsZSBzb2x1dGlvbnMuIFdlIGZvdW5kIHRoZSBpbmZvcm1hdGlvbiBpbiBSQSBp cyBub3QgYWRlcXVhdGUgZm9yIA0KZWZmaWNpZW50IE1vdmVtZW50IERldGVjdGlvbiBkdWUgdG8g aW5jb25zaXN0ZW5jeSBhbmQgaW5jb21wbGV0ZW5lc3MuIFRoZSBjb250ZW50cyBhcmU6IA0KDQox LiAgSW50cm9kdWN0aW9uDQoyLiBUaGUgUkEgSW5mb3JtYXRpb24gSXNzdWVzLyBQcm9ibGVtcw0K IDIuMSAgTGluayBsb2NhbCBzY29wZSBvZiBSb3V0ZXIgQWRkcmVzcw0KIDIuMiAgT21pc3Npb24g b2YgUHJlZml4IEluZm9ybWF0aW9uIA0KIDIuMyAgTGFjayBvZiBTb2xpY2l0YXRpb24gQWNrbm93 bGVkZ2VtZW50IA0KIDIuNCAgQW1iaWd1aXR5IG9mIE9uLWxpbmsgaW5mb3JtYXRpb24gKEwtYml0 KQ0KMy4gIFJBIG9wdGltaXplZCBmb3IgTW92ZW1lbnQgRGV0ZWN0aW9uLyBDYW5kaWRhdGUgU29s dXRpb25zDQogMy4xICBDb21wbGV0ZSBSQQ0KIDMuMiAgUkEgd2l0aCBsaW5rIGlkZW50aWZpZXIg b3B0aW9uDQoNClRoaXMgZG9jdW1lbnQgaGFzIG5vdCB5ZXQgcmVhY2hlZCB0aGUgSUQgV1dXIHNp dGUsIGJ1dCBpcyBhdmFpbGFibGUgYXQgdGhlIFVSTDoNCg0KaHR0cDovL3d3dy5jdGllLm1vbmFz aC5lZHUuYXUvaXB2Ni9kcmFmdC1qaW5jaG9pLWlwdjYtY1JBLTAwLnR4dA0KDQpXZSBhcmUgbG9v a2luZyBmb3J3YXJkIHRvIHlvdSBmZWVkYmFjay4NCg0KQmVzdCBSZWdhcmRzDQoNCkppbkh5ZW9j ayBDaG9pIGFuZCBHcmVnIERhbGV5ICANCg0KDQog -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:33:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02102 for ; Tue, 30 Mar 2004 18:33:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjG-0006WI-OZ for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCPSZP001899 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 08:25:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI3K-0000Kf-W3 for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:25:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05184 for ; Wed, 22 Oct 2003 08:24:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACI30-0004HC-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACI2z-0004H3-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI23-00082l-Dm; Wed, 22 Oct 2003 08:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGup-0001Z9-9u for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 07:12:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03615 for ; Wed, 22 Oct 2003 07:12:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGuo-0003is-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:12:34 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1ACGuo-0003iY-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:12:34 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9MBC2V08807 for ; Wed, 22 Oct 2003 04:12:02 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9MBEGtX000375 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 Oct 2003 04:14:21 -0700 Message-ID: <3F9665EC.4010508@innovationslab.net> Date: Wed, 22 Oct 2003 07:11:40 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a IPv6 working group last call for comments on advancing the following document as an Proposed Standard: Title : Deprecating Site Local Addresses Author(s) : C. Huitema, B. Carpenter Filename : draft-ietf-ipv6-deprecate-site-local-01.txt Pages : 10 Date : 2003-10-13 Please send substantive comments to the ipv6 mailing list, and minor editorial comments to the authors. This last call period will end on 5 November 2003. Brian Haberman / Bob Hinden IPv6 W.G. Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:34:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02122 for ; Tue, 30 Mar 2004 18:34:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjG-0006WI-QV for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5JeSQa029719 for ipv6-archive@odin.ietf.org; Wed, 5 Nov 2003 14:40:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTVy-0007jG-2c for ipv6-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:40:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19537 for ; Wed, 5 Nov 2003 14:40:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTVv-0001d2-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:40:23 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTVv-0001cz-00 for ipv6-web-archive@ietf.org; Wed, 05 Nov 2003 14:40:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTVc-0007br-G7; Wed, 05 Nov 2003 14:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTUl-0007ap-5m for ipv6@optimus.ietf.org; Wed, 05 Nov 2003 14:39:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19440 for ; Wed, 5 Nov 2003 14:38:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTUi-0001as-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:39:08 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTUh-0001ap-00 for ipv6@ietf.org; Wed, 05 Nov 2003 14:39:07 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA10219 for ; Wed, 5 Nov 2003 19:39:06 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA26788 for ; Wed, 5 Nov 2003 19:39:06 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA5Jd5Q28370 for ipv6@ietf.org; Wed, 5 Nov 2003 19:39:05 GMT Date: Wed, 5 Nov 2003 19:39:05 +0000 From: Tim Chown To: ipv6@ietf.org Subject: Re: IPv6 w.g. Last Call on "Deprecating Site Local Addresses" Message-ID: <20031105193905.GA28127@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org References: <3F9665EC.4010508@innovationslab.net> <3FA940FA.2030902@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA940FA.2030902@innovationslab.net> User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Sections 4 and 6 seem fine. Minor nit in 2.2 "which may cause" rather than "causing". Minor nit in 3, "QoS" for "QOS". Also in 3, "in which addresses are not ambiguous and do not have a simple explicit scope." is maybe better left as "in which addresses are not ambiguous" or maybe change to "and thus do not have" But it is fine as is :) Tim On Wed, Nov 05, 2003 at 01:27:06PM -0500, Brian Haberman wrote: > This is a reminder that the last call on the deprecation document > ends today. In particular, the chairs would like to ensure that > the WG agrees on the actual deprecation text in Sections 4 & 6. > There has been few comments on this draft and it cannot proceed > unless the chairs can be sure that it has been thoroughly reviewed > and agreed upon. > > If you have reviewed the document, have no issues with it, and agree > on its content, please let the chairs and/or the working group know. > > Thanks, > Brian & Bob > IPv6 WG Chairs > > Brian Haberman wrote: > > >This is a IPv6 working group last call for comments on advancing the > >following document as an Proposed Standard: > > > > Title : Deprecating Site Local Addresses > > Author(s) : C. Huitema, B. Carpenter > > Filename : draft-ietf-ipv6-deprecate-site-local-01.txt > > Pages : 10 > > Date : 2003-10-13 > > > >Please send substantive comments to the ipv6 mailing list, and minor > >editorial comments to the authors. This last call period will end on 5 > >November 2003. > > > >Brian Haberman / Bob Hinden > >IPv6 W.G. Chairs > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:34:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02158 for ; Tue, 30 Mar 2004 18:34:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjG-0006WI-Md for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCPQju001844 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 08:25:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI3J-0000LB-QA for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:25:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05202 for ; Wed, 22 Oct 2003 08:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACI32-0004HZ-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACI2z-0004H7-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI21-000823-BE; Wed, 22 Oct 2003 08:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACGuF-0001TR-TI for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 07:11:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03607 for ; Wed, 22 Oct 2003 07:11:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACGuD-0003iN-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:11:57 -0400 Received: from uillean.fuaim.com ([206.197.161.140]) by ietf-mx with esmtp (Exim 4.12) id 1ACGuC-0003iK-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:11:56 -0400 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h9MBBRV08801 for ; Wed, 22 Oct 2003 04:11:27 -0700 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h9MBDhtX000372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 22 Oct 2003 04:13:46 -0700 Message-ID: <3F9665CD.5010008@innovationslab.net> Date: Wed, 22 Oct 2003 07:11:09 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org Subject: IPv6 w.g. Last Call on "IPv6 Scoped Address Architecture" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a IPv6 working group last call for comments on advancing the following document as an Proposed Standard: Title : IPv6 Scoped Address Architecture Author(s) : S. Deering et al. Filename : draft-ietf-ipv6-scoping-arch-00.txt Pages : 22 Date : 2003-6-24 Please send substantive comments to the ipv6 mailing list, and minor editorial comments to the authors. This last call period will end on 5 November 2003. Brian Haberman / Bob Hinden IPv6 W.G. Chairs -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:34:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02263 for ; Tue, 30 Mar 2004 18:34:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjF-0006Yx-Vd for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ME7bvc018911 for ipv6-archive@odin.ietf.org; Mon, 22 Mar 2004 09:07:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Q5Z-0004uu-7H for ipv6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 09:07:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25482 for ; Mon, 22 Mar 2004 09:07:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Q5X-0005dQ-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 09:07:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Q4U-0005QN-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 09:06:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Q3R-0005DS-00 for ipv6-web-archive@ietf.org; Mon, 22 Mar 2004 09:05:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Q3B-0003wT-0H; Mon, 22 Mar 2004 09:05:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OYT-0000Iv-MQ for ipv6@optimus.ietf.org; Mon, 22 Mar 2004 07:29:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19649 for ; Mon, 22 Mar 2004 07:29:20 -0500 (EST) From: Michael.Dillon@radianz.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5OYT-0001JG-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:29:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5OXV-0001DI-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:28:22 -0500 Received: from intldssmtp001.radianz.com ([195.16.185.40]) by ietf-mx with esmtp (Exim 4.12) id 1B5OWc-000139-00 for ipv6@ietf.org; Mon, 22 Mar 2004 07:27:26 -0500 To: , Subject: Re: [ppml] Re: ASN-based prefixes for leaf ASes MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Mon, 22 Mar 2004 12:25:32 +0000 X-MIMETrack: Serialize by Router on INTLDSSMTP001/SERV/RadianzExt(Release 6.0.2CF1|June 9, 2003) at 22/03/2004 12:33:10, Serialize complete at 22/03/2004 12:33:10 Content-Type: text/plain; charset="us-ascii" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 >My proposal was that automatic /48 allocations be made to anyone with an >ASN, based on the premise that every AS will advertise at least one PI >block. And what is wrong with giving every AS an automatic /32? Or to put it in a more systematic manner, let's offer every AS holder some IPv6 space now. Let's ask them to identify how many networks they currently connect in order to estimate the number of /48's that would be used to connect the same number of networks. Then let's round this up to the next highest CIDR block boundary up to a maximum size of /32 and then give them that much IPv6 space, today. The basic principle is that because an AS holder is using IPv4 today, they will almost certainly use IPv6 at some future date. Therefore they have a justified requirement for IPv6 address space. And if an ISP is going to start offering IPv6 services, it is likely that they will eventually be offering those services to all customers. By counting the number of networks/sites they connect today, we have a rough estimate of the number of IPv6 sites that they will connect. But this offer is only a kickstart offer for one IPv6 allocation therefore the offer should be for no more than one /32. This does not mean that the RIRs have to create a swamp. They could reserve a /32 for each AS but only allocate the smaller block. Now, with these assumptions, we have enough information to calulate the amount of IPv6 space that would be used up. Could someone please do the caculations and let us know what percentage of the currently defined unicast IPv6 space would be consumed by such a kickstart program? --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:34:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02281 for ; Tue, 30 Mar 2004 18:34:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjG-0006WI-7t for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA42KHVW021190 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 21:20:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqnf-0005P2-D8 for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 21:20:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09320 for ; Mon, 3 Nov 2003 21:19:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGqnc-0003AF-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:20:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGqnc-0003AC-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 21:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqnb-0005IM-JU; Mon, 03 Nov 2003 21:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqml-0005GC-4h for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 21:19:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09300; Mon, 3 Nov 2003 21:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGqmi-00038x-00; Mon, 03 Nov 2003 21:19:08 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AGqmh-00038o-00; Mon, 03 Nov 2003 21:19:08 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7E67815210; Tue, 4 Nov 2003 11:19:05 +0900 (JST) Date: Tue, 04 Nov 2003 11:19:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Soohong Daniel Park Cc: "'Vijay Devarapalli'" , "'Soliman Hesham'" , ipv6@ietf.org, mip6@ietf.org, dna@eng.monash.edu.au Subject: Re: [Mip6] Re: A list of issues for RFC2462 update In-Reply-To: <01ae01c399d5$e748d660$b7cbdba8@daniel> References: <3F987C5B.9070905@iprg.nokia.com> <01ae01c399d5$e748d660$b7cbdba8@daniel> 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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 24 Oct 2003 11:24:08 +0900, >>>>> Soohong Daniel Park said: > I agreed with your mention and this issue is work in progress > at the DNA BOF. A second BOF will be scheduled during > this meeting. > For more reference, please look into this draft. > http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt-requiremen > t-01.txt Thanks for the pointer. I think this is a good summary of DAD related issues raised so far. (Again, this does not mean I'm going to propose a change in rfc2462bis due to the 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 exim@www1.ietf.org Tue Mar 30 18:34:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02354 for ; Tue, 30 Mar 2004 18:34:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjF-0006WI-Nx for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TKPTX5032728 for ipv6-archive@odin.ietf.org; Wed, 29 Oct 2003 15:25:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwsi-0008VY-Fs for ipv6-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 15:25:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04143 for ; Wed, 29 Oct 2003 15:25:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwsa-0002Y5-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 15:25:20 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEwsY-0002Xz-00 for ipv6-web-archive@ietf.org; Wed, 29 Oct 2003 15:25:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwsI-0008Dc-O0; Wed, 29 Oct 2003 15:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwrc-0008Ar-TL for ipv6@optimus.ietf.org; Wed, 29 Oct 2003 15:24:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04117 for ; Wed, 29 Oct 2003 15:24:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwrb-0002X2-00 for ipv6@ietf.org; Wed, 29 Oct 2003 15:24:19 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx with esmtp (Exim 4.12) id 1AEwra-0002WK-00 for ipv6@ietf.org; Wed, 29 Oct 2003 15:24:19 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3D4BF246; Wed, 29 Oct 2003 21:23:47 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp03.uc3m.es (Postfix) with ESMTP id 2771E230; Wed, 29 Oct 2003 21:23:47 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Pekka Savola Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Wed, 29 Oct 2003 21:23:44 +0100 User-Agent: KMail/1.5.4 Cc: itojun@iijlab.net, , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310292123.45458.jrh@it.uc3m.es> Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday 29 October 2003 20:05, Pekka Savola wrote: > On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: > > On the other hand, I think that applications which > > query the DNS shouldn't be real-time applications, so I see this > > feature is not very useful. > > How do you see people browsing the web get to the websites then, if not > using DNS? That's enough realtime in my book -- the user waits while the > request(s) is being processed. > > I really don't understand what you're trying to say.. Hello Pekka! I will try to explain it better.... I just say that this option is not *very* useful, having into account the problems that it has with link-local addresses and so on... if you fix these problems, it's a matter of choice, if you want to use it, just do it. > > If I understood Stig well, he said that people was > > turning off IPv6 because of delaying issues. Doing that is not an option > > if you want to allow your app. to run over "IPv6 AND IPv4". If you can > > not cope with such delays, maybe you shouldn't be using the DNS at all. > > Then what? Distributed hosts file? ;-) ? ^--^ ...(after a while)... pouting (grrrr). Then what ? it's not my problem, I haven't switched to IPv4 because the IPv6 resolver took a couple of extra roundtrip times. I'm happy with a lot of IPv6 applications that don't use this feature at all. > > The problem here is that most of the times this feature will fail back > > to the worst case, which is the normal getaddrinfo behaviour, because > > it's not as easy as checking for global IPv6 configured address, as > > Itojun has already said. We might come up with a lot of scenarios where > > this option might fail to improve the response time (e.g: only link-local > > addresses, global addresses but no default route, proper link local IPv6 > > configuration but some black-hole on outer routers.....). > > I fail to see the point here: > > - if only link local addresses: fixed AI_ADDRCONFIG would fix > > - if global but no default route: > a) without the on-link assumption: automatic immediate no route > message and fallback to the next address > b) with (current) on-link assumption: problematic (which is why the > assumption must be killed :-) Uhm I thought that IPv6 was a piece of cake, but it might be problematic sometimes....Ops, I've got the solution, just kill IPv6 ! ;-) > > - if global, default route, but blackhole somewhere: > silently discarding packets is evil practice anyway and nothing can > be done about that, whether in case of v4 or v6. > > - if global, default route, everything works, but some DNS server munges > the AAAA queries: can't help with that, but because v6 would be > used, that has to be fixed by fixing the servers anyway. > > .. so my perception is that this would fix all the problems related to > partial IPv6 deployment I could think of w/ the elimination of the on-link > assumption pretty well. I see another way of fixing: If this option is problematic, don't use it. This has been proved to work, as a lot of applications don't use it already. You will have to give me other arguments to kill the on-link assuption. -- JFRH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:35:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02372 for ; Tue, 30 Mar 2004 18:35:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjF-0006WI-Rw for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIATLW8004267 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 05:29:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM36n-00016j-NL for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 05:29:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13243 for ; Tue, 18 Nov 2003 05:29:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM36k-00029b-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:29:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM36j-00029V-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:29:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM35S-0000WO-73; Tue, 18 Nov 2003 05:27:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM0TC-0006sO-Cs for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 02:40:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08839; Tue, 18 Nov 2003 02:40:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM0T8-0007aG-00; Tue, 18 Nov 2003 02:40:14 -0500 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx with esmtp (Exim 4.12) id 1AM0T7-0007a6-00; Tue, 18 Nov 2003 02:40:13 -0500 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57]) by smtp.uibk.ac.at (8.12.10/8.12.10/F1) with ESMTP id hAI7deUV006759; Tue, 18 Nov 2003 08:39:40 +0100 Subject: Re: [pmtud] Re: [dccp] PMTU issues From: Michael Welzl To: Eddie Kohler Cc: Fred Templin , dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org In-Reply-To: <200311180139.hAI1dJIe059714@coyote.icir.org> References: <200311180139.hAI1dJIe059714@coyote.icir.org> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1069141080.4798.3.camel@lap10-c703.uibk.ac.at> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 18 Nov 2003 08:38:03 +0100 Content-Transfer-Encoding: 7bit X-Spam-Score: -8.4 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCV_UIBK,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN X-Scanned-By: MIMEDefang 2.35 at uibk.ac.at Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ... I agree 100% with Eddie on these two (1. "we should get rid of ICMP feedback in the long run", 2. "combine PMTUD with ECN") issues. Cheers, Michael On Tue, 2003-11-18 at 02:39, Eddie Kohler wrote: > Hi Fred, > > * PLPMTUD is useful. > * Designing PMTUD so that it works in the absence of ICMP feedback seems > necessary. > > BUT > > * Suitable ICMP feedback hints might significantly improve the performance > of a transport protocol. > * We can program our transports to react to ICMP as a hint -- i.e., not > trust it, but use it to optimize performance. > * So ICMP should not be "needed", but it might, and probably would, be quite > helpful in some cases. > * For instance, not all packetization layers have as easy a time as TCP > with packet size changes. The smooth ramp-up suggested in PLPMTUD may > require intervention from the application for example. For good > performance, these applications may apply PMTUD in unexpected ways -- > they might start large, for example. ICMP feedback would really help > them. > * ICMP is not a significant cause of Internet congestion and need not ever > become one (mark it less-than-best-effort). > > I still think your overloading of ECN capable as "PLPMTUD capable, don't > send ICMP" is not necessary, a bad idea, and will not fly. > > Eddie > > _______________________________________________ > pmtud mailing list > pmtud@ietf.org > https://www1.ietf.org/mailman/listinfo/pmtud -- Michael Welzl University of Innsbruck -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:35:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02405 for ; Tue, 30 Mar 2004 18:35:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj5-0006a4-CL for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9982qkX009861 for ipv6-archive@odin.ietf.org; Thu, 9 Oct 2003 04:02:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vl5-0002Yb-AT for ipv6-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 04:02:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10602 for ; Thu, 9 Oct 2003 04:02:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vl2-00037J-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 04:02:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Vl2-00037G-00 for ipv6-web-archive@ietf.org; Thu, 09 Oct 2003 04:02:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7VkN-0002BK-7m; Thu, 09 Oct 2003 04:02:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vjs-00024G-48 for ipv6@optimus.ietf.org; Thu, 09 Oct 2003 04:01:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10551 for ; Thu, 9 Oct 2003 04:01:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vjp-00035m-00 for ipv6@ietf.org; Thu, 09 Oct 2003 04:01:33 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vjo-000359-00 for ipv6@ietf.org; Thu, 09 Oct 2003 04:01:32 -0400 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 9 Oct 2003 10:01:03 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38E3B.7BC44F12" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: unsubscribe Date: Thu, 9 Oct 2003 10:01:02 +0200 Message-ID: Thread-Topic: unsubscribe Thread-Index: AcOOO3tBnAgegvPUT6qTKjKH/3j54g== From: "VO Tien Cuong FTRD/DAC/ISS" To: X-OriginalArrivalTime: 09 Oct 2003 08:01:03.0382 (UTC) FILETIME=[7C299360:01C38E3B] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C38E3B.7BC44F12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable unsubscribe ------_=_NextPart_001_01C38E3B.7BC44F12 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable unsubscribe

unsubscribe

------_=_NextPart_001_01C38E3B.7BC44F12-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:35:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02489 for ; Tue, 30 Mar 2004 18:35:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjE-0006Yx-HV for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LCeRY2023628 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 08:40:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvnt-000669-8s for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 08:40:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15708 for ; Tue, 21 Oct 2003 08:39:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABvns-00033e-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 08:40:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABvnr-00033a-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 08:39:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvlH-0005So-2O; Tue, 21 Oct 2003 08:37:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvk4-0004v1-NO for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 08:36:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15530 for ; Tue, 21 Oct 2003 08:35:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABvk3-00030p-00 for ipv6@ietf.org; Tue, 21 Oct 2003 08:36:03 -0400 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1ABvk2-00030m-00 for ipv6@ietf.org; Tue, 21 Oct 2003 08:36:02 -0400 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id ADFE8830F; Tue, 21 Oct 2003 14:35:41 +0200 (CEST) From: "Jeroen Massar" To: "'Dan Lanciani'" , Subject: RE: IPv6 adoption behavior Date: Tue, 21 Oct 2003 14:35:42 +0200 Organization: Unfix Message-ID: <004001c397cf$d830ff20$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200310202019.QAA08845@ss10.danlan.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Dan Lanciani wrote: > "Jeroen Massar" wrote: > Again, it is not very interesting for the purposes of > determining whether IPv6 can _replace_ IPv4+NAT as suggested. Even IPv4 can replace IPv4+NAT, anything can replace that mechanism that is breaking end-to-end connectivity. > Sure there is if the user has no access to the *local* end which is > embedded in the tamper-resistant firmware of a smart phone. My point > was that this is a context where you can force the user to pay per > address since he cannot install NAT within the phone. I think you want to dig more into covert channels. There is always a way in or out :) > |> I understand that actual end-user requirements are not a > |> major consideration for IPv6 development. > | > |The enduser wants one thing: it needs to work(tm) > > The end-user has tasted the power of internetworking. I don't think > you will make him forget that easily. But then I may be wrong. It > is said that nobody ever lost money underestimating the intelligence > of the consumer. Or something like that. You are wrong :) They tasted the filth of being behind NAT's and not being able to do a number of things including VoIP. > |> an individual networks his own computers and > |> connects that network to the internet as in the > |> pre-commercial model. > | > |Which won't scale as that would require to much routing > |information and administration in the RIR's. > > This is just another variation of the "PI doesn't scale" > argument. The administration angle is kind of funny, though. Isn't it > amazing how the registries manage to "administer" as many domain names as > anybody cares to pay for? I guess it's much harder to keep a list of numbers > than to keep a list of names... You mean that adminstration of domain names that includes a lot of inconsistensies is handled by about 250 'registries' and usually doesn't even contain any real data so that abuse is completely impossible ? > |> Your statement is extremely misleading, comparing apples and > |> turnips. It is true that _a_ network connected without NAT > |> enjoys a slightly larger > |> set of capabilities (though they are capabilities that are > |> not important to the typical NAT user) > | > |Let me put it this way: they want their mp3's (-> warez). > |Thus they need to do P2P as they know no other way. > |This requires a non-NATted IP. > > Of course, that's not quite true. People keep trying to > project onto NAT the problems caused by the provider's > limitation of a single IP address. NAT limits me in the way the internet was designed. Which was made to communicate between hosts: End To End. Not Multi To End. > |> The correct comparison, then, is between a NAT-connected network > |> and a network that is not connected to the internet at all. > |> Which one enjoys greater capability? > | > |The NAT connected network with an IPv6 tunnel :) > > I agree that that is even better: > > (NAT connected network with IPv6 tunnel) > > (NAT connected network) > (unconnected network) > > However, I suspect that you will find that if/when IPv6 access becomes > valuable to the typical customer, your tunnel broker will > start charging you for addresses just as your local ISP would. Accidentally it is partially 'my' tunnelbroker ;) I have heared of nobody yet doing this and I don't expect it become that way for the coming couple of years. At least not while there is no general IPv6 access. The company that owns the POP makes up their own policy and can make it a public or a closed POP. Charge whatever they want, that is their business. But in the spirit of good will and the fact that most other services (ftp servers/public download) will cost them much more traffic all except two of the POP's are public, with 2 extra public ones in the pipe. Actually there have been requests in the past for a service like a tunnelbroker for which people have to pay to get a stable set of IPv6 addresses which can move with them when they swap ISP's. Basically this is also a way of solving PI, just tunnel the space :) Though one is not independent of the TB in that case. But one is always dependent on one instance or another. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP5UoHSmqKFIzPnwjEQKAqwCgikKRtrgU5SF/4pGIv5V6tzoP6wAAn1vN qDYlE0YfaM94L/GVRcG9Ek08 =z+7i -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:36:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02690 for ; Tue, 30 Mar 2004 18:36:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjD-0006WI-UD for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCPRe7001888 for ipv6-archive@odin.ietf.org; Wed, 22 Oct 2003 08:25:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI3K-0000L9-Jh for ipv6-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:25:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05196 for ; Wed, 22 Oct 2003 08:24:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACI32-0004HU-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACI30-0004HF-00 for ipv6-web-archive@ietf.org; Wed, 22 Oct 2003 08:25:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACI2C-0008AW-SW; Wed, 22 Oct 2003 08:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACH6W-00030G-Vm for ipv6@optimus.ietf.org; Wed, 22 Oct 2003 07:24:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03841 for ; Wed, 22 Oct 2003 07:24:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACH6W-0003pq-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:24:40 -0400 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1ACH6V-0003pf-00 for ipv6@ietf.org; Wed, 22 Oct 2003 07:24:39 -0400 Received: from pjs3 (pjs2.etri.re.kr [129.254.112.155]) by pec.etri.re.kr (8.12.10/8.12.10) with ESMTP id h9MBcjJ5023218; Wed, 22 Oct 2003 20:38:45 +0900 (KST) Message-Id: <200310221138.h9MBcjJ5023218@pec.etri.re.kr> Reply-To: From: "jspark" To: "'Erik Nordmark'" , "'Bob Hinden'" Cc: Subject: RE: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" Date: Wed, 22 Oct 2003 20:23:58 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook, Build 11.0.4920 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcOYf5VS+m6CC2FvQ3OY7rucws5i0wABfvfg Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Erik Thanks for your comments. > I'm trying to understand why the RFC 3306 are so broken for scope = <=3D2 > that they can not be used. > While using the new address format for scope <=3D 2 would presumably = be=20 >preferred I don't see why prohibiting=20 > (as the "MUST" above does) the use of RFC 3306 for those scopes. > If prohibiting them is the right thing I think the document should = state why. Technically, RFC3306 can be used for scope <=3D2. RFC3306 author's consent to the following sentence : our draft updates the "Unicast-Prefix- based IPv6 Multicast=20 Addresses" for the link-local scope.=20 In my memory, IPv6 guys also agreed on our view during the 54th IETF meeting. I think .. RFC3306 needs allocation server of 32bit goup ID in order to support the uniqueness in the site. This site is identified by network prefix. But,=20 Group ID Autoconfiguration in link-scope will be valuable=20 without help of allocation server. Each node in our draft allocates group ID independently. > The example says: > This is an example of an interface ID-based multicast address with > link-local scope. For example in an Ethernet environment, if the > link-local unicast address is FE80::12:34:56:78:90:AB, the multicast > prefix of the host is FF32:0:1234:56FF:FE78:90AB::/96. For SSM, > multicast address will be FF32::/96.=20 > Typo (I think): FE80::12:34:56:78:90:AB should be FE80::1234:5678:90AB > and a better example would have a 64 bit iid (the above one has 16 = leading zeros). Such as > FE80::a12:34ff:fe56:7890 > resulting in > FF32:0:a12:34ff:fe56:7890::/96 >=20 > Erik Good comment.=20 We will publish new draft with a reflex of reality soon. Jungsoo -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:36:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02743 for ; Tue, 30 Mar 2004 18:36:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjB-0006YH-I1 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKHmBn022955 for ipv6-archive@odin.ietf.org; Mon, 24 Nov 2003 15:17:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AON9X-0005wM-VX for ipv6-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:17:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26600 for ; Mon, 24 Nov 2003 15:17:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AON9R-0003mn-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 15:17:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AON9R-0003mR-00 for ipv6-web-archive@ietf.org; Mon, 24 Nov 2003 15:17:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AON8o-0005ci-8I; Mon, 24 Nov 2003 15:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AON7r-0005c3-Gh for ipv6@optimus.ietf.org; Mon, 24 Nov 2003 15:16:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26378 for ; Mon, 24 Nov 2003 15:15:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AON7m-0003iY-00 for ipv6@ietf.org; Mon, 24 Nov 2003 15:15:58 -0500 Received: from evrtwa1-ar8-4-65-024-025.evrtwa1.dsl-verizon.net ([4.65.24.25] helo=tndh.net) by ietf-mx with esmtp (Exim 4.12) id 1AON7m-0003iV-00 for ipv6@ietf.org; Mon, 24 Nov 2003 15:15:58 -0500 Received: from eaglet (127.0.0.1:4496) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Mon, 24 Nov 2003 12:19:34 -0800 From: "Tony Hain" To: "'Brian E Carpenter'" , "'Pekka Savola'" Cc: Subject: RE: draft-hain-templin-ipv6-localcomm-03 comments Date: Mon, 24 Nov 2003 12:15:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3FC1C557.50733BA8@zurich.ibm.com> Thread-Index: AcOyg3Ft+iszwsr+QeWLpF6XtN7ykwAQ7qZg Message-Id: Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > ... > Now, I would be completely happy for us to throw away the Hain/Templin > draft as long as we immediately standardize the Hinden/Haberman solution. > But if we want to address (pun intended) the problems of the real world, > we cannot ignore the fact that most corporate network managers are > profoundly convinced of the need for private addressing. In many cases I would agree with Brian, but in this specific one we have an example of lost discussion from many years ago about why network managers 'need' a private space, and FEC0 was allocated for it. We need to document why Hinden/Haberman is needed to solve today's problems, so we don't end up arguing about it 5 years from now. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:36:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02797 for ; Tue, 30 Mar 2004 18:36:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjD-0006Yx-Jg for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKVnXD032568 for ipv6-archive@odin.ietf.org; Mon, 10 Nov 2003 15:31:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIhR-0008TD-9s for ipv6-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 15:31:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11870 for ; Mon, 10 Nov 2003 15:31:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIhP-00048k-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 15:31:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJIhP-00048g-00 for ipv6-web-archive@ietf.org; Mon, 10 Nov 2003 15:31:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIgg-00089G-Bg; Mon, 10 Nov 2003 15:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIg2-00087E-Tw for ipv6@optimus.ietf.org; Mon, 10 Nov 2003 15:30:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11778 for ; Mon, 10 Nov 2003 15:30:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIg1-00044w-00 for ipv6@ietf.org; Mon, 10 Nov 2003 15:30:21 -0500 Received: from ns2.sea.interquest.net ([66.135.144.2] helo=ns2.sea) by ietf-mx with esmtp (Exim 4.12) id 1AJIg0-00044t-00 for ipv6@ietf.org; Mon, 10 Nov 2003 15:30:20 -0500 Received: from ssprunk (ip154.post-vineyard.dfw.interquest.net [66.135.181.154]) by ns2.sea (8.12.10/8.12.5) with SMTP id hAAKUGJT008340; Mon, 10 Nov 2003 12:30:17 -0800 Message-ID: <024201c3a7c9$74097db0$6401a8c0@ssprunk> From: "Stephen Sprunk" To: "Iljitsch van Beijnum" , "Erik Nordmark" Cc: References: Subject: Re: IPv6 w.g. Last Call on "Unique Local IPv6 Unicast Addresses" Date: Mon, 10 Nov 2003 14:20:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thus spake "Iljitsch van Beijnum" > > I don't see how this can be true in general. > > Here is an example using referrals; the three nodes involved are A, B, > > C. Node A and B are in the same site, have both local and global > > addresses, and C is in a different site. > > > Node A and B are communicating using these local addresses. > > In particular, B contacted A using FQDN(A) and the naming system > > somehow so that they ended up communcating with local addresses. (My > > understanding is that part of the benefit of these local addresses is > > that local communication prefer using local addresses over global > > addresses.) > > Yes, but how??? > > A simple method would be to check the first 48 bits of the IP addresses > that are suspected of having "local" reachability. But this doesn't > allow for the merging of two sites, which was presented as a rather > prominent requirement during the site local wars (or at least the part > I got to witness). I don't see this is a problem at all; any given address on a host may only be able to reach a subset of destinations, whether it's a site-local address or not. The only way to be sure is to try them all and see which works; if the working one happens to be a site-local, who cares? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:37:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03016 for ; Tue, 30 Mar 2004 18:37:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjC-0006ZK-CT for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEIBClE016409 for ipv6-archive@odin.ietf.org; Fri, 14 Nov 2003 13:11:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiPY-0004Ga-LN for ipv6-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 13:11:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22960 for ; Fri, 14 Nov 2003 13:10:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKiPW-00026W-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 13:11:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKiPW-00026S-00 for ipv6-web-archive@ietf.org; Fri, 14 Nov 2003 13:11:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiPO-00047x-Ek; Fri, 14 Nov 2003 13:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiOl-0003x5-VH for ipv6@optimus.ietf.org; Fri, 14 Nov 2003 13:10:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22925 for ; Fri, 14 Nov 2003 13:10:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKiOj-00025t-00 for ipv6@ietf.org; Fri, 14 Nov 2003 13:10:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AKiOj-00025D-00 for ipv6@ietf.org; Fri, 14 Nov 2003 13:10:21 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hAEI9ot05667; Fri, 14 Nov 2003 10:09:50 -0800 X-mProtect: <200311141809> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKfuJo0; Fri, 14 Nov 2003 10:09:48 PST Message-ID: <3FB51C0B.7030509@iprg.nokia.com> Date: Fri, 14 Nov 2003 10:16:43 -0800 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipv6@ietf.org, v6ops@ops.ietf.org CC: ftemplin@iprg.nokia.com Subject: [Fwd: Re: [pmtud] Re: [dccp] PMTU issues] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm cross-posting this from another list, since it relates to the recent discussions on Path MTU discovery: Fred ftemplin@iprg.nokia.com Fred Templin wrote: > I hate to say it, but frankly I think this whole PMTU business is > a bunch of hooey. We have RFCs 1191 and 1981 as the service for > packetization layers that require network level feedback, and those > packetization layers can happily continue doing what they've been > doing for the past decade or so. > > But, new packetization layers that take the example of PLPMTUD > require no feedback from the network and so they should have a > means by which to turn the network layer feedback off. This should > eventually dampen the noise from the unnecessary ICMP's as the > new packetization layers supplant the old. > > Anyway, that's my story and I'm sticking to it. > > Fred > ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:37:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03072 for ; Tue, 30 Mar 2004 18:37:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjC-0006ZK-R6 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKADJ8B026410 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 05:13:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMloM-0006rt-E3 for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 05:13:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27543 for ; Thu, 20 Nov 2003 05:13:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMloK-00005Z-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 05:13:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMloJ-00005W-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 05:13:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMln8-0006Xp-Ly; Thu, 20 Nov 2003 05:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMkLr-0001sC-5S for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 03:39:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25358 for ; Thu, 20 Nov 2003 03:39:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMkLp-0006oQ-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:39:45 -0500 Received: from pop.directnic.com ([204.251.10.90]) by ietf-mx with smtp (Exim 4.12) id 1AMkLp-0006oI-00 for ipv6@ietf.org; Thu, 20 Nov 2003 03:39:45 -0500 Received: by pop.directnic.com (iris/0.113:482015); 20 Nov 2003 08:39:44 +0000 Received: from node180.hil.no (EHLO MOBBUS) (128.39.109.180) by pop.directnic.com (iris/0.113:482015/relay) with ESMTP id 482015 for ipv6@ietf.org; 20 Nov 2003 08:39:38 +0000 From: "Dag Veierod" To: Subject: How do I unsubscribe? Have tried lots of possibillities but no success. Please help! Date: Thu, 20 Nov 2003 09:39:25 +0100 Message-ID: <005e01c3af41$d3f63950$0900000a@MOBBUS> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of john.loughney@nokia.com Sent: 20. november 2003 09:36 To: john.loughney@nokia.com; ipv6@ietf.org Subject: RE: Node Req: Issue31: DHCPv6 text Hi All, I forgot other text that Pekka suggested, here is all of the text: reword: For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. to: Nodes that implement DHCPv6 MUST use DHCP upon the receipt of a Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCPv6 MUST attempt to use DHCPv6. In this context, 'use DHCP' means trying to obtain both address(es) and other configuration information through DHCP. and: reword: For those IPv6 nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. to: Nodes that implement DHCP MUST use DHCP upon the receipt of a Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. In this context, 'use DHCP' means trying to obtain both address(es) and other configuration information through DHCP. -------------------------------------------------------------------- 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 exim@www1.ietf.org Tue Mar 30 18:38:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03244 for ; Tue, 30 Mar 2004 18:38:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjC-0006Yx-5p for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J8q2mm017976 for ipv6-archive@odin.ietf.org; Thu, 19 Feb 2004 03:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atjuc-0004fr-R2 for ipv6-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 03:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05907 for ; Thu, 19 Feb 2004 03:52:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atjua-0005ca-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 03:52:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atjtf-0005XC-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 03:51:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atjsh-0005TU-00 for ipv6-web-archive@ietf.org; Thu, 19 Feb 2004 03:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atjsg-0004B9-T5; Thu, 19 Feb 2004 03:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atjrl-0003y2-OW for ipv6@optimus.ietf.org; Thu, 19 Feb 2004 03:49:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05797 for ; Thu, 19 Feb 2004 03:49:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atjrj-0005QQ-00 for ipv6@ietf.org; Thu, 19 Feb 2004 03:49:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atjqr-0005Nn-00 for ipv6@ietf.org; Thu, 19 Feb 2004 03:48:09 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AtjqD-0005Ic-00 for ipv6@ietf.org; Thu, 19 Feb 2004 03:47:29 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGXXZJ>; Thu, 19 Feb 2004 03:47:12 -0500 Message-ID: <9E3BA3946476AD4EB94672712B12A85F04216F@ftmail.lab.flarion.com> From: Soliman Hesham To: ipv6@ietf.org Subject: 2461bis Date: Thu, 19 Feb 2004 03:47:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, I didn't see the announcement for this draft so please note the URL: http://www.ietf.org/internet-drafts/draft-soliman-ipv6-2461-bis-01.txt There is still a few unresolved issues that I'll summarise and send to the list. I hope we can discuss this in Seoul. Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:39:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03482 for ; Tue, 30 Mar 2004 18:39:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjB-0006Yx-D3 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S9bcFQ015086 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 04:37:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQIA-0003uo-VL for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 04:37:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11988 for ; Tue, 28 Oct 2003 04:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEQI6-0006NR-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 04:37:30 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEQI3-0006NN-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 04:37:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQHe-0003bb-Hh; Tue, 28 Oct 2003 04:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQHT-0003aM-Pf for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 04:36:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11974 for ; Tue, 28 Oct 2003 04:36:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEQHQ-0006Mz-00 for ipv6@ietf.org; Tue, 28 Oct 2003 04:36:48 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AEQHM-0006Mj-00 for ipv6@ietf.org; Tue, 28 Oct 2003 04:36:44 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9S9aDxA010496; Tue, 28 Oct 2003 01:36:14 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9S9aDS12364; Tue, 28 Oct 2003 10:36:13 +0100 (MET) Date: Tue, 28 Oct 2003 10:35:57 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: "RFC 2461bis" issue: MTU handling To: Fred Templin Cc: Erik Nordmark , Iljitsch van Beijnum , ipv6@ietf.org In-Reply-To: "Your message with ID" <3F9DAB6C.60702@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > One case in which data packets could be used as probe packets > is when IPv4 is used as an L2 media for IPv6. In this case, we could > send IPv6-in-IPv4 encapsulated packets with the DF bit NOT set > in the IPv4 header expecting that the decapsulator would send us > some sort of indication if it sensed fragmentation. Yes, you have that option for the L2 which is known as IPv4. > But this begs the question of a fundamental design point: do we need > to support sub-L2 media elements (i.e., the physical elements that sit > below IPv4) that neither support IPv4 fragmentation nor send IPv4 > "frag needed" messages when they can't forward a packet? Based on > the 1Gbps/100Mbps Ethernet bridge example, I believe the answer > to this is "yes" - would you agree? I think the high-order bit question for those L2s is first how important the problem is to solve, and then what simplying assumptions we can make. (such as "does the network admin control all the switches i.e. does s/he know whether all are jumbo frame capable"). Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:39:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03712 for ; Tue, 30 Mar 2004 18:39:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjA-0006WI-GW for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGoGDi029797 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 11:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbiV-0007fr-8M for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 11:50:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09427 for ; Tue, 11 Nov 2003 11:49:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbiU-0005rm-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:50:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJbiT-0005rj-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:50:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbiN-0007Wp-Vf; Tue, 11 Nov 2003 11:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbfy-00079O-3y for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 11:47:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09279 for ; Tue, 11 Nov 2003 11:47:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbfw-0005oy-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:47:32 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AJbfv-0005ov-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:47:32 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 17:47:29 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A873.7EA4E1C4" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: Sites in draft "Unique Local IPv6 Unicast Addresses" Date: Tue, 11 Nov 2003 17:47:29 +0100 Message-ID: Thread-Topic: Sites in draft "Unique Local IPv6 Unicast Addresses" Thread-Index: AcOoczQEo4JHrKkeQZaF1Ba9pnJiNg== From: "NOISETTE Yoann FTRD/DMI/CAE" To: X-OriginalArrivalTime: 11 Nov 2003 16:47:29.0746 (UTC) FILETIME=[7EBBFB20:01C3A873] Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A873.7EA4E1C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I just wanted to point out something that caught my attention when re-reading this draft. In draft-ietf-ipv6-deprecate-site-local-01.txt, section 2.4, there is an assertion that "Site is an ill-defined concept" followed by arguments. When reading draft-ietf-ipv6-unique-local-addr-01.txt, we can notice that the word "site" is referred many times, often to describe or limit some features or operations on the new defined addresses. Then, though both documents are not to be considered as companion documents, I was wondering if it wouldn't be a good thing that draft-ietf-ipv6-unique-local-addr-01.txt gives the meaning of "site" as used for the writing, in order to prevent any confusion or amalgamate with the "site" that is discussed in draft-ietf-ipv6-deprecate-site-local-01.txt. As an exemple (well, for what it's worth) we can see "Apart from link-local, scope boundaries are ill-defined. What is a site?" (in the deprecate draft, section 2.4) on the one hand and "Well known prefix to allow for easy filtering at site boundaries" (in the ULA draft, section 1.0) on the other hand. I think this should be clarified to prevent any misunderstanding. Moreover, while the list is discussing the name to be given to the new defined addresses (organi[zs]ation, local or... whatever), the fact to position the meaning of "site" used throughout the document might be a good thing. I don't want to restart many discussions that took place on the list many times on "what is a site", but just wonder if it is a good thing to use "site" so many times in a document describing new addresses alternatives to "site-local addresses" without clarifying its meaning as far as the document is concerned. Notably, make it clear it isn't linked to any "scope" meaning but rather to some operational deployment cases (some examples could be provided from simple one to more complex making use of VPN or Mobile Nodes). My two cents, FWIW... Yoann NOISETTE Yoann &francetelecom R&D DMI/SIR/IPI 42, rue des Coutures - BP 6243 14066 CAEN Cedex 4 - FRANCE * : +33 (0)2.31.75.90.48 * : +33 (0)2.31.73.56.26 * mailto:yoann.noisette@francetelecom.com ------_=_NextPart_001_01C3A873.7EA4E1C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sites in draft "Unique Local IPv6 Unicast = Addresses"

Hi,

I just wanted to point out something = that caught my attention when re-reading this draft. In = draft-ietf-ipv6-deprecate-site-local-01.txt, section 2.4, there is an = assertion that "Site is an ill-defined concept" followed by = arguments.  When reading  = draft-ietf-ipv6-unique-local-addr-01.txt, we can notice that the word = "site" is referred many times, often to describe or limit some = features or operations on the new defined addresses.

Then, though both documents are not to = be considered as companion documents, I was wondering if it wouldn't be = a good thing that draft-ietf-ipv6-unique-local-addr-01.txt gives the = meaning of "site" as used for the writing, in order to prevent = any confusion or amalgamate with the "site" that is discussed = in draft-ietf-ipv6-deprecate-site-local-01.txt. As an exemple (well, for = what it's worth) we can see "Apart from link-local, scope = boundaries are ill-defined. What is a site?" (in the deprecate = draft, section 2.4) on the one hand and "Well known prefix to allow = for easy filtering at site boundaries" (in the ULA draft, section = 1.0) on the other hand.

I think this should be clarified to = prevent any misunderstanding. Moreover, while the list is discussing the = name to be given to the new defined addresses (organi[zs]ation, local = or… whatever), the fact to position the meaning of = "site" used throughout the document might be a good = thing.

I don't want to restart many = discussions that took place on the list many times on "what is a = site", but just wonder if it is a good thing to use = "site" so many times in a document describing new addresses = alternatives to "site-local addresses" without clarifying its = meaning as far as the document is concerned. Notably, make it clear it = isn't linked to any "scope" meaning but rather to some = operational deployment cases (some examples could be provided from = simple one to more complex making use of VPN or Mobile = Nodes).

My two cents, FWIW...

Yoann

NOISETTE Yoann
 &francetelecom R&D

              DMI/SIR/IPI
      42, rue des Coutures - BP 6243
      14066 CAEN Cedex 4 - = FRANCE

( : +33 (0)2.31.75.90.48    2 : +33 (0)2.31.73.56.26
* mailto:yoann.noisette@francetelecom.com


------_=_NextPart_001_01C3A873.7EA4E1C4-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:40:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03748 for ; Tue, 30 Mar 2004 18:40:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjA-0006YH-Do for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIARuIV002021 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 05:27:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM35P-0000Vg-Tg for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 05:27:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13118 for ; Tue, 18 Nov 2003 05:27:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM351-00025f-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:27:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM34w-00024m-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:27:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM32d-0008FA-8L; Tue, 18 Nov 2003 05:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM32Z-0008Ef-MH for ipv6@optimus.ietf.org; Tue, 18 Nov 2003 05:24:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13042 for ; Tue, 18 Nov 2003 05:24:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM32W-00023B-00 for ipv6@ietf.org; Tue, 18 Nov 2003 05:24:56 -0500 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM32V-000238-00 for ipv6@ietf.org; Tue, 18 Nov 2003 05:24:55 -0500 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA27434 for ; Tue, 18 Nov 2003 10:24:54 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA07424 for ; Tue, 18 Nov 2003 10:24:53 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hAIAOrf19062 for ipv6@ietf.org; Tue, 18 Nov 2003 10:24:53 GMT Date: Tue, 18 Nov 2003 10:24:53 +0000 From: Tim Chown To: ipv6@ietf.org Subject: IPv4 compatible deprecation? (addr-arch-v4) Message-ID: <20031118102453.GE18738@login.ecs.soton.ac.uk> Mail-Followup-To: ipv6@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, A discussion on v6ops made me realise that while I thought we were deprecating IPv4 compatible addresses, this actually isn't the case. I have a feeling many people have assumed their use is "deprecated" but this isn't formally documented? IPv4 compatibles have now been removed from the latest update of the Basic Transition Mechanisms document that is just going through v6ops: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt If we want to deprecate IPv4-compatible addressing, then we need to look at section 2.5.5 of the addressing architecture document that was re-released with site local updates last month: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-00.txt We should catch this one while the text is being updated for site locals. We would presumably update the text in a similar way to the site local text update to section 2.5.7. If a separate deprecation document is required as per site local deprecation I would be happy to author/help on that. For reference, the site local deprecation is defined here: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-01.txt This deprecation would not affect mapped addresses. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:40:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03880 for ; Tue, 30 Mar 2004 18:40:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjA-0006ZK-1J for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SAdHSJ006325 for ipv6-archive@odin.ietf.org; Tue, 28 Oct 2003 05:39:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERFs-0001dw-Pq for ipv6-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 05:39:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15035 for ; Tue, 28 Oct 2003 05:39:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AERFo-0007fP-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 05:39:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AERFo-0007fM-00 for ipv6-web-archive@ietf.org; Tue, 28 Oct 2003 05:39:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AERFg-0001TI-Aw; Tue, 28 Oct 2003 05:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEREv-00018t-3i for ipv6@optimus.ietf.org; Tue, 28 Oct 2003 05:38:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14974 for ; Tue, 28 Oct 2003 05:38:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEREr-0007eG-00 for ipv6@ietf.org; Tue, 28 Oct 2003 05:38:13 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AEREq-0007eD-00 for ipv6@ietf.org; Tue, 28 Oct 2003 05:38:13 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9SAcCPh028046; Tue, 28 Oct 2003 03:38:13 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9SAcBS21293; Tue, 28 Oct 2003 11:38:11 +0100 (MET) Date: Tue, 28 Oct 2003 11:37:56 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: "RFC 2461bis" issue: MTU handling To: Fred Templin Cc: Iljitsch van Beijnum , ipv6@ietf.org In-Reply-To: "Your message with ID" <3F9DA665.6000403@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > I'm afraid I'm not bought into this one as being necessary (yet). We know > from our physical/logical point of attachment what the largest possible > MTU for the attached L2 media is - this is a given. That isn't true for Ethernet. A node attaching to an Ethernet has no (standard) way to tell whether the switch it connects to supports jumboframes or not. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:41:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04035 for ; Tue, 30 Mar 2004 18:41:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj9-0006ZK-V4 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKnZZg012207 for ipv6-archive@odin.ietf.org; Wed, 12 Nov 2003 15:49:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1vg-00039z-85 for ipv6-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 15:49:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08623 for ; Wed, 12 Nov 2003 15:49:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1vd-0005ue-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:49:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK1vb-0005u7-00 for ipv6-web-archive@ietf.org; Wed, 12 Nov 2003 15:49:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1vC-0002vx-Vk; Wed, 12 Nov 2003 15:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1uT-0002gE-28 for ipv6@optimus.ietf.org; Wed, 12 Nov 2003 15:48:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08545 for ; Wed, 12 Nov 2003 15:48:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1uR-0005t8-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:48:15 -0500 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 1AK1uO-0005sX-00 for ipv6@ietf.org; Wed, 12 Nov 2003 15:48:12 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id hACKldkF238196 for ; Wed, 12 Nov 2003 15:47:39 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-244-127.mts.ibm.com [9.65.244.127]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hACKlabQ151626 for ; Wed, 12 Nov 2003 13:47:37 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id hACKiVM03342 for ; Wed, 12 Nov 2003 14:44:32 -0600 Message-Id: <200311122044.hACKiVM03342@cichlid.raleigh.ibm.com> To: ipv6@ietf.org Subject: FWD: IAB Response to your appeal of October 9, 2003 Date: Wed, 12 Nov 2003 14:44:30 -0600 From: Thomas Narten Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , ------- Forwarded Message From: Leslie Daigle To: Tony Hain CC: iab@ietf.org, iesg@ietf.org, ietf@ietf.org Date: Wed, 12 Nov 2003 14:40:06 -0500 Subject: IAB Response to your appeal of October 9, 2003 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 Tony, This week the IAB completed its deliberations on the appeal you lodged on October 9. I've attached a copy of the appeal response below. We do expect to give a brief presentation of this response at this evening's IETF plenary, with time for more questions during the IAB open plenary session tomorrow evening. Regards, Leslie. ======================================== IAB Response to Appeal from Tony Hain On October 9, 2003, the IAB received an appeal against the IESG decision regarding the IPv6 Working Group chairs' declaration of consensus on the issue of site local addresses in the IPv6 address architecture (Attachment A). 1. The Appeal Question The IAB interpreted this appeal to be as follows: The appeal is that the IESG, in upholding the IPv6 Working Group chairs' and Internet Area ADs' decisions relating to the declaration of consensus on the issue of deprecation of site local addresses in the IPv6 address architecture, made an incorrect decision. 2. The Basis of the Appeal The appeal is using the process described in Section 6.5.2 of the "Internet Standards Process" (RFC 2026), namely: Should the complainant not be satisfied with the outcome of the IESG review, an appeal may be lodged to the IAB. The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing and report to the IETF on the outcome of its review. If circumstances warrant, the IAB may direct that an IESG decision be annulled, and the situation shall then be as it was before the IESG decision was taken. The IAB may also recommend an action to the IESG, or make such other recommendations as it deems fit. The IAB may not, however, pre-empt the role of the IESG by issuing a decision which only the IESG is empowered to make. The IAB decision is final with respect to the question of whether or not the Internet standards procedures have been followed. 3. The Process used by the IAB to Review the Situation The question raised by the appeal from the perspective of the IAB is whether the Internet Standards Process been followed in the determination of Working Group consensus and the subsequent appeal- based reviews on the issue of deprecation of site local addresses in the IPv6 address architecture. The procedure used by the IAB in responding to this appeal has included - review of the documentation of the IETF's standards procedures and a working group's declaration of consensus, as described in RFC 2026 and RFC 2418, - review of the history of this appeal, and the process used and evidence gathered by the IESG in responding to the appeal directed to the IESG, - review of the video recording of the meeting of the IPv6 working group at the 56th IETF, where the original question concerning site local addresses was put to the working group, and - review of the IPv6 Working Group mailing list following the 56th IETF to ascertain what followup actions were taken within the Working Group leading to the declaration of Working Group consensus on this topic, and - review of email on the thread "Appeal to the IAB on the site-local issue" on the IETF mailing list. 4. IAB Considerations 4.1 Review of Internet Standards Procedures RFC 2026 notes "the importance of establishing widespread community consensus" within the operation of Internet Standards process. The document also notes that disputes may be related to technical disagreements or the process used by the Working Group to reach an outcome. i) RFC 2026, Section 6.5.1, Working Group Disputes "An individual (whether a participant in the relevant Working Group or not) may disagree with a Working Group recommendation based on his or her belief that either (a) his or her own views have not been adequately considered by the Working Group, or (b) the Working Group has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy. The first issue is a difficulty with Working Group process; the latter is an assertion of technical error. These two types of disagreement are quite different, but both are handled by the same process of review." The procedure for Working Group meetings is detailed section 3 of the "Working Group Guidelines" (RFC2418) document. Relevant excerpts from this section of RFC 2418, "IETF Working Group Guidelines and Procedures" are: ii) RFC 2418, Section 3, Working Group Operation: "The IETF has basic requirements for open and fair participation and for thorough consideration of technical alternatives. Within those constraints, working groups are autonomous and each determines most of the details of its own operation with respect to session participation, reaching closure, etc. The core rule for operation is that acceptance or agreement is achieved via working group "rough consensus". iii) RFC 2418, Section 3.1, Session Planning: "the [Working Group] Chair(s) MUST publish a draft agenda well in advance of the actual session. The agenda should contain at least: - The items for discussion; - The estimated time necessary per item; and - A clear indication of what documents the participants will need to read before the session in order to be well prepared." iv) RFC 2418, Section 3.2, Session venue: "Decisions reached during a face-to-face meeting about topics or issues which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed on the mailing list." "While open discussion and contribution is essential to working group success, the Chair is responsible for ensuring forward progress." v) RFC2418, Section 3.3, Session management: "Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached." "In the case where a consensus which has been reached during a face- to-face meeting is being verified on a mailing list the people who were in the meeting and expressed agreement must be taken into account. If there were 100 people in a meeting and only a few people on the mailing list disagree with the consensus of the meeting then the consensus should be seen as being verified. Note that enough time should be given to the verification process for the mailing list readers to understand and consider any objections that may be raised on the list. The normal two week last-call period should be sufficient for this." "The challenge to managing working group sessions is to balance the need for open and fair consideration of the issues against the need to make forward progress." "It is occasionally appropriate to revisit a topic, to re-evaluate alternatives or to improve the group's understanding of a relevant decision. However, unnecessary repeated discussions on issues can be avoided if the Chair makes sure that the main arguments in the discussion (and the outcome) are summarized and archived after a discussion has come to conclusion." 4.2 Review of the background of this appeal, and the process used and evidence gathered by the IESG References to the material reviewed are listed in Attachment B. The April 10 appeal to the Area Directors and the April 31 appeal to the IESG both claimed that the Working Group Chairs asked an ambiguous question of yes/no for deprecation, both at the meeting and subsequently on the list. The IESG reply on September 30 was that the question asked by the chairs at the meeting and on the mailing list was clear and precise. The IESG reply on Sept. 30 also contends that the spectrum of choices, included the limited use model, had been adequately presented at the SF meeting. The IAB noted that the IESG, in undertaking its review of the appeal had reviewed the text of the Area Director's response to the appeal to the Area Director, the Area Director's summary to the IESG of the issue, the videotape of the IETF 56 Working Group meeting, and the mailing list archives. It was noted that not all IESG members reviewed every item in this collection of material. The IESG noted to the IAB that it had unsuccessfully attempted to seek clarification of the appeal from the appellant. The IESG chose to treat the appeal as an appeal about the declaration of consensus by the chairs at the IPv6 Working Group meeting during IETF 56, and noted that the IESG regarded the video of this meeting as the most central piece of evidence. Since this was regarded as a process appeal, not an appeal on technical substance, the events that transpired in the meeting, and their relationship to the description about declaration of consensus within the Internet Standards Process, were reported by the IESG as the central points they considered in reaching their decision on the appeal. 4.3 Review of Video Recording A review of the video recording of the IETF56 IPv6 Working Group meeting was undertaken by Scott Bradner and passed to the IAB on October 13 (Attachment C). IAB members reviewed the video recording and there is broad agreement that the report prepared by Scott Bradner is an accurate summary of the proceedings. The questions put to the Working Group at the meeting were: (1) "how many people want to deprecate the use of IPv6 SL addresses?" and (2) "how many people do not want to deprecate the use of IPv6 SL addresses?" There was evidence of a consensus position within the meeting and the chairs then informed the meeting that this would be then be taken to the mailing list for verification. 4.4 Review of the IPv6 Working Group Mailing List The Working Group Chairs took the declared consensus decision of the Working Group meeting to the IPv6 working group mailing list. The IAB has reviewed the mailing list traffic from the period between the consensus call on April 1, and the declaration of consensus on April 10. The question asked on the mailing list was: "The question is: Should we deprecate IPv6 site-local unicast addressing? Valid responses are: "YES -- Deprecate site-local unicast addressing". "NO -- Do not deprecate site-local unicast addressing"." The mailing list message also included the following notice: "NOTE: DO NOT reply if you already expressed an opinion during the IPv6 WG meeting in SF!" People voting were required to vote either "Yes" or "No" unambiguously. After reviewing the mails sent in response to this question, it is noted that people clearly did so. There was some mailing list traffic indicating that not all members of the working group were entirely clear on the question and text describing deprecation of site local addresses was requested. The view was expressed that the question could imply that the working group should stop working on any address technology that had site-local scope, or that the question could imply that the working group should remove the specification of the site-local prefix FEC0::/10, leaving the potential for the working group to explore a similar approach at a later time. Other working group members indicated that did not see the question as being unclear, and were comfortable that they were making an informed decision when voicing their views on what they felt was a clearly put question. The declaration of consensus by the Working Group on the question was posted to the mailing as follows: "All told, there were over 200 responses to the consensus call on IPv6 site-local addressing, approximately 3-to-1 in favor of deprecating IPv6 site-local unicast addressing. The final count (including the room and the mailing list) was: 155 YES, 56 NO (211 Total)." 4.5 Review of IETF email following the IAB Appeal The IAB reviewed email on on the thread "Appeal to the IAB on the site- local issue" on the IETF mailing list, following the lodging of an appeal with the IAB. The email highlighted two main topics that are of potential relevance: - Does the decision to remove a technology from a proposed standard require a stronger demonstration of consensus that the decision to adopt a technology? Various views were expressed on this question within the mail thread. - Was the decision regarding site local addresses a decision related to the definition of the address prefix FEC0::/10, or was it a decision to remove site-scoped local addresses from the IPv6 address architecture altogether? 4.6 Further Remarks The appeal notes that: "Contrary to their claim, the full spectrum of choices was not presented at the SF meeting." The appeals process within the IETF is intended to ensure that differences of perspective in the manner of the conduct of the Internet Standards Process are handled at through a number of levels of escalation. It is assumed that when an appeal is passed to the IAB the matter under review is one that has some gravity and substance and is entirely germane to the proper operation of the Internet Standards Process. Appeals can be seen to serve a role as one means of feedback on the quality of the IETF's work in terms of both our ability to adhere to our adopted process and the quality of the process itself. These remarks are addressed to this broader perspective of the role of appeals. The technical topic upon which this appeal is based has been a topic that has engaged the IPv6 Working Group's attention for a number of years, and behind it lie a number of considerations relating to the utility and role of scoped address prefixes within the protocol's address architecture, and the associated issues of routing architectures and deployment considerations. The original approach of the definition of a common site local prefix within the IPv6 address architecture, namely FEC0::/10, introduced the potential issue of addressing clashes in the deployment environment. Given the highly variable definitions of a "site" in the context of deployment environments, and the consequences of leakage of these site- local addresses beyond its intended scope of use, there was a body of opinion that saw this as a potential weak point in the overall protocol architecture. Equally it is apparent that there is a body of opinion that recognizes that there are perceived to be considerable advantages in a structured approach to scoped architectures where local-use utilities could be appropriately supported using local scoped addresses. In this fashion it appeared to be the intention that local use contexts could be supported using automated forms of local use address assignments in a so-called 'plug- and-play' architecture. It has been observed that the IPv6 working group has been grappling with these two perspectives for some time, and progress with respect to the standard forms of use of site-local addresses was not apparent within the IPv6 Working Group for some time due to failure to obtain a clear consensus, albeit rough consensus, over how to balance these two perspectives and complete this part of its chartered activity. It is noted that the Chairs have been diligent in attempting to assist the working group to come to a consensus position on this topic, and the IETF 56 meeting was intended to proceed further on the positions that the Working Group had shown some level of preference at the IETF 55 meeting. The Chairs noted the emerging consensus position in the IETF 56 working group meeting, and elected to put the question to the working group that reflected this position. The appeal to the IAB notes that within this course of events, there was no documentation at the IETF 56 meeting of the option of complete removal of the site-local prefix from the address architecture, nor was there a requirements draft for locally-scoped addresses, nor were there drafts that considered the implications of the elimination of this prefix, or its retention within the address architecture. As noted in the comments received by the IAB, and noted in a review of the mailing list archives, this did lead to the comment being made that the question was not sufficiently clear to all working group members. This consideration highlights the question received by the IAB regarding the possible need for a stronger demonstration of consensus for a decision to deprecate a technology from a proposed standard than that required to adopt a technology. A possible rephrasing of this question is to what degree should the working group carefully consider the implications of deprecation in the form of preparation of working group drafts that attempt to clearly define the intended action and explore the consequences and potential alternative approaches prior to making a consensus decision. This consideration would need to be balanced against the need to ensure that IETF Working Groups can operate effectively and efficiently, and that each Working Group consensus decision does not get unduly enmeshed in an increasing level of process overheads that may ultimately cause a Working Group to cease to make any progress at all. However, with regards to the protocol for IETF appeals, the appeal to the IAB is an appeal of the IESG's ruling on the prior appeal to the IESG. Broadening the terms of the appeal at this point in time is not within the intended scope of the appeals process. For this reason the IAB feels that above question is not properly within the scope of the appeal of the IESG decision. If the IETF is of the view that this question is of sufficient validity to warrant further study, then it is appropriate that it should be considered within the existing process of chartering a IETF working group activity relating to a review of the Working Group Procedures and the Internet Standards Process, rather than as part of any formal outcome of this appeal to the IAB. The appeal raises the question: "was this a vote about removing ambiguity from the site-local prefix, or removing limited routing scope from the architecture?" The appeal cites as evidence: "Which returns us to the ambiguity of the original question, was this a vote about removing ambiguity from the site-local prefix, or removing limited routing scope from the architecture? People expressed opinions about each of those as the basis of their yes vote" The questions posed to the working group by the chairs at the IETF 56 meeting were: "how many people want to deprecate the use of IPv6 Site Local addresses?" and "how many people do not want to deprecate the use of IPv6 Site Local addresses?" The question mailed to the ipv6 working group mailer was: "Should we deprecate IPv6 site-local unicast addressing?" It is observed that while a Working Group makes progress through rough consensus, this consensus refers to working group consensus questions, as distinct to a formation of a consensus among working group members as the basis for their reasons to support a particular response to the consensus question. In terms of the question of the ambiguity of the question, this can be posed as whether the term "deprecate IPv6 Site Local Addresses" is inherently ambiguous to a IPv6 working group member. It is noted that in the IPv6 address architecture the concept of a "Site-Local Address" is defined as a set of constraints on those addresses that use the prefix FEC0:/10. Within the mail archives of the working group, the Working Group's use of the term "IPv6 site-local address" has been consistently used to mean the FEC0::/10 prefix together with the described set of constraints associated with this prefix in the address architecture specification. In this light is it reasonable to conclude that "deprecate IPv6 Site Local Addresses" refers to the deprecation of the part of the IPv6 address architecture specification that describes the FEC0::/10 prefix and its associated constraints. In the view of the IAB, we believe that terminology used in the question was consistent with the working group's normal usage of this terminology. 5. IAB Consideration of the Appeal The IAB finds that: - While this was a topic with a considerable history of consideration within the Working Group's activities, the Working Group adopted a direction within its IETF 56 meeting that wasn't well signaled in advance in the meeting's agenda material, in the documents prepared for consideration on the topic and in the conduct of this part of the meeting. However, the Chairs of the Working Group were acting within the parameters of conduct of Working Groups in calling the question at the meeting in response to evidence of a possible consensus on the question. The subsequent validation of this consensus decision on the WG mailing list was a necessary and useful adjunct to the WG meeting. The meeting poll was not a decision taken in isolation or taken without subsequent consideration. - This decision was reflective of the consensus position of the Working Group and was not an instance of the use of incorrect or improper process. The Working Group Chairs declaration of Working Group rough consensus on the question was made in accordance with IETF process. - There is no current documentation that requires any additional or altered procedure to that of rough consensus when deprecating a technology from an Internet standard, as compared to the adoption of a technology. - The IESG undertook a diligent investigation into the declaration of consensus by the Working Group chairs, and had gathered all the relevant inputs. The IAB in their review found that there is nothing obvious that was omitted in the IESG investigation and the IESG interpretation of the appeal as a process appeal is consistent with the data the IESG gathered. - that the IESG's decision not to uphold the appeal was consistent with available evidence, and consistent with the IETF documented processes for working group conduct and consistent with the Internet Standards Process. The IAB finds that the IESG decision, namely to uphold the IPv6 Working Group chairs' and Internet Area ADs' decisions relating to the declaration of consensus on the issue of deprecation of site local addresses in the IPv6 address architecture, was consistent with the available evidence and consistent with documented IETF process. Accordingly, the IAB upholds the IESG decision in this matter. Attachment A ------------ Text of the Appeal to the IAB From: "Tony Hain" To: "IAB" Cc: "The IESG" , , "IETF" Subject: Appeal to the IAB on the site-local issue Date: Thu, 9 Oct 2003 16:59:38 -0700 I am saddened that it has come to this, but the IESG action has simply prolonged the process. The only clarity in their '...somewhere to the left...' justification is their willingness to let personal technical biases blind them to the process failure. As such, please consider this note to be an appeal to the IAB against the IESG decision to reject my appeal. Contrary to their claim, the full spectrum of choices was not presented at the SF meeting. Then, if it weren't for the seriousness of the issue, their inability to do a quick check of the Atlanta minutes (which shows that 125 attendees were against complete removal, not the limited model) would be humorous. In response to the overwhelming rejection of her preferred path, in Atlanta the chair declared 'The wg has agreed we don't want to remove them completely ...' so there was no documentation developed discussing the impacts of complete removal. Therefore there could be no substantive presentation of that position. As noted in my original 4/10/2003 appeal to the chairs, the mail list claims that the RFC 3513 Site-Local addresses 'have issues that outweigh the benefits', or 'does not meet the requirements' are invalid because there was no document listing the requirements, therefore no way to conduct an evaluation which would justify those positions. This lack of documentation became acute when the participants from the applications area were invited to join in the discussion. While I acknowledge that cross area participation helps refine the specifications (and had personally been lobbying the Apps Area to participate), that refinement only happens through extended discussion and informed debate. An hour and twenty minutes of inciting the mob does not constitute informed discussion. In fact 10 minutes before the question, Dave Thaler pointed out there was no draft about elimination, but that detail was ignored by the chair. Shortly after that, Brian Carpenter pointed out that he couldn't vote for keeping SL unless he knew the details of that outcome, to which the chair eventually countered we don't have any details about what it means to remove them either and 'we may have to wave our hands around a little bit'. The chair chose to conduct the vote with no clear outcome for either position, leaving the result that the chair could later tell the working group what it had decided. The further comment by the IESG that the action has resulted in working group activity to address the issues is equally flawed. There were attempts to disambiguate the FEC0 space prior to the SF fiasco, but those were consistently savaged by those who want nothing more than to declare the routing space to be globally flat by IETF fiat. Those same people are working to prevent a different form of local prefix from being defined, and now are feeling emboldened as it appears that this current work is an addition to the architecture rather than a refinement. Which returns us to the ambiguity of the original question, was this a vote about removing ambiguity from the site-local prefix, or removing limited routing scope from the architecture? People expressed opinions about each of those as the basis of their yes vote, but the scope of routing is an operational decision of network managers, therefore not something the IETF gets to decide. Since the votes were mixed as a common Yes, the vote must be invalidated. At every step, this exercise has exposed failures in how the IETF conducts its business. It is now up to the IAB to recommend that the IESG go back, *seriously* set aside their technical biases, and reconsider the process breakdowns. Anything less and we set the precedent that it really doesn't matter how badly a chair abuses the process as long as the IESG agrees with the outcome. Tony FYI: video of the SF session: ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56 > The IESG has reviewed the appeal by Tony Hain of the IPv6 Working Group > chairs' declaration of consensus on the issue of site local addresses in > the IPv6 address architecture. > > Tony's appeal requests that the declaration of consensus be > overturned due > to the ambiguity of the question asked. > > As is to be expected of a technical discussion where there are many > opinions, the discussion of the site-local issue at the San > Francisco IETF > meeting went all over the map, with many unanswered questions. > However, the question asked by the chairs, with clarification from > the AD, was clear. "Does the group want to go away from site-local > addressing, deprecate it, work out how to get it out, [or] does > the group want to keep it and figure out what the right usage model > is for it?" The clarifying statement was "Deprecate [...] means > somewhere to the left of the 'limited use' model?" The spectrum > of choices, including the 'limited use' model, had been presented > during that same meeting. Although the group had decided to > rule out the 'limited use' model (and presumably anything to the > left of it as well) in Atlanta, nothing precludes new information > from prompting a review of old decisions. > > The question posed on the list was more concise, simply "Should we > deprecate IPv6 site-local unicast addressing?" This question is > not ambiguous. > > The deprecation of site-local addresses in their current form has > served a useful role in forcing the working group to recognize the > problems that the original definition had and work to address them. > The IESG finds nothing unusual about how the question was asked or > how the working group has proceeded. > > There is strong consensus in the IESG that deprecation is the > correct technical decision, but we have done our best to separate > our technical preferences from the process issue in considering > this appeal. > > In summary, the IESG upholds the chairs' and INT ADs' decisions. > > The IESG > Attachment B ------------ References to documentation and related material reviewed by the IAB November 2003, Atlanta IETF: Brian Haberman, "Routing and Forwarding of Site Local Addresses", 55th IETF. http://www.ietf.org/proceedings/02nov/slides/ipv6-5.pdf Rob Austein, Connected Site-Local Considered Harmful, 55th IETF. http://www.ietf.org/proceedings/02nov/slides/ipv6-6.pdf Minutes from the IPv6 Working Group at the Atlanta IETF: http://playground.sun.com/pub/ipng/html/minutes/ipv6-minutes-nov2002.txt March 2003, M. Wasserman, The Impact of Site-Local Addressing in Internet Protocol, Version 6 (IPv6). http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.txt March 2003, San Francisco IETF meeting: Bob Hinden and Margaret Wasserman, IPv6 Site-Local Discussion, 56th IETF http://www.ietf.cnri.reston.va.us/proceedings/03mar/slides/ipv6-3/index.html Page 3 lists the range of use cases: No site-local; limited; exclusive; moderate; full-usage. Minutes: http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt April 1, Hinden and Wasserman, Consensus Call. ftp://playground.sun.com/pub/ipng/mail-archive/, ipng.200304, Message-Id: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> * "The question is: Should we deprecate IPv6 site-local unicast addressing?" April 9, Hinden and Wasserman, Declaration on Consensus. ftp://playground.sun.com/pub/ipng/mail-archive/, ipng.200304, Message-Id: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> * This is the IPv6 Working Group chairs' declaration of consensus on the issue of site local addresses in the IPv6 address architecture. * "there were over 200 responses to the consensus call on IPv6 site-local addressing, approximately 3-to-1 in favor of deprecating IPv6 site-local unicast addressing." * "The IPv6 WG will work to accomplish the following things in parallel:" April 10, appeal to the ADs: ftp://playground.sun.com/pub/ipng/mail-archive/, ipng.200304, Message-Id: <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings> * "the chairs decided to call an ambiguous question of yes/no for deprecation" * "the call ended up combining yes opinions for removing ambiguity with yes opinions for removing local scope addresses from the architecture." July 31, appeal to the IESG: http://www.ietf.org/IESG/APPEALS/tony-hain-appeal.txt Appeal claims: * The chair asked an ambiguous question. * The question asked to the list was no clearer. August 26: draft-ietf-ipv6-deprecate-site-local-00.txt, by Huitema and Carpenter. Now draft-ietf-ipv6-deprecate-site-local-01.txt Sept. 16 email from Hinden and Haberman to ipv6@ietf.org on "Results of Poll" Sept. 30, IESG reply to the appeal: http://www.ietf.cnri.reston.va.us/IESG/APPEALS/iesg_tony_hain.txt In the IESG reply to the appeal, the IESG found that: * The question asked by the chair, with clarification from the AD, was clear; * The question posed on the mailing list was clear and concise. * The spectrum of choices, included the limited use model, had been presented at the meeting. * Although the group had decided to rule out the limited use model in July, "nothing precludes new information from prompting a review of old decisions". October 9, Hain, appeal to the IAB. http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00239.html Appeal claims: * The full spectrum of choices was not presented at the SF meeting; * The co-chairs didn't check the Atlanta minutes showing 125 attendees against complete removal; * There was no documentation at the meeting of the complete removal option. * Claims on the mailing list that site-local addresses don't meet the requirements are invalid because there is no requirements document. * The chair conducted the vote with no clear drafts about the elimination or the keep-site-local options. * It was not clear whether the vote was about removing ambiguity from the site-local prefix, or about removing limited routing scope from the architecture. "Since the votes were mixed as a common Yes, the vote must be invalidated." Email archives: ftp://playground.sun.com/pub/ipng, then http://www1.ietf.org/mail-archive/working-groups/ipv6/current/maillist.html Attachment C ------------- Review of recording of the IPv6 Working Group Session Excerpts from mail from Scott Bradner to the IAB describing a review of a video recording of the IPv6 Working Group meeting. Date: Mon, 13 Oct 2003 12:28:49 -0400 (EDT) From: Scott Bradner To: iab@ietf.org Subject: Re: Appeal to the IAB on the site-local issue Cc: iesg@ietf.org, ietf@ietf.org ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56%20-%2003202003%20-%20INT%20ipv6.rm The SL discussion starts at 1:02 into the session. The chairs first presented a set of slides talking about various SL related options. The presentation was interrupted with questions from the floor quite a few times during the discussion of the "exclusive" model (wherein a v6 node would be a SL node of a global addressing node) - it was clear to me that there was quite a bit of confusion about this model. There were few interruptions during the discussions about the other models. The chairs opened the floor for general discussion at 1:39 into the session. The discussion was careful and extensive. After a while it became clear, as noted by Thomas [Narten], that more people were arguing for eliminating SL than had been the case in the past and few people were arguing for SL addressing. Those that were arguing in favor of SL mostly said that SL and v6 NATs were going to happen anyway but no one seemed all that concerned that the IETF define such addresses (e.g. Deno pointed out that people would just pick their own if the IETF did not.) At 2:07 into the session the chairs conferred and said that they would ask a simple yes or no question (in reality they asked two questions) about deprecating IPv6 SL addresses. (Not eliminate them in that the sense that the prefix would not be reassigned for other uses.) Margaret noted that the simple questions covered a lot of details that were not called out. After 10 minutes of discussion to clarify the intent of the questions Margaret asked for a show of hands for: 1/ how many people want to deprecate the use of IPv6 SL addresses? 2/ how many people do not want to deprecate the use of IPv6 SL addresses? She asked the first question twice so they could get a count of hands the second time. The result was 102 hands in favor of deprecating and 20 opposed. The chairs declared that there was rough consensus in the session to deprecate the use of IPv6 SL addressing but that this consensus would now be taken to the list to verify. Date: Tue, 14 Oct 2003 11:17:44 -0400 (EDT) From: Scott Bradner To: iab@ietf.org Subject: RE: Appeal to the IAB on the site-local issue Cc: iesg@ietf.org, ietf@ietf.org Yesterday I posted a message that said that I agreed with the IPv6 working group chairs that rough consensus was reached to deprecate IPv6 site local addresses. That said, I do have an issue on the discussion that led up to that consensus decision. I do not think there was much of an actual discussion on the topic. The working group chair's presentation on the site local options listed five options for the working group moving forward in regards to the site local question. These options ranged from eliminating site local addresses to fully embracing the concept and working out all the details of how to use them. But they only discussed the middle three options. They reported that the consensus in the Atlanta meeting was to not support outright elimination or full embrace so those options were not included in the chair's presentation of the advantages and disadvantages of the various options. The discussion during the chair's presentation basically did not touch on the pros and cons of having site local addresses per se - a few 'they should just go away' statements were made but no exploration of the issues. The open discussion after the presentation also did not explore the issues but there were a greater number of people who felt that SL addresses should be eliminated from IPv6. As I mentioned in yesterday's note - Thomas and others noticed the sentiment against SL and the chairs wound up asking the question they did (about deprecating SL) as a result. ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:41:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04211 for ; Tue, 30 Mar 2004 18:41:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj8-0006WI-My for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LCacm3019824 for ipv6-archive@odin.ietf.org; Tue, 21 Oct 2003 08:36:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvkb-00059c-2F for ipv6-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 08:36:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15554 for ; Tue, 21 Oct 2003 08:36:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABvkZ-00031N-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 08:36:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABvkY-00031K-00 for ipv6-web-archive@ietf.org; Tue, 21 Oct 2003 08:36:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvkC-0004wY-Of; Tue, 21 Oct 2003 08:36:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvjo-0004s9-Us for ipv6@optimus.ietf.org; Tue, 21 Oct 2003 08:35:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15523 for ; Tue, 21 Oct 2003 08:35:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABvjn-00030f-00 for ipv6@ietf.org; Tue, 21 Oct 2003 08:35:47 -0400 Received: from [195.41.29.4] (helo=ursa.amorsen.dk) by ietf-mx with esmtp (Exim 4.12) id 1ABvjn-00030W-00 for ipv6@ietf.org; Tue, 21 Oct 2003 08:35:47 -0400 Received: from [10.0.0.217] (lion2.ipservice.dk [212.242.77.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ursa.amorsen.dk (Postfix) with ESMTP id E72CB1C136 for ; Tue, 21 Oct 2003 14:35:15 +0200 (CEST) Subject: Re: IPv6 adoption behavior From: Benny Amorsen To: ipv6@ietf.org In-Reply-To: <20031021121506.GA18743@fries.net> References: <200310142211.SAA04345@ss10.danlan.com> <20031021121506.GA18743@fries.net> Content-Type: text/plain Message-Id: <1066739712.1777.16.camel@vega.amorsen.dk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-5) Date: Tue, 21 Oct 2003 14:35:12 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 2003-10-21 at 14:15, Todd T. Fries wrote: > I'm sorry to reply late to this, but I can't help but realize that > NAT+IPv4 vs IPv6+firewall can be equivalent in `isolation'. Simply > `block in all' and `pass out on $ext_if keep state' (in the pf terms of > OpenBSD) and in two rules you have the same isolation of a NAT+IPv4 as > you do with IPv6+firewall. Imagine that two internal hosts are communicating in your scenario. They have a TCP connection running for weeks. Then the outside connection to the Internet breaks and is brought back up, but assigned a different address. In the IPv4+NAT case hosts that only contact other hosts on the internal network do not notice the failure at all. In the IPv6+firewall case the new addresses are provided to the hosts and eventually the old addresses time out -- and the internal TCP connection breaks. Ouch. /Benny -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:41:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04247 for ; Tue, 30 Mar 2004 18:41:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj8-0006ZK-VJ for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SJjNlN025036 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 14:45:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxAOo-0006Vi-QA for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 14:45:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29503 for ; Sat, 28 Feb 2004 14:45:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxAOl-0007X8-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 14:45:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxANr-0007Qt-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 14:44:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxAN4-0007KZ-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 14:43:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxAMY-0005o8-Di; Sat, 28 Feb 2004 14:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxAM8-0005nK-Mv for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 14:42:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29345 for ; Sat, 28 Feb 2004 14:42:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxAM5-0007Bu-00 for ipv6@ietf.org; Sat, 28 Feb 2004 14:42:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxAL5-00074G-00 for ipv6@ietf.org; Sat, 28 Feb 2004 14:41:32 -0500 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1AxAKS-0006xN-00 for ipv6@ietf.org; Sat, 28 Feb 2004 14:40:52 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA06089; Sat, 28 Feb 2004 14:40:43 -0500 (EST) Date: Sat, 28 Feb 2004 14:40:43 -0500 (EST) From: Dan Lanciani Message-Id: <200402281940.OAA06089@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,MLM,NO_COST autolearn=no version=2.60 Bill Manning wrote: |% Bill Manning wrote: |% |% | be prepared to defend yourself in court(s) in any number of |% | jurisdictions. |% |% Against whom exactly would he be defending? Presumably the litigation would |% be initiated by someone who had a financial stake in the matter. Are you |% acknowledging that the current address rental model exists for profit rather |% than as a solution to the technical problem of address & routing table slot |% consumption? | | I am not impuning anything wrt routing table issues. Your original comments suggested (at least to me) that you believed that someone would have a stake in challenging the rent-free nature of the allocations itself; however, your hypothetical concerns a vanilla dispute over a particular allocation. | Positing a US based example... GE uses FD00:42:: | Ford uses FD00:42:: - the prefixes become entrenched | in their respective corporate cultures. A tiff breaks out | and they go to court and cite the IESG & the then current (I assume you are using "cite" to mean "make a claim against." Obviously if the citation is just a reference then the IESG has nothing to defend against.) | WG chairs for the creation of address blocks as property. The problem here is that it isn't at all clear how the rent-free nature of the allocation was causal of the (presumably) unintentional prefix duplication. The litigants could certainly complain that the IESG had failed to take sufficient steps to insure duplicate-free allocations, but then they could do that in the rental scenario as well. In fact, they might have a stronger case if they were paying rent since they might expect to get something for their money. Moreover, given that allocations in the FD00::/8 prefix are not guaranteed to be unique in the first place, the property right created is at most a non-exclusive one. This (along with the clearly available FC00::/8 alternative) would seem to make their complaint pretty shaky. Finally, the hypothetical as stated is itself a little odd because the litigants would be contesting the creation of the very property right which they seek to enforce (or even to expand). Granted the arguments aren't completely mutually exclusive, but would anyone really risk undermining their own case just to pull in the IESG and chairs as co-defendants? What kind of remedy could they seek from the IESG? It's not like it or the chairs could wave a magic wand and make the conflict go away. Any monetary damages GE or Ford might extract would be insignificant to those companies--surely not worth the bad PR. I really think you are attempting to find a problem where none exists. On the flip side, note that a rental model is hardly proof against legal troubles: just look at the constant issues surrounding domain names. | this is -NOT- how the current address delegation model works. You and other opponents of the current proposal keep stating this as if it were a justification for forcing the address rental model on non-routables. The routable address delegation model exists for (allegedly) technical reasons that are not applicable to non-routables. Year after year proposals for routable PI space have been met with hand-waving "technical" arguments about something-or-other growing exponentially in something-or-other-else. The current proposal accomplishes (if nothing else) a distillation of the PI argument to its purest form, free from technobabble. We seem to be left with dire legal warnings and the old standby: ``it has to be that way because something else is that way.'' I find this very educational. |% | You should check w/ the RIRs on their role/position |% | wrt legal precident on address/prefix ownership. |% |% Umm, wouldn't they (at least some of them) be a bit biased since it is |% additional revenue that they might want for themselves? | | what revenue? The revenue from renting the addresses that would be available at no cost under the current proposal. |% | You should |% | have the ISOC/IETF legal team review the creation of property rights |% | by the WG chairs and the IESG. |% |% How do these allocations create property rights any more than the original |% IPv4 allocations used before the rental model was introduced? | | the early delegations have very nebulous documentation (mostly) | as to the terms and conditions under which they were delegated. It was fairly clear at the time that the allocations were permanent. If you look at the history of hierarchical allocation and CIDR you will find the original promise that that _temporary_ hack would not deprive owners of their address portability. Yes, you were going to get your addresses from your current provider initially, but you would still be able to take them with you when you moved because they were _your_ addresses. Of course the cynical among us didn't believe that promise for a minute, but the fact that it was used to sell folks on the scheme says something. | That is not the case here. So is it really just the "level" of permanence that is at issue here? What if we said that the addresses are delegated to end users in just the same way that they are delegated to current "topmost" holders, that there will never be a recurring cost (monetary or other) to the end user, but that the addresses can be revoked en masse in conjunction with (and only in conjunction with) a similar revocation of the delegations to the other holders, should there be a technical reason for so doing? This might provide a solution that is permanent enough for many end users while creating no property rights beyond those already enjoyed by existing address holders. The requirement for en masse revocation avoids the need to keep track of individual allocations. |% | Its not going to be easy and its |% | not clear the effort justifies the exposure, at least to me. |% |% It is true that these days it is possible to cook up a legal storm about |% almost anything. What is the true reason for doing so in this case? | | The IETF is making a fundamental change in address delegation | policy No, it is simply _not_ propagating a special-case policy to a new class of address space for which that special-case policy is not appropriate. |w/o consultation with the existing, operational groups | who manage address delegations. Why exactly should those groups have a say in the matter? After all, if they have no property rights in the revenue streams they derive from address rentals then surely the IETF is not obligated to preserve/extend those (non) rights. |% | If you do this, I will have to rethink my use of IPv6 as tainted |% | goods. |% |% I think a lot of folks will rethink their use of IPv6 if they can't get |% permanent address space. | | No space delegations are permanent. I await the revocation of net 10... |% | The IETF should stick to -PROTOCOL- development, not create |% | property rights to be fought over in courts. |% |% But the IETF has already (at least indirectly) created property rights--and |% very valuable ones--for the registries and ISPs who rent addresses. A rental |% property is still a property. Your complaint seems to be with property rights |% for end users, not with property rights in general. | | That was not the IETF. The IETF creates the hierarchical allocation model that in turn enables the address rental business with its associated property rights. |That was governments and operators. | The IAB concured with these groups in establishing RIRs. | | And if you will take the time to review the legal history, | you will note that the RIRs do not claim ownership. Obviously there are different levels of "ownership." Regardless of what RIRs may claim, they do by their actions assert various property rights in the address blocks they manage. The right to rent an object (abstract or tangible) and retain the revenue so generated is a property right. |In fact | US legal precident (and in other venues as well) indicates | that address delegations are -NOT- property/assets. Certainly RIRs have argued successfully that delegations in the hands of end users are not property. Yet at the same time those registries reserve to themselves some additional rights (e.g., the right of transfer), thus suggesting that they hold the addresses with a higher level of ownership than end users. Again, these policies and structures were created--and the cases argued--on the grounds that such measures were necessary to conserve address space and to allocate that address space in such a way that it would aggregate for routing purposes. Those considerations do not apply to the new address space under discussion. The address MLM juggernaut that exists as a side effect of the (alleged) requirements for _routable_ address space does not justify its own perpetuation in new areas where those requirements do not exist. |RIRs | are custodians. As I suggested above, what if we allow end users to act as custodians at a level parallel to RIRs, rather than at a subservient level? Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:42:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04357 for ; Tue, 30 Mar 2004 18:42:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj7-0006ZK-Cz for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B71aHV019805 for ipv6-archive@odin.ietf.org; Sat, 11 Oct 2003 03:01:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Dkq-00058q-Jk for ipv6-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 03:01:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24002 for ; Sat, 11 Oct 2003 03:01:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Dkl-0001Hs-00 for ipv6-web-archive@ietf.org; Sat, 11 Oct 2003 03:01:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8Dkl-0001Hp-00 for ipv6-web-archive@ietf.org; Sat, 11 Oct 2003 03:01:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8DkU-0004yr-OS; Sat, 11 Oct 2003 03:01:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8DjR-0004vK-5c for ipv6@optimus.ietf.org; Sat, 11 Oct 2003 03:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23934; Sat, 11 Oct 2003 02:59:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8DjL-0001GV-00; Sat, 11 Oct 2003 02:59:59 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A8DjK-0001GG-00; Sat, 11 Oct 2003 02:59:59 -0400 Subject: RE: Removing features MIME-Version: 1.0 Date: Fri, 10 Oct 2003 23:59:24 -0700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Removing features thread-index: AcOPxEeLrxkiYRECSlaDbzRi1BP3ZwAANPkw From: "Michel Py" To: "Leif Johansson" , "Iljitsch van Beijnum" Cc: , , , , Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Leif Johansson wrote: > Tell that to the root zone operators and brace for the reaction. Root zone operators, meaning like Verisign? Michel. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:42:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04504 for ; Tue, 30 Mar 2004 18:42:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj6-0006ZK-VO for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PKAJt8004050 for ipv6-archive@odin.ietf.org; Wed, 25 Feb 2004 15:10:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5MC-0000xr-Ma for ipv6-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 15:10:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09739 for ; Wed, 25 Feb 2004 15:10:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5M9-00056Y-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:10:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5L8-000503-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:09:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5KT-0004ue-00 for ipv6-web-archive@ietf.org; Wed, 25 Feb 2004 15:08:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5KF-0008EU-M8; Wed, 25 Feb 2004 15:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5K3-00088m-Rh for ipv6@optimus.ietf.org; Wed, 25 Feb 2004 15:07:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09547 for ; Wed, 25 Feb 2004 15:07:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5K0-0004sJ-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:07:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5JD-0004m6-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:07:08 -0500 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5I7-0004fX-00 for ipv6@ietf.org; Wed, 25 Feb 2004 15:05:59 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA12353; Wed, 25 Feb 2004 15:05:56 -0500 (EST) Date: Wed, 25 Feb 2004 15:05:56 -0500 (EST) From: Dan Lanciani Message-Id: <200402252005.PAA12353@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Bill Manning wrote: | be prepared to defend yourself in court(s) in any number of | jurisdictions. Against whom exactly would he be defending? Presumably the litigation would be initiated by someone who had a financial stake in the matter. Are you acknowledging that the current address rental model exists for profit rather than as a solution to the technical problem of address & routing table slot consumption? | You should check w/ the RIRs on their role/position | wrt legal precident on address/prefix ownership. Umm, wouldn't they (at least some of them) be a bit biased since it is additional revenue that they might want for themselves? | You should | have the ISOC/IETF legal team review the creation of property rights | by the WG chairs and the IESG. How do these allocations create property rights any more than the original IPv4 allocations used before the rental model was introduced? | Its not going to be easy and its | not clear the effort justifies the exposure, at least to me. It is true that these days it is possible to cook up a legal storm about almost anything. What is the true reason for doing so in this case? | If you do this, I will have to rethink my use of IPv6 as tainted | goods. I think a lot of folks will rethink their use of IPv6 if they can't get permanent address space. | The IETF should stick to -PROTOCOL- development, not create | property rights to be fought over in courts. But the IETF has already (at least indirectly) created property rights--and very valuable ones--for the registries and ISPs who rent addresses. A rental property is still a property. Your complaint seems to be with property rights for end users, not with property rights in general. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:43:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04539 for ; Tue, 30 Mar 2004 18:43:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj6-0006WI-My for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OAvahB016516 for ipv6-archive@odin.ietf.org; Fri, 24 Oct 2003 06:57:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACzdP-0004Hw-Ef for ipv6-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 06:57:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25308 for ; Fri, 24 Oct 2003 06:57:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACzdL-0001YT-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 06:57:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACzdK-0001YQ-00 for ipv6-web-archive@ietf.org; Fri, 24 Oct 2003 06:57:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACzcv-00043N-7U; Fri, 24 Oct 2003 06:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACzcN-0003u9-8z for ipv6@optimus.ietf.org; Fri, 24 Oct 2003 06:56:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25237 for ; Fri, 24 Oct 2003 06:56:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACzcI-0001Wg-00 for ipv6@ietf.org; Fri, 24 Oct 2003 06:56:26 -0400 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1ACzcH-0001Vp-00 for ipv6@ietf.org; Fri, 24 Oct 2003 06:56:25 -0400 Received: from pjs3 (pjs2.etri.re.kr [129.254.112.155]) by pec.etri.re.kr (8.12.10/8.12.10) with ESMTP id h9OBAe5l008542 for ; Fri, 24 Oct 2003 20:10:40 +0900 (KST) Message-Id: <200310241110.h9OBAe5l008542@pec.etri.re.kr> Reply-To: From: "jspark" To: Subject: FW: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses" Date: Fri, 24 Oct 2003 19:55:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 11.0.4920 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: AcOZ/N8UAB/E6Pe6S9S6VF6EBzj2ywAAvvwQAAb2raAAAGaLMA== Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----Original Message----- From: jspark [mailto:jspark@pec.etri.re.kr] Sent: Friday, October 24, 2003 7:51 PM To: 'Pekka Savola' Cc: 'mkshin@etri.re.kr'; 'khj@etri.re.kr' Hi Pekka. On Fri, 24 Oct 2003, Pekka Savola wrote: > First, there is typically just one link-local address. > Either it uses EUI-64 based IID or not. Right. So many types of addresses exist such as stateless, stateful, manually etc. > If it doesn't, you can't generate addresses like this. In our spec, we mentioned that EUI-64 IID based LL address is only used. But, I think that stateful or manually configured addresses are also useful because these kinds of addresses are supported by DAD. > Second, the EUI-64 does not guarantee the uniqueness of the method. > Otherwise we would not be needing DAD with addresses that are > generated with EUI-64. Right. The EUI-64 itself is not unique. So, DAD procedure is needed for link-local address. And also stateful or manually configured addresses are used after DAD processing. > But it is mandated by the specs. So > these addresses are > *not* truly, completely, totally, unique. In our spec. The uniqueness of LL unicast address is verified by DAD procedure. And then, EUI-64 IID (or other) is extracted from LL Unicast address. Therefore, our method supposes that LL unicast address should be verified by DAD procedure. Jungsoo. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:43:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04581 for ; Tue, 30 Mar 2004 18:43:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj5-0006WI-Mz for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A8UCi3029216 for ipv6-archive@odin.ietf.org; Fri, 10 Oct 2003 04:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7sf1-0007b8-NK for ipv6-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 04:30:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13891 for ; Fri, 10 Oct 2003 04:29:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7sey-0003pI-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 04:30:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7sey-0003pF-00 for ipv6-web-archive@ietf.org; Fri, 10 Oct 2003 04:30:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7se2-0007R3-6U; Fri, 10 Oct 2003 04:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7sdZ-0007Pv-3M for ipv6@optimus.ietf.org; Fri, 10 Oct 2003 04:28:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13868; Fri, 10 Oct 2003 04:28:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7sdV-0003p1-00; Fri, 10 Oct 2003 04:28:33 -0400 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 1A7sdV-0003oG-00; Fri, 10 Oct 2003 04:28:33 -0400 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 63B1B1C; Fri, 10 Oct 2003 11:41:20 +0300 (EEST) Message-ID: <3F866D9C.6050807@nomadiclab.com> Date: Fri, 10 Oct 2003 11:28:12 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Cc: Multi6 WG , IPV6 WG , MIP6 WG , IPsec WG Subject: An official HIP BOF request has been sent Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Apologies for cross-posting. Please trim the CC: on replies.] Folks, I sent an official BOF request for a Host Identity Protocol BOF a few moments ago. Based on the discussions with the INT area ADs, it looks fairly probable that a BOF will be scheduled. The latest version of the proposed BOF agenda is available at http://www.tml.hut.fi/~pnr/HIP/hipbof.txt The latest version of the proposed WG charter is available at http://www.tml.hut.fi/~pnr/HIP/hip_charter_proposal.txt Note to the IPsec WG: The charter proposal suggest that the new WG would specify a small addition to ESP, basing on draft-nikander-esp-beet-mode-00.txt. Folks at the IPsec WG may have strong opinions on this. The most appropiate place to discuss the BOF and charter proposals is the hipsec mailing list. See the bof agenda and/or charter proposal for details on how to join to the mailing list. The list policy requires non-member postings to be explicitly approved by the list admins. --Pekka Nikander -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:43:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04694 for ; Tue, 30 Mar 2004 18:43:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj5-0006ZK-DJ for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SJjRUt025086 for ipv6-archive@odin.ietf.org; Sat, 28 Feb 2004 14:45:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxAOt-0006WX-Od for ipv6-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 14:45:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29519 for ; Sat, 28 Feb 2004 14:45:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxAOr-0007Xx-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 14:45:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxANx-0007Rs-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 14:44:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxANT-0007Li-00 for ipv6-web-archive@ietf.org; Sat, 28 Feb 2004 14:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxANV-0005v8-JJ; Sat, 28 Feb 2004 14:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxANF-0005tk-Hw for ipv6@optimus.ietf.org; Sat, 28 Feb 2004 14:43:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29431 for ; Sat, 28 Feb 2004 14:43:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxANC-0007LI-00 for ipv6@ietf.org; Sat, 28 Feb 2004 14:43:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxAMG-0007Df-00 for ipv6@ietf.org; Sat, 28 Feb 2004 14:42:44 -0500 Received: from ss10.danlan.com ([199.33.144.62]) by ietf-mx with esmtp (Exim 4.12) id 1AxALe-000757-00 for ipv6@ietf.org; Sat, 28 Feb 2004 14:42:07 -0500 Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA06103; Sat, 28 Feb 2004 14:42:03 -0500 (EST) Date: Sat, 28 Feb 2004 14:42:03 -0500 (EST) From: Dan Lanciani Message-Id: <200402281942.OAA06103@ss10.danlan.com> To: ipv6@ietf.org Subject: Re: Appeal on "Unique Local IPv6 Unicast Addresses" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Alain Durand wrote: |On Feb 27, 2004, at 5:23 PM, Thomas Narten wrote: [...] |> But this |> begs the question of why an end site would ever want to use such |> addresses. I.e, this raises such questions as: |> |> - under what conditions would an address be reclaimed? | |to be decided by the entity(ies) managing the allocation and their |customer by contract. | |> - who does the revokation? | |the entity(ies) responsible for the allocations. | |> - what recourse does the end site have? | |See the contract between the chosen entity and the customer. Your proposed policy where the "chosen entity" has full discretion in how it contracts with its customers does exactly what you claim to want to avoid: it creates a valuable asset consisting of the right to rent the addresses. I ask for the third time: who decides who is allowed to be in the profitable business that you are creating? Who decides who receives the asset that you are creating? How do they decide? |Again, this is policy, not protocol. i.e. this is not IETF business. | | | |> |> My understanding is that the whole point of these allocations being |> "permanent" is that once and ends site gets one, it can use it without |> worry that it will have to give it up at some future time. |> |> Also, why do we need to make these allocations "non permantent"? | |I'm not asking to make them non permanent in the document, but rather |not to |specify in an IETF document that they are permanent. This is different. |If the entity in charge of the allocations decide that permanent |allocation |is the way they want to run their business, fine. How will you guarantee that the option to provide permanent allocation will be available to the entity? Your proposed policy glosses over the issue of registry selection in a competitive, for-profit environment. |> Is |> there some future scenario we're worried about where it becomes |> important to be able to reclaim these addresses? I.e., are they ever |> going to become a scarce resource? | |I'm worried about the scenario where IETF does policy and not protocols |anymore. You are no less proposing policy than the current draft. The problem with your policy is that it omits a key detail which will almost certainly be filled in later in such a way as to perpetuate and enforce the rental model for these new addresses. You have claimed that your policy would allow a free and competitive market to serve its customers, but the market is not free. In order to enter the market an entity needs an address delegation. The requirements placed on the entity to receive that delegation will constrain the business models available to that entity. If the entity has to pay a recurring fee (or even a large initial fee) to be in the business then the entity will not be able to offer cheap/free permanent allocations to its customers. Dan Lanciani ddl@danlan.*com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:44:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04853 for ; Tue, 30 Mar 2004 18:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj4-0006ZK-Fi for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QH61cp028422 for ipv6-archive@odin.ietf.org; Fri, 26 Sep 2003 13:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2w2a-0007OI-I9 for ipv6-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 13:06:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14018 for ; Fri, 26 Sep 2003 13:05:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2w2Y-0003Ju-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 13:05:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2w2Y-0003Jr-00 for ipv6-web-archive@ietf.org; Fri, 26 Sep 2003 13:05:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vzh-0006vo-IT; Fri, 26 Sep 2003 13:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vyu-0006u5-3R for ipv6@optimus.ietf.org; Fri, 26 Sep 2003 13:02:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13877 for ; Fri, 26 Sep 2003 13:02:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2vys-0003Hv-00 for ipv6@ietf.org; Fri, 26 Sep 2003 13:02:10 -0400 Received: from [195.167.170.152] (helo=bowl.fysh.org ident=mail) by ietf-mx with esmtp (Exim 4.12) id 1A2vyr-0003Hs-00 for ipv6@ietf.org; Fri, 26 Sep 2003 13:02:09 -0400 Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 1A2vyj-0004Ax-00; Fri, 26 Sep 2003 18:02:01 +0100 Date: Fri, 26 Sep 2003 18:02:00 +0100 To: Steven Blake Cc: Bob Hinden , ipv6@ietf.org Subject: Re: [I-D ACTION:draft-ietf-ipv6-unique-local-addr-01.txt] Message-ID: <20030926170200.GB28323@fysh.org> References: <4.3.2.7.2.20030925160504.03283e98@mailhost.iprg.nokia.com> <1064592579.342.477.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1064592579.342.477.camel@newcastle.torrentnet.com> User-Agent: Mutt/1.3.28i From: Zefram Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Steven Blake wrote: > don't think it is necessary to be unable to guess the date or > relative order in which a particular ID was allocated, however. Someone will have a reason to want such unguessability. That is sufficient. This is one of those cases where making it work in 100% of cases is worthwhile because it means we don't need to keep in mind the limitations of the compromise that we chose. >3. I don't believe it is essential to have alternative registration > methods besides web and e-mail. I think this should be decided by the other issues that determine whether it is necessary to charge for allocation. If it works out to be feasible, I think we should have no-cost allocation, via an automated web/email system -- no need for distribution of the registration function, no need for the mechanisms to handle payments, and so on. It'd require an investment by someone of the hardware (roughly a PC plus 256GB disk space plus backup provisions -- total cost a couple of thousand dollars), and would lead to a fantastically hassle-free registration process. I think it's worth sacrificing offline means of registration in order to get this simplification. It is only if this really cannot be done that we should accept a non-zero-cost registration process: the need to handle a payment complicates the process for everyone involved, and makes it a lot less accessible than the free-to-end-user system would be. In this system, offline registration mechanisms would effectively come for free alongside the payment-handling infrastructure. > In a dispute one can prove that he or she owns > an allocation by producing a non-repudiatable (e.g., signed) message > from a registry. I note that the automated system I suggest above can do this admirably. -zefram -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:45:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05089 for ; Tue, 30 Mar 2004 18:45:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj3-0006WI-9T for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGca7t023880 for ipv6-archive@odin.ietf.org; Tue, 11 Nov 2003 11:38:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbXG-00067w-Br for ipv6-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 11:38:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08871 for ; Tue, 11 Nov 2003 11:38:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbX6-0005dS-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:38:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJbX5-0005dP-00 for ipv6-web-archive@ietf.org; Tue, 11 Nov 2003 11:38:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbWq-0005xj-4Y; Tue, 11 Nov 2003 11:38:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbWN-0005kD-JU for ipv6@optimus.ietf.org; Tue, 11 Nov 2003 11:37:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08822 for ; Tue, 11 Nov 2003 11:37:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbWM-0005cb-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:37:38 -0500 Received: from web80506.mail.yahoo.com ([66.218.79.76]) by ietf-mx with smtp (Exim 4.12) id 1AJbWL-0005bj-00 for ipv6@ietf.org; Tue, 11 Nov 2003 11:37:37 -0500 Message-ID: <20031111163706.40437.qmail@web80506.mail.yahoo.com> Received: from [130.129.133.218] by web80506.mail.yahoo.com via HTTP; Tue, 11 Nov 2003 08:37:05 PST Date: Tue, 11 Nov 2003 08:37:05 -0800 (PST) From: Fred Templin Subject: Re: Path MTU for Tunnels (was: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt) To: Christian Huitema , Jun-ichiro itojun Hagino , pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org, osprey67@yahoo.com In-Reply-To: <20031110173314.23014.qmail@web80510.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1404901583-1068568625=:38822" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-1404901583-1068568625=:38822 Content-Type: text/plain; charset=us-ascii Folks, I uncovered a few bugs and made some changes since yesterday. (I was using the wrong mechanism for L2 fragmentation! :^/ ) The new document version can be found at: www.geocities.com/osprey67/tunnelmtu-04.txt The changelog appears below: Fred osprey67@yahoo.com Appendix A. Changelog o Specified use of IPv4 fragmentation (instead of IPv6) as the L2 fragmentation mechanism. o Added CongestMTU for use during periods of congestion. o Added support for sending congestion indications not associated with probes. o Clarified DF bit settings. Fred Templin wrote: I would like to add some qualifying remarks to my previous message. Many of my earlier messages on this subject were preliminary, but this message and my current document are not. See: www.geocities.com/osprey67/tunnelmtu-03.txt This document offers the following important conclusion: "It is impossible for the network to anticipate the packet transmission strategy of the application." This result is perhaps not surprising and certainly not new, as it is accurately predicted by the End-to-End Principle. Some additional notes: - For the past several months, I have worked under the premise that a robust, secure, efficient, and generalized Path MTU discovery mechanism for IPv6-in-IPv4 tunnels was needed that operated autonomously and without direction from the application. I struggled for many months to come up with a solution that satisfied this design point and failed - as have many others over the past 15 years. - After finally accepting the above conclusion and recognizing the means by which the application could provide guidance to the network, the solution was immediately obvious and I was able to write the entire document on the 4.5 hr flight into Minneapolis. All those interested in path MTU discovery (and the more general subject of application<->network interactions) should read this document along with the normative references it cites (even reading just the Introduction should be sufficient if time is short). The document probably has a few bugs, and I would appreciate comments. But, the conclusions will not go away and are indeed inescapable. Thanks - Fred ftemplin@iprg.nokia.com P.S. The document can be trivially extended to support IPv6 Jumbograms - this will be added in the next version. Fred Templin wrote: As I said I would do in my 10/29/2003 note on the ipv6 list under the subject heading: "Re: RFC 2461bis issue: MTU handling", I am now prepared to submit a new version of my document on dynamic MTU determination. (Please note that there are some significant differences from the previous version.) A copy of the document can be viewed at: www.geocities.com/osprey67/tunnelmtu-03.txt I am copying this to both lists, but suggest we continue the discussion on 'v6ops'. Finally, I would like to welcome comments and offer this document as topic for discussion during the MECH timeslot in Tuesday's v6ops session. Fred Templin osprey67@yahoo.com --0-1404901583-1068568625=:38822 Content-Type: text/html; charset=us-ascii
Folks,
 
I uncovered a few bugs and made some changes since yesterday.
(I was using the wrong mechanism for L2 fragmentation! :^/ ) The
new document version can be found at:
 
 
The changelog appears below:
 
Fred
 
Appendix A. Changelog

   o  Specified use of IPv4 fragmentation (instead of IPv6) as the L2
      fragmentation mechanism.

   o  Added CongestMTU for use during periods of congestion.

   o  Added support for sending congestion indications not associated
      with probes.

   o  Clarified DF bit settings.



Fred Templin <osprey67@yahoo.com> wrote:
I would like to add some qualifying remarks to my previous message.
Many of my earlier messages on this subject were preliminary, but this
message and my current document are not. See:
 
 
This document offers the following important conclusion:
 
  "It is impossible for the network to anticipate the
   packet transmission strategy of the application."
 
This result is perhaps not surprising and certainly not new, as
it is accurately predicted by the End-to-End Principle.
 
Some additional notes:
 
- For the past several months, I have worked under the premise that a
  robust, secure, efficient, and generalized Path MTU discovery mechanism
  for IPv6-in-IPv4 tunnels was needed that operated autonomously and without
  direction from the application. I struggled for many months to come up
  with a solution that satisfied this design point and failed -  as have many
  others over the past 15 years.
 
- After finally accepting the above conclusion and recognizing the means
  by which the application could provide guidance to the network, the solution
  was immediately obvious and I was able to write the entire document on
  the 4.5 hr flight into Minneapolis.
 
All those interested in path MTU discovery (and the more general
subject of application<->network interactions) should read this
document along with the normative references it cites (even reading
just the Introduction should be sufficient if time is short). The document
probably has a few bugs, and I would appreciate comments. But,
the conclusions will not go away and are indeed inescapable.
 
Thanks - Fred
 
P.S. The document can be trivially extended to support IPv6
    Jumbograms - this will be added in the next version. 
 
  

Fred Templin <osprey67@yahoo.com> wrote:
As I said I would do in my 10/29/2003 note on the ipv6 list under
the subject heading: "Re: RFC 2461bis issue: MTU handling", I am
now prepared to submit a new version of my document on dynamic
MTU determination. (Please note that there are some significant
differences from the previous version.)
 
A copy of the document can be viewed at:
 
 
I am copying this to both lists, but suggest we continue
the discussion on 'v6ops'. Finally, I would like to welcome
comments and offer this document as topic for discussion
during the MECH timeslot in Tuesday's v6ops session.
 
Fred Templin
--0-1404901583-1068568625=:38822-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:45:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05107 for ; Tue, 30 Mar 2004 18:45:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj3-0006a4-Dv for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKDgk8Z008916 for ipv6-archive@odin.ietf.org; Thu, 20 Nov 2003 08:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMp54-0002Jj-Ik for ipv6-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 08:42:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03759 for ; Thu, 20 Nov 2003 08:42:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMp53-0002yt-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 08:42:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMp52-0002yq-00 for ipv6-web-archive@ietf.org; Thu, 20 Nov 2003 08:42:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMp4M-00021H-9X; Thu, 20 Nov 2003 08:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMp3q-00020u-V9 for ipv6@optimus.ietf.org; Thu, 20 Nov 2003 08:41:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03731 for ; Thu, 20 Nov 2003 08:41:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMp3p-0002xz-00 for ipv6@ietf.org; Thu, 20 Nov 2003 08:41:29 -0500 Received: from [200.55.156.32] (helo=starfruit.itojun.org) by ietf-mx with esmtp (Exim 4.12) id 1AMp3o-0002xj-00 for ipv6@ietf.org; Thu, 20 Nov 2003 08:41:29 -0500 Received: by starfruit.itojun.org (Postfix, from userid 1001) id 16EC1199D0; Thu, 20 Nov 2003 22:40:55 +0900 (JST) To: john.loughney@nokia.com Cc: ipv6@ietf.org Subject: Re: Node Req: Issue31: DHCPv6 text (ignore previous mails) In-Reply-To: Your message of "Thu, 20 Nov 2003 11:12:52 +0200" References: X-Mailer: Cue version 0.6 (031029-1517/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031120134055.16EC1199D0@starfruit.itojun.org> Date: Thu, 20 Nov 2003 22:40:55 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > Please ignore previous mails on this topic, here is the proposed text: the change has to be synchronized with 2462bis effort, am i right? itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:46:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05283 for ; Tue, 30 Mar 2004 18:46:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj2-0006ZK-I8 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBF7fsIX027435 for ipv6-archive@odin.ietf.org; Mon, 15 Dec 2003 02:41:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVnME-00076g-Po for ipv6-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 02:41:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27536 for ; Mon, 15 Dec 2003 02:41:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVnMA-00066q-00 for ipv6-web-archive@ietf.org; Mon, 15 Dec 2003 02:41:30 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AVnLy-00065F-00 for ipv6-web-archive@ietf.org; Mon, 15 Dec 2003 02:41:18 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AVn96-00069h-Dn for ipv6-web-archive@ietf.org; Mon, 15 Dec 2003 02:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVn8B-0005jJ-As; Mon, 15 Dec 2003 02:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVn7s-0005if-N3 for ipv6@optimus.ietf.org; Mon, 15 Dec 2003 02:26:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26793 for ; Mon, 15 Dec 2003 02:26:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVn7o-0005hM-00 for ipv6@ietf.org; Mon, 15 Dec 2003 02:26:40 -0500 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1AVn7n-0005hD-00 for ipv6@ietf.org; Mon, 15 Dec 2003 02:26:40 -0500 Received: by coconut.itojun.org (Postfix, from userid 1001) id 07E70A0; Mon, 15 Dec 2003 16:26:40 +0900 (JST) To: hinden@iprg.nokia.com, deering@cisco.com Cc: ipv6@ietf.org Subject: comments on draft-ietf-ipv6-addr-arch-v4-00.txt References: <3FDA9143.8080408@ieee.org> X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 From: itojun@iijlab.net Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031215072640.07E70A0@coconut.itojun.org> Date: Mon, 15 Dec 2003 16:26:40 +0900 (JST) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , as an IAB i was asked to comment on draft-ietf-ipv6-addr-arch-v4-00.txt, so here it is. happy holidays. itojun MAJOR ===== "scope" the use of word/concept "scope" needs more care. moreover the terminology is not consistent (such as "link-scope" and "local scope"). (maybe this is because there is a separate draft for scoped address architecture, but anyways, first-time readers will get confused). multicast scope is well documented in 2.7. the problem is in the way unicast scope is documented. here are use of unicast "scope" in the document (maybe i missed some of those): 2.1: link-scope 2.4: of any scope 2.5.1: over a broader scope local scope interface identifier universal scope interface identifier universal scope (multiple occurrences) local scope (multiple occurrences) 2.5.3: link-local scope solution: there has to be a section describing what the unicast "scope" is, in very early part of the document. it can be very simple as there are only two scopes - link-local and global. use terminology such as "link-local scope" or "global scope" consistently. another solution: refer to scoped address architecture document. however, it will create dependency to scoped address architecture document which is not very desirable. it seems that the document tries to use "universal scope" to refer the scope of global unicast address, however, it is a bit confusing. maybe it is better to use "global scope" - in fact, ff0e::/16 is called "global scope", not "universal scope". textual representation 2.2 (1) has to state how many digits are permitted as "x" (one component between colon). my personal preference is that "x" has to be 1 to 4 digits (5 digits or more is invalid). remove "::13.1.68.3" from example for (3), as we no longer have IPv4 compatible address (not to confuse readers). IPv4 mapped address if I remember correctly draft-itojun-v6ops-v4mapped-harmful-02.txt (IPv4 mapped address on-wire is harmful) got enough consensus. please document that IPv4 mapped address is not permitted on wire, in 2.5.5. i know this is not a document to discuss on-wire stuff, however, there's no better place to document it. IPv4 compatible address 2.5.5 states that "The IPv6 transition mechanisms [TRAN] include..." for IPv4 compatible address. however, [TRAN] (RFC2893) no longer includes automatic tunnel. solution: mark IPv4 compatible as historic, just like site-local. EUI64 the last paragraph in 2.5.1 is incorrect: it states that "Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format". however, after "and" (EUI64 portion) is not true. (it is not required to construct interface ID based on EUI64 format, moreover, EUI64 method is applicable only to interfaces of certain media types) MINOR ===== NSAP address 2.5 and 2.5.4 talks about "encoded NSAP address" which is not of interest for many of the readers. i'd suggest removing it. there could be other places where encoded NSAP address is mentioned. (is it used in practice? it'll be interesting to see the implementation report when the document advances to DS) security consideration it may be worthwhile to state that noone should use addresses as authenticator - AH (or ESP) has to be used instead. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:47:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05642 for ; Tue, 30 Mar 2004 18:47:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj1-0006WI-JY for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7TJqm015869 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 03:29:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZu7-00043Y-Su for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:29:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06471 for ; Thu, 23 Oct 2003 03:28:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZu5-0002ry-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:29:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZu5-0002rv-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 03:29:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZu2-0003rt-6C; Thu, 23 Oct 2003 03:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZtF-0003fJ-9T for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 03:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06433 for ; Thu, 23 Oct 2003 03:28:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZtC-0002rC-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:28:10 -0400 Received: from coconut.itojun.org ([219.101.47.130]) by ietf-mx with esmtp (Exim 4.12) id 1ACZtC-0002r9-00 for ipv6@ietf.org; Thu, 23 Oct 2003 03:28:10 -0400 Received: by coconut.itojun.org (Postfix, from userid 1001) id DF05191; Thu, 23 Oct 2003 16:28:10 +0900 (JST) To: iljitsch@muada.com Cc: ipv6@ietf.org Subject: Re: "RFC 2461bis" issue: MTU handling In-Reply-To: Your message of "Thu, 23 Oct 2003 09:23:56 +0200" References: X-Mailer: Cue version 0.6 (031002-0709/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031023072810.DF05191@coconut.itojun.org> Date: Thu, 23 Oct 2003 16:28:10 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , > > the assumption made in RFC2461 is that the link MTU is constant > > over the link, i guess. i don't think it is necessary to make > > MTU negotiable between peers, it would complicate too many things. > What would it complicate? > Obviously nobody is going to force anyone to implement such an option; > it would only be used between consenting hosts. you need to have a mechanism if the peer is capable of handling the option or not (since it is optional, if i read your comment correctly). then, neighbor cache management has to be changed to handle per-peer MTU value. itojun -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:49:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06258 for ; Tue, 30 Mar 2004 18:49:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riz-0006WI-Uz for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NAEGkb015703 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 06:14:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACcTw-00045C-LM for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 06:14:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11556 for ; Thu, 23 Oct 2003 06:14:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACcTs-0004pc-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 06:14:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACcTs-0004pY-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 06:14:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACcTj-0003x2-Ig; Thu, 23 Oct 2003 06:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACcT8-0003rW-Mb for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 06:13:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11527 for ; Thu, 23 Oct 2003 06:13:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACcT4-0004oK-00 for ipv6@ietf.org; Thu, 23 Oct 2003 06:13:22 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACcT3-0004o4-00 for ipv6@ietf.org; Thu, 23 Oct 2003 06:13:22 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9NAChP02371; Thu, 23 Oct 2003 13:12:43 +0300 Date: Thu, 23 Oct 2003 13:12:43 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Jun-ichiro itojun Hagino , Subject: Re: "RFC 2461bis" issue: MTU handling In-Reply-To: <9342DB02-0532-11D8-A9F8-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 23 Oct 2003, Iljitsch van Beijnum wrote: [...] > See http://sd.wareonearth.com/~phil/net/jumbo/ for some links > surrounding this issue. Yes, and...? Even if you don't want a separate physical infrastructure, defining a VLAN is trivial. Really, I can't see all that many scenarios where you'd deploy multiple nodes on a link with different MTU values and the internal traffic would be so high that optimizing the MTU used between these would be worth optimizing.. -- 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 exim@www1.ietf.org Tue Mar 30 18:50:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06306 for ; Tue, 30 Mar 2004 18:50:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riz-0006ZK-Vh for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIASuS7003834 for ipv6-archive@odin.ietf.org; Tue, 18 Nov 2003 05:28:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM36L-0000zl-Cc for ipv6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 05:28:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13209 for ; Tue, 18 Nov 2003 05:28:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM36H-00028b-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:28:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM36G-00028T-00 for ipv6-web-archive@ietf.org; Tue, 18 Nov 2003 05:28:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM34Z-00008Y-Gc; Tue, 18 Nov 2003 05:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALupx-0006RZ-Cw for ipv6@optimus.ietf.org; Mon, 17 Nov 2003 20:39:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17663; Mon, 17 Nov 2003 20:39:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALupu-0003Bn-00; Mon, 17 Nov 2003 20:39:22 -0500 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ALupu-0003Bk-00; Mon, 17 Nov 2003 20:39:22 -0500 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id hAI1dJIe059714; Mon, 17 Nov 2003 17:39:19 -0800 (PST) (envelope-from kohler@coyote.icir.org) Message-Id: <200311180139.hAI1dJIe059714@coyote.icir.org> To: Fred Templin cc: dccp@ietf.org, pmtud@ietf.org, ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: [pmtud] Re: [dccp] PMTU issues In-Reply-To: Message from Fred Templin of "Mon, 17 Nov 2003 12:12:10 PST." <3FB92B9A.8020409@iprg.nokia.com> Date: Mon, 17 Nov 2003 17:39:19 -0800 From: Eddie Kohler Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi Fred, * PLPMTUD is useful. * Designing PMTUD so that it works in the absence of ICMP feedback seems necessary. BUT * Suitable ICMP feedback hints might significantly improve the performance of a transport protocol. * We can program our transports to react to ICMP as a hint -- i.e., not trust it, but use it to optimize performance. * So ICMP should not be "needed", but it might, and probably would, be quite helpful in some cases. * For instance, not all packetization layers have as easy a time as TCP with packet size changes. The smooth ramp-up suggested in PLPMTUD may require intervention from the application for example. For good performance, these applications may apply PMTUD in unexpected ways -- they might start large, for example. ICMP feedback would really help them. * ICMP is not a significant cause of Internet congestion and need not ever become one (mark it less-than-best-effort). I still think your overloading of ECN capable as "PLPMTUD capable, don't send ICMP" is not necessary, a bad idea, and will not fly. Eddie -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:50:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06348 for ; Tue, 30 Mar 2004 18:50:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riz-0006ZK-Fs for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NCU3hi021011 for ipv6-archive@odin.ietf.org; Thu, 23 Oct 2003 08:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACebL-0005So-QF for ipv6-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 08:30:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15736 for ; Thu, 23 Oct 2003 08:29:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACebK-0006V6-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 08:30:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACebK-0006V3-00 for ipv6-web-archive@ietf.org; Thu, 23 Oct 2003 08:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACeb5-0005Fm-JI; Thu, 23 Oct 2003 08:29:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACeZc-0004mm-PJ for ipv6@optimus.ietf.org; Thu, 23 Oct 2003 08:28:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15601 for ; Thu, 23 Oct 2003 08:28:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACeZa-0006SY-00 for ipv6@ietf.org; Thu, 23 Oct 2003 08:28:14 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACeZY-0006Rk-00 for ipv6@ietf.org; Thu, 23 Oct 2003 08:28:13 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9NCRQ904231; Thu, 23 Oct 2003 15:27:26 +0300 Date: Thu, 23 Oct 2003 15:27:25 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: "" Subject: Re: "RFC 2461bis" issue: MTU handling In-Reply-To: <80FD8028-0547-11D8-A9F8-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Thu, 23 Oct 2003, Iljitsch van Beijnum wrote: > On 23 okt 2003, at 12:12, Pekka Savola wrote: > > Even if you don't want a separate physical infrastructure, defining a > > VLAN is trivial. > > Yes, and setting up a new TCP session is even more trivial. But somehow > people see the value of writing a 150 page specification to do > mobility. Yes, and...? You don't set up VLAN's for every session the hosts create. You do it once and you're done. -- 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 exim@www1.ietf.org Tue Mar 30 18:51:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06672 for ; Tue, 30 Mar 2004 18:51:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riy-0006Yx-VO for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3LKRb6029248 for ipv6-archive@odin.ietf.org; Mon, 3 Nov 2003 16:20:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGm7d-0007bf-Ll for ipv6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 16:20:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21976 for ; Mon, 3 Nov 2003 16:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGm7b-0004ox-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 16:20:24 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGm7b-0004ou-00 for ipv6-web-archive@ietf.org; Mon, 03 Nov 2003 16:20:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGm7J-0007Vd-6N; Mon, 03 Nov 2003 16:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGm6v-0007Uy-RS for ipv6@optimus.ietf.org; Mon, 03 Nov 2003 16:19:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21949 for ; Mon, 3 Nov 2003 16:19:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGm6t-0004oH-00 for ipv6@ietf.org; Mon, 03 Nov 2003 16:19:39 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGm6s-0004o7-00 for ipv6@ietf.org; Mon, 03 Nov 2003 16:19:38 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA3LJ2m08787; Mon, 3 Nov 2003 23:19:02 +0200 Date: Mon, 3 Nov 2003 23:19:01 +0200 (EET) From: Pekka Savola To: Hans Kruse cc: ipv6@ietf.org Subject: Re: Thoughts on the draft-hinden last call In-Reply-To: <2147483647.1067865598@dhcp-074-191.cns.ohiou.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , On Mon, 3 Nov 2003, Hans Kruse wrote: > Please explain to me how the job of applications gets any easier if the > local addressing is done with a hijacked prefix.... Why exactly should we care if party X's internal applications break because it hijacks a prefix? -- 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 exim@www1.ietf.org Tue Mar 30 18:51:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06701 for ; Tue, 30 Mar 2004 18:51:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riy-0006Yx-RU for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA49bQnb017812 for ipv6-archive@odin.ietf.org; Tue, 4 Nov 2003 04:37:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxcr-0004dB-8v for ipv6-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 04:37:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05699 for ; Tue, 4 Nov 2003 04:37:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxco-0001mh-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 04:37:22 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGxcn-0001me-00 for ipv6-web-archive@ietf.org; Tue, 04 Nov 2003 04:37:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxcZ-0004Vp-M2; Tue, 04 Nov 2003 04:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxbR-0004S0-4b for ipv6@optimus.ietf.org; Tue, 04 Nov 2003 04:35:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05639 for ; Tue, 4 Nov 2003 04:35:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxbO-0001ke-00 for ipv6@ietf.org; Tue, 04 Nov 2003 04:35:54 -0500 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AGxbN-0001kC-00 for ipv6@ietf.org; Tue, 04 Nov 2003 04:35:53 -0500 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Nov 2003 04:34:50 -0500 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922E77@ftmail.lab.flarion.com> From: Soliman Hesham To: ipv6@ietf.org Subject: Issue 13: Omission of prefix options - resolution Date: Tue, 4 Nov 2003 04:34:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , Hi, This is an attempt to resolve this issue: Issue 13: Impacts of the omission of a prefix option. section 2.2 in : http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt describes the impacts of omitting a prefix option from an RA on movement detection for mobile nodes. RFC 2461 does not require options to be present in every RA. In case you haven't had time to look through the draft here is the background info: This issue raises the problem with omitting some prefixes from an RA. The problem here is that 2461 says that a router may choose to omit some prefixes from the RA to save BW (i.e. while the lifetime of that prefix has not expired). A mobile node might take this as an indication of movement (i.e. it is no longer reachable on the CoA that was derived from the omitted prefix). This may unnecessarily cause the mobile node to send a binding update to the HA/CNs to indicate that its CoA has changed. The other problem is that a host has no idea whether an RA contains all the prefix options that are valid on a link. Therefore, even if it sends an RS it might still get an RA with an incomplete list of prefixes. Suggested resolution: - Introduce a new code (1) in the router solicitation and advertisement. When a host sends an RS with code = 1 it requests that the RA include all prefixses valid on that link. Similarly, when a router sends an RA with code=1 it means that the RA includes all prefixes valid on that link. This way, a MN can confirm its mobility. Comments? Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:52:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06837 for ; Tue, 30 Mar 2004 18:52:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riy-0006WI-KA for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KN8Rm3003537 for ipv6-archive@odin.ietf.org; Fri, 20 Feb 2004 18:08:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuJkx-0000uy-46 for ipv6-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 18:08:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19807 for ; Fri, 20 Feb 2004 18:08:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuJku-0003Gm-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 18:08:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuJju-0003Br-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 18:07:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuJjU-00037t-00 for ipv6-web-archive@ietf.org; Fri, 20 Feb 2004 18:06:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuJid-00084b-JF; Fri, 20 Feb 2004 18:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuJiW-00082R-BW for ipv6@optimus.ietf.org; Fri, 20 Feb 2004 18:05:56 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19528 for ; Fri, 20 Feb 2004 18:05:51 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1AuJi1-0007rP-Sw; Fri, 20 Feb 2004 18:05:25 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'IP Forwarding Table MIB' to Proposed Standard Message-Id: Date: Fri, 20 Feb 2004 18:05:25 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has approved the following document: - 'IP Forwarding Table MIB ' as a Proposed Standard This document is the product of the IP Version 6 Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner. It accomplishes this by utilizing the InetAddress TC to provide IP address-independence on the management objects. This allows a single MIB to provide the same level of management for IPv4 and IPv6. Working Group Summary There was strong WG consensus for this document in both the IPv6 working group and the IPv6 MIB design team. Protocol Quality This document has undergone significant review by management experts. In particular, Mike Heard performed a thorough MIB Doctor review on this MIB. It has been reviewed for the IESG by Thomas Narten. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:52:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07034 for ; Tue, 30 Mar 2004 18:52:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rix-0006ZK-Ou for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADEuRLf028759 for ipv6-archive@odin.ietf.org; Thu, 13 Nov 2003 09:56:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKItX-0007Tm-CP for ipv6-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 09:56:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29527 for ; Thu, 13 Nov 2003 09:56:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKItV-0006AM-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 09:56:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKItV-0006AJ-00 for ipv6-web-archive@ietf.org; Thu, 13 Nov 2003 09:56:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIsC-00078B-1G; Thu, 13 Nov 2003 09:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIrR-00076a-9s for ipv6@optimus.ietf.org; Thu, 13 Nov 2003 09:54:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29438 for ; Thu, 13 Nov 2003 09:54:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIrP-00068X-00 for ipv6@ietf.org; Thu, 13 Nov 2003 09:54:15 -0500 Received: from web80509.mail.yahoo.com ([66.218.79.79]) by ietf-mx with smtp (Exim 4.12) id 1AKIrO-00067X-00 for ipv6@ietf.org; Thu, 13 Nov 2003 09:54:14 -0500 Message-ID: <20031113145338.52776.qmail@web80509.mail.yahoo.com> Received: from [63.197.18.101] by web80509.mail.yahoo.com via HTTP; Thu, 13 Nov 2003 06:53:38 PST Date: Thu, 13 Nov 2003 06:53:38 -0800 (PST) From: Fred Templin Subject: ISATAP in unmanaged networks? To: ipv6@ietf.org, v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-859950525-1068735218=:48226" Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --0-859950525-1068735218=:48226 Content-Type: text/plain; charset=us-ascii Hello, It just now occurs to me that Christian's unmanaged networks presentiation during v6ops yesterday did not mention ISATAP as one of the automatic tunneling alternatives, and I wonder why this is so. I have not studied this space, but it occurs to me that ISATAP could be tried as a first alternative to check whether the two hosts are separated by a NAT. If there is no intervening NAT, it seems to me that ISATAP would provide the benefit of not needing the UDP header and "bubble" packets, yielding greater efficiency. Otherwise, if blocked by a NAT the initiating host coud after a short timeout try again with Teredo. I know that ISATAP has been seen as in the Enterprise space, but I see potential applicability here for the unmanaged. Comments? Fred Templin osprey67@yahoo.com --0-859950525-1068735218=:48226 Content-Type: text/html; charset=us-ascii
Hello,
 
It just now occurs to me that Christian's unmanaged networks
presentiation during v6ops yesterday did not mention ISATAP
as one of the automatic tunneling alternatives, and I wonder
why this is so.
 
I have not studied this space, but it occurs to me that ISATAP
could be tried as a first alternative to check whether the two
hosts are separated by a NAT. If there is no intervening NAT,
it seems to me that ISATAP would provide the benefit of not
needing the UDP header and "bubble" packets, yielding
greater efficiency. Otherwise, if blocked by a NAT the
initiating host coud after a short timeout try again with
Teredo.
 
I know that ISATAP has been seen as in the Enterprise
space, but I see potential applicability here for the
unmanaged. Comments?
 
Fred Templin
--0-859950525-1068735218=:48226-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:53:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07211 for ; Tue, 30 Mar 2004 18:53:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rix-0006ZK-L3 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GGgPS5017240 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 11:42:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslpB-0004Tz-BA for ipv6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 11:42:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03982 for ; Mon, 16 Feb 2004 11:42:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslpA-000705-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 11:42:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsloE-0006us-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 11:41:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AslnJ-0006nU-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 11:40:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aslmv-00044t-BG; Mon, 16 Feb 2004 11:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asl5g-0000An-W1 for ipv6@optimus.ietf.org; Mon, 16 Feb 2004 10:55:25 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26992 for ; Mon, 16 Feb 2004 10:55:21 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1Asl5C-00008l-Kz; Mon, 16 Feb 2004 10:54:54 -0500 X-test-idtracker: no To: IETF-Announce :; From: The IESG Subject: Last Call: 'Deprecating Site Local Addresses' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Mon, 16 Feb 2004 10:54:54 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,TO_HAS_SPACES autolearn=no version=2.60 The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'Deprecating Site Local Addresses ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-03-01. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-02.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:55:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07662 for ; Tue, 30 Mar 2004 18:55:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006a4-Hf for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IKhsUb015208 for ipv6-archive@odin.ietf.org; Thu, 18 Mar 2004 15:43:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44Ms-0003xD-DI for ipv6-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 15:43:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07714 for ; Thu, 18 Mar 2004 15:43:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B44Mq-0002Oy-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 15:43:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B44Ln-0002Gs-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 15:42:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B44Kl-0002B3-00 for ipv6-web-archive@ietf.org; Thu, 18 Mar 2004 15:41:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44J8-0002yw-Mq; Thu, 18 Mar 2004 15:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44Il-0002tE-46 for ipv6@optimus.ietf.org; Thu, 18 Mar 2004 15:39:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07332; Thu, 18 Mar 2004 15:39:31 -0500 (EST) Message-Id: <200403182039.PAA07332@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-prefix-delegation-requirement-04.txt Date: Thu, 18 Mar 2004 15:39:30 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Requirements for IPv6 prefix delegation Author(s) : S. Miyakawa, R. Droms Filename : draft-ietf-ipv6-prefix-delegation-requirement-04.txt Pages : 7 Date : 2004-3-18 This document describes requirements about how an IPv6 address prefix should be delegated to an IPv6 subscriber's network (or 'site'). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-prefix-delegation-requirement-04.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-prefix-delegation-requirement-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-18153508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-prefix-delegation-requirement-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-18153508.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:55:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07776 for ; Tue, 30 Mar 2004 18:55:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006a4-Cr for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF3DiN029557 for ipv6-archive@odin.ietf.org; Wed, 18 Feb 2004 10:03:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTED-0007dV-Pd for ipv6-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 10:03:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16457 for ; Wed, 18 Feb 2004 10:03:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTE6-0005q3-00 for ipv6-web-archive@ietf.org; Wed, 18 Feb 2004 10:03:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTCP-0005V0-00 for ipv6-web-archive@ietf.org; Wed, 18 Feb 2004 10:01:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtTAp-0005Ar-00 for ipv6-web-archive@ietf.org; Wed, 18 Feb 2004 09:59:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTAD-0005R2-SX; Wed, 18 Feb 2004 09:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTA5-0005Q9-K5 for ipv6@optimus.ietf.org; Wed, 18 Feb 2004 09:58:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15586; Wed, 18 Feb 2004 09:58:50 -0500 (EST) Message-Id: <200402181458.JAA15586@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-node-requirements-08.txt Date: Wed, 18 Feb 2004 09:58:49 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : IPv6 Node Requirements Author(s) : J. Loughney Filename : draft-ietf-ipv6-node-requirements-08.txt Pages : 20 Date : 2004-2-18 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-node-requirements-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-node-requirements-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-18101200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-node-requirements-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-node-requirements-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101200.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:55:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07786 for ; Tue, 30 Mar 2004 18:55:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006Yx-CA for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GFajMt024191 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 10:36:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asknc-00068K-Qh for ipv6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 10:36:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25733 for ; Mon, 16 Feb 2004 10:36:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsknF-0004sb-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 10:36:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AskmI-0004l2-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 10:35:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsklL-0004dt-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 10:34:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askk2-0004h1-Mc; Mon, 16 Feb 2004 10:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AskjG-0004ao-AX for ipv6@optimus.ietf.org; Mon, 16 Feb 2004 10:32:14 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24979; Mon, 16 Feb 2004 10:32:10 -0500 (EST) Message-Id: <200402161532.KAA24979@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-unique-local-addr-03.txt Date: Mon, 16 Feb 2004 10:32:09 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-unique-local-addr-03.txt Pages : 16 Date : 2004-2-13 This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-unique-local-addr-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-unique-local-addr-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: <2004-2-16104515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-unique-local-addr-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-unique-local-addr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16104515.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:55:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07867 for ; Tue, 30 Mar 2004 18:55:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riw-0006a4-7u for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GFahAQ023928 for ipv6-archive@odin.ietf.org; Mon, 16 Feb 2004 10:36:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsknH-00067b-BY for ipv6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 10:36:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25729 for ; Mon, 16 Feb 2004 10:36:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsknE-0004sN-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 10:36:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AskmH-0004kr-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 10:35:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsklL-0004ds-00 for ipv6-web-archive@ietf.org; Mon, 16 Feb 2004 10:34:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askk1-0004gp-94; Mon, 16 Feb 2004 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askj9-0004Zz-Fe for ipv6@optimus.ietf.org; Mon, 16 Feb 2004 10:32:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24964; Mon, 16 Feb 2004 10:32:03 -0500 (EST) Message-Id: <200402161532.KAA24964@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-scoping-arch-01.txt Date: Mon, 16 Feb 2004 10:32:02 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : IPv6 Scoped Address Architecture Author(s) : S. Deering Filename : draft-ietf-ipv6-scoping-arch-01.txt Pages : 23 Date : 2004-2-13 This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids using the syntax and usage of unicast site-local addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-scoping-arch-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-scoping-arch-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-scoping-arch-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-16104507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-scoping-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-scoping-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16104507.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:56:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25529 for ; Tue, 30 Mar 2004 18:09:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjW-0006Xa-JB for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i247nndS017033 for ipv6-archive@odin.ietf.org; Thu, 4 Mar 2004 02:49:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aync5-0004PJ-3r for ipv6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 02:49:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24529 for ; Thu, 4 Mar 2004 02:49:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynbm-0005zT-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:49:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynam-0005mR-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:48:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AynZy-0005ax-00 for ipv6-web-archive@ietf.org; Thu, 04 Mar 2004 02:47:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynZX-0003mV-Ti; Thu, 04 Mar 2004 02:47:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynYx-0003eV-4j for ipv6@optimus.ietf.org; Thu, 04 Mar 2004 02:46:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24234 for ; Thu, 4 Mar 2004 02:46:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynYt-0005NM-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:46:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynXx-00057U-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:45:34 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AynWu-0004eE-00 for ipv6@ietf.org; Thu, 04 Mar 2004 02:44:29 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i247hwiQ007818; Wed, 3 Mar 2004 23:43:58 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQW54563; Wed, 3 Mar 2004 23:43:57 -0800 (PST) Date: Wed, 3 Mar 2004 23:43:57 -0800 (PST) From: Suresh Satapati To: Dave Thaler cc: Changming Liu , ipv6@ietf.org Subject: RE: v6 host load balancing In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dave, Lemme give this a try.. > > No matter it is active or passive open, the modem stateful will need > to > > open > > the "hole" by listening to the control channel for "port" and "pasv" > > comamnd. > > You lost me here. Since the passive open has the connection initiated > by the client, there is no need for the firewall around the client to > open a port based on listening to the control channel, right? > if there is a fw X on the path to the server, fw X may have to look at the PASV response and open a hole for the subsequent data traffic from the client. something like a dynamic (created on-the-fly) outbound access list. > > The hole is opened only on the firewall which is dealing the > > control channel. If the data channel goes to another file, apparently > this > > will not work. > > I don't see why not. It's just another outgoing TCP connection. > coz data from the client may be going thru a different device Y, which is being blocked by the fw on that device. fw Y doesn't have the hole to let the traffic go through. Hope this helps. -- Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 18:59:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26622 for ; Tue, 30 Mar 2004 18:13:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjT-0006Zv-NA for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C6cwml006647 for ipv6-archive@odin.ietf.org; Thu, 12 Feb 2004 01:38:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAV0-0001j8-1c for ipv6-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 01:38:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27256 for ; Thu, 12 Feb 2004 01:38:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArAUx-0003N2-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 01:38:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArAU0-0003Hj-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 01:37:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArATV-0003D6-00 for ipv6-web-archive@ietf.org; Thu, 12 Feb 2004 01:37:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAT8-00011o-Sl; Thu, 12 Feb 2004 01:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAT6-00011E-Vg for ipv6@optimus.ietf.org; Thu, 12 Feb 2004 01:37:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27218 for ; Thu, 12 Feb 2004 01:36:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArAT3-0003Cg-00 for ipv6@ietf.org; Thu, 12 Feb 2004 01:36:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArAS9-00037w-00 for ipv6@ietf.org; Thu, 12 Feb 2004 01:36:02 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1ArARd-00032i-00 for ipv6@ietf.org; Thu, 12 Feb 2004 01:35:29 -0500 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D0A5215210; Thu, 12 Feb 2004 15:35:28 +0900 (JST) Date: Thu, 12 Feb 2004 15:35:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Felipe Alfaro Solana Cc: ipv6@ietf.org Subject: Re: new revision of rfc2462bis is available In-Reply-To: <1076442972.2358.11.camel@teapot.felipe-alfaro.com> References: <1076442972.2358.11.camel@teapot.felipe-alfaro.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 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 >>>>> On Tue, 10 Feb 2004 20:56:12 +0100, >>>>> Felipe Alfaro Solana said: > I don't understand how is it possible for two hosts to communicate when > no stateful server or router advertising a prefix is attached to the > link. In this case, both hosts are configured exclusively with > link-local addresses, but since those addresses have a fe80::/10 prefix, > how can the IPv6 stack know what interface should the packets be sent > on? Just because link-local addresses has a well-known prefix fe80::/10 cannot be the source of the problem. The problem is that link-local addresses are only unique within a single link and are ambiguous for a multi-linked host. If the host in question has only one physical interface to which it is connected to the link and the interface is specified as "the default" (see draft-ietf-ipv6-scoping-arch-00.txt for more details on this), link-local addresses work just like global addresses. Even if the default interface is not specified, link-local addresses will still work when the user specified the correct link (interface) (again, see the scoping-arch draft for details). > For instance, on Linux 2.6 kernels, when trying to ping another host > using its link-local IPv6, an invalid argument error is generated since > the kernel is not able to guess which interface the packet should be > sent to, since any local interface has exactly the same prefix and > length. This gets complicated even more if the machine has multiple > interfaces, for example, two Ethernet interfaces. This is just an implementation. For example, *BSDs have the notion of the "default interface" (and the default link automatically derived from the interface) to implement the scope-arch draft, with which the above scenario works perfectly. So, > I thought that two IPv6-enabled hosts could only communicate if both > have a site-local or global IPv6 address configured. this is not really correct. Also, site-local addresses even have the same problem of ambiguity. And besides, the IETF is now going to kill site-local addresses. Let's just concentrate on link-local and global. 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 exim@www1.ietf.org Tue Mar 30 19:00:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08925 for ; Tue, 30 Mar 2004 19:00:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ris-0006a4-Ar for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJKUE98023213 for ipv6-archive@odin.ietf.org; Wed, 19 Nov 2003 15:30:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYxq-00062K-I1 for ipv6-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 15:30:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10033 for ; Wed, 19 Nov 2003 15:30:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMYxp-0001Y8-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 15:30:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMYxo-0001Xb-00 for ipv6-web-archive@ietf.org; Wed, 19 Nov 2003 15:30:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYwf-0005kB-W9; Wed, 19 Nov 2003 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMYvu-0005TD-Qd for ipv6@optimus.ietf.org; Wed, 19 Nov 2003 15:28:14 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09808; Wed, 19 Nov 2003 15:28:01 -0500 (EST) Message-Id: <200311192028.PAA09808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-deprecate-site-local-02.txt Date: Wed, 19 Nov 2003 15:28:01 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --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 : Deprecating Site Local Addresses Author(s) : C. Huitema, B. Carpenter Filename : draft-ietf-ipv6-deprecate-site-local-02.txt Pages : 11 Date : 2003-11-19 This document describes the issues surrounding the use of IPv6 site- local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-site-local-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-deprecate-site-local-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-deprecate-site-local-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-19144729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-deprecate-site-local-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-deprecate-site-local-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-19144729.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 19:00:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08965 for ; Tue, 30 Mar 2004 19:00:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ris-0006ZK-7P for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1KWRgP029294 for ipv6-archive@odin.ietf.org; Mon, 1 Dec 2003 15:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuiY-0007ap-PX for ipv6-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 15:32:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27691 for ; Mon, 1 Dec 2003 15:32:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuiL-0007nn-00 for ipv6-web-archive@ietf.org; Mon, 01 Dec 2003 15:32:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQuiJ-0007nY-00 for ipv6-web-archive@ietf.org; Mon, 01 Dec 2003 15:32:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuhC-00072p-FF; Mon, 01 Dec 2003 15:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQugC-0006yK-Nm for ipv6@optimus.ietf.org; Mon, 01 Dec 2003 15:30:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27223; Mon, 1 Dec 2003 15:29:46 -0500 (EST) Message-Id: <200312012029.PAA27223@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2012-update-05.txt Date: Mon, 01 Dec 2003 15:29:46 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --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 : Management Information Base for the Transmission Control Protocol (TCP) Author(s) : R. Raghunarayan Filename : draft-ietf-ipv6-rfc2012-update-05.txt Pages : 27 Date : 2003-12-1 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2012 and 2452. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2012-update-05.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-rfc2012-update-05.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: <2003-12-1152224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2012-update-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2012-update-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152224.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 19:00:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09001 for ; Tue, 30 Mar 2004 19:00:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ris-0006a4-6X for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1KWR8G029300 for ipv6-archive@odin.ietf.org; Mon, 1 Dec 2003 15:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuiZ-0007bb-7P for ipv6-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 15:32:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27694 for ; Mon, 1 Dec 2003 15:32:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuiT-00000A-00 for ipv6-web-archive@ietf.org; Mon, 01 Dec 2003 15:32:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQuiI-0007nW-00 for ipv6-web-archive@ietf.org; Mon, 01 Dec 2003 15:32:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuhE-000731-QI; Mon, 01 Dec 2003 15:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQugJ-00070E-8P for ipv6@optimus.ietf.org; Mon, 01 Dec 2003 15:30:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27249; Mon, 1 Dec 2003 15:29:52 -0500 (EST) Message-Id: <200312012029.PAA27249@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipv6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2012-update-05.txt Date: Mon, 01 Dec 2003 15:29:52 -0500 Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , --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 : Management Information Base for the Transmission Control Protocol (TCP) Author(s) : R. Raghunarayan Filename : draft-ietf-ipv6-rfc2012-update-05.txt Pages : 27 Date : 2003-12-1 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2012 and 2452. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2012-update-05.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-rfc2012-update-05.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: <2003-12-1152224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2012-update-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2012-update-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152224.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 19:04:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27551 for ; Tue, 30 Mar 2004 18:16:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006Xa-Q5 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i17GnucW032404 for ipv6-archive@odin.ietf.org; Sat, 7 Feb 2004 11:49:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVeW-0008QZ-Fq for ipv6-web-archive@optimus.ietf.org; Sat, 07 Feb 2004 11:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08497 for ; Sat, 7 Feb 2004 11:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApVeV-000342-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 11:49:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApVdZ-0002yA-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 11:48:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApVd8-0002rW-00 for ipv6-web-archive@ietf.org; Sat, 07 Feb 2004 11:48:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVcf-00085F-Nm; Sat, 07 Feb 2004 11:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApVcJ-00083J-4C for ipv6@optimus.ietf.org; Sat, 07 Feb 2004 11:47:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08426 for ; Sat, 7 Feb 2004 11:47:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApVcI-0002q4-00 for ipv6@ietf.org; Sat, 07 Feb 2004 11:47:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApVbM-0002mV-00 for ipv6@ietf.org; Sat, 07 Feb 2004 11:46:41 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ApVax-0002ic-00 for ipv6@ietf.org; Sat, 07 Feb 2004 11:46:15 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 5A4446A90B; Sat, 7 Feb 2004 18:46:13 +0200 (EET) Message-ID: <402515F2.1030702@kolumbus.fi> Date: Sat, 07 Feb 2004 18:44:34 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gregory Daley Cc: JINMEI Tatuya , Markku Savela , ipv6@ietf.org Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay References: <4dae174de5a6.4de5a64dae17@mail1.monash.edu.au> In-Reply-To: <4dae174de5a6.4de5a64dae17@mail1.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Gregory Daley wrote: > Hi Jari, > > ----- Original Message ----- > From: Jari Arkko > Date: Friday, February 6, 2004 10:42 pm > Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay > > >>Greg Daley wrote: >> >> >>>I do not think we should be modifying every node to suit >>>MLD snooping, but it is possible to perhaps suggest >>>a random delay for _both_ the MLD report _and_ the DAD >>>NS (but no explicit delay between them). The DAD NS must >>>come after the MLD report though. >> >>What is important here is to avoid the collisions. The collisions >>are avoided if there is some random delay before you start sending >>packets. Given that the protocols impose an ordering (MLD first and >>DAD after that), a delay in MLD will impose an equivalent delay >>in DAD. > > > That's sufficient. Ok, so now we agree what needs to be done protocol wise, the rest is just a documentation issue ;-) >>My conclusion is that the right thing is to update RFC 2710 >>and require a delay. This removes collisions from both MLD >>and DAD. > > > I think that the problem there may be that RFC-2710 is > being replaced by MLDv2. > > The IPv6 node reqs document had a MUST for MLDv1, and > SHOULD for MLDv2 (last I saw). This could lead to many > of the hosts exhibiting the colliding behaviour for MLDv1, > even if the changes go into MLDv2. > > Will we effectively need MLDv1(the second)? I see the problem. I do not have a strong opinion on which document should explain what the correct behaviour is, as long as the document boundaries do not force us to specify suboptimal behaviour. For instance, if RFC 2462bis can explain that the delay should actually be before the MLD packet, that would be also sufficient. [If you think it sounds strange that 2462bis would be saying what to do for MLD, lets not forget that MLD is invoked because 2462bis needs the multicast listening service.] --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 19:09:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29536 for ; Tue, 30 Mar 2004 18:23:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006a4-24 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N7aMhV025553 for ipv6-archive@odin.ietf.org; Tue, 23 Mar 2004 02:36:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gSD-0006db-HK for ipv6-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 02:36:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09426 for ; Tue, 23 Mar 2004 02:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5gS9-0004bg-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 02:36:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5gRC-0004VD-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 02:35:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5gQP-0004Oq-00 for ipv6-web-archive@ietf.org; Tue, 23 Mar 2004 02:34:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gPQ-0006Hf-HJ; Tue, 23 Mar 2004 02:33:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gOi-0006FI-SB for ipv6@optimus.ietf.org; Tue, 23 Mar 2004 02:32:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09193 for ; Tue, 23 Mar 2004 02:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5gOf-0004Ad-00 for ipv6@ietf.org; Tue, 23 Mar 2004 02:32:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5gNc-00041u-00 for ipv6@ietf.org; Tue, 23 Mar 2004 02:31:21 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B5gMz-0003mn-00 for ipv6@ietf.org; Tue, 23 Mar 2004 02:30:41 -0500 content-class: urn:content-classes:message Subject: RE: ND-proxy applicability and loop-prevention Date: Tue, 23 Mar 2004 02:30:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: ND-proxy applicability and loop-prevention Thread-Index: AcQQo6lqAVDiyS2QRVOC01ZOruxvBgAAv9dg From: "Soliman Hesham" To: "Pekka Savola" , "Erik Nordmark" Cc: Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka,=20 I think you're oversimplifying the following issue: > > It *might* be sufficient if the solution could detect=20 > loops and sound the alarm > > (and stop forwarding frames), but ndproxy can't even=20 > detect loops and shut > > itself off. Thus when loops are formed the result is that=20 > the consumer will > > see their network die (100% link utilization due to frames=20 > looping around > > forever; ndproxy doesn't decrement the hop count). >=20 > I don't personally think 100% link utilization is that bad a=20 > signal. =20 =3D> I think it's a bad signal, _if_ detected. I.e. An average user is not even going to know that they have 100% link utilisation. And _if_ they do, I actually think that neither the user, nor the help desk first line of support will have the faintest idea (having been a regular with help desk people that work for a couple of major operators in different countries). > It rather simply conveys that "oops-- I've done something=20 > wrong when I > added the box there." and after it's removed all starts to work again > -- intuitive. =20 =3D> So if I somehow get inspired or guess that I should=20 remove the proxy and things work, what does that tell me??? Maybe the device is faulty? Maybe I'll take it back to the=20 shop! There is nothing intuitive about that from an average user's perspective.=20 Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From exim@www1.ietf.org Tue Mar 30 19:22:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02373 for ; Tue, 30 Mar 2004 18:35:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjF-0006Yx-TQ for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i239jC1H022151 for ipv6-archive@odin.ietf.org; Wed, 3 Mar 2004 04:45:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySw0-0005kF-7w for ipv6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 04:45:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14898 for ; Wed, 3 Mar 2004 04:44:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AySvi-0002a3-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 04:44:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AySuz-0002NN-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 04:43:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyStc-0001yl-00 for ipv6-web-archive@ietf.org; Wed, 03 Mar 2004 04:42:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySsg-00059s-RZ; Wed, 03 Mar 2004 04:41:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySrl-00054m-8r for ipv6@optimus.ietf.org; Wed, 03 Mar 2004 04:40:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14426 for ; Wed, 3 Mar 2004 04:40:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AySrO-0001aT-00 for ipv6@ietf.org; Wed, 03 Mar 2004 04:40:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AySqT-0001SL-00 for ipv6@ietf.org; Wed, 03 Mar 2004 04:39:17 -0500 Received: from web80512.mail.yahoo.com ([66.218.79.82]) by ietf-mx with smtp (Exim 4.12) id 1AySph-0001BL-00 for ipv6@ietf.org; Wed, 03 Mar 2004 04:38:29 -0500 Message-ID: <20040303093759.21505.qmail@web80512.mail.yahoo.com> Received: from [192.100.104.18] by web80512.mail.yahoo.com via HTTP; Wed, 03 Mar 2004 01:37:59 PST Date: Wed, 3 Mar 2004 01:37:59 -0800 (PST) From: Fred Templin Subject: RE: ndproxy and SEND To: Dave Thaler , ipv6@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Dave's re-word works for me, and see also section 4.1 of 'draft-ietf-v6ops-unmaneval-01.txt' for ndproxy use cases. Thanks - Fred osprey67@yahoo.com --- Dave Thaler wrote: > I mostly agree with Erik's suggested text, but would reword it > a bit to say three things: > > 1) the concept of proxied NAs is not introduced by this draft, > it's in the base ND spec, and the mechanisms in this draft do > not introduce any additional security issues beyond the ones > inherent in the base ND spec (which at Draft Std) > 2) IPv4 ARP proxying is widely deployed and the security of this > spec is no worse than IPv4 ARP proxying. Hence it does not make > the situation worse, but instead provides the potential for adding > security in the future. > 3) this document assumes that securing proxyied NA's would be > done by an extension to SEND > > -Dave > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > Sent: Wednesday, March 03, 2004 9:06 AM > > To: Dave Thaler > > Cc: ipv6@ietf.org > > Subject: ndproxy and SEND > > > > draft-thaler-ipv6-ndproxy-02.txt says: > > > > > o Support secure IPv6 neighbor discovery. This is discussed in > > > the Security Considerations section. > > > > I don't understand what it means to support SEND, given that the > > combination of SEND and ndproxy currently doesn't work. > > > > > As a result, securing Neighbor Discovery or ARP must take into > > > account the ability to proxy messages. This document does not > > > introduce any new requirements in this regard. > > > > I would be much clearer if the document instead said > > This document assumes that SEND provide security for > > proxy neighbor advertisement. > > > > The fact that SEND doesn't currently provide security for proxy > neighbor > > advertisements is an indication that 1) there isn't much perceived > need > > for it and/or 2) it is hard to do since authorization is a challenge. > > > > Hence it is useful to be very clear about the assumption on what SEND > > provides. > > > > Erik > > > > > -------------------------------------------------------------------- > 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 exim@www1.ietf.org Tue Mar 30 23:16:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25325 for ; Tue, 30 Mar 2004 23:16:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8X95-000623-V5 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 23:16:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V4G7Zl023179 for ipv6-archive@odin.ietf.org; Tue, 30 Mar 2004 23:16:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8X93-00061d-Be for ipv6-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 23:16:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25256 for ; Tue, 30 Mar 2004 23:16:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8X91-0005mi-00 for ipv6-web-archive@ietf.org; Tue, 30 Mar 2004 23:16:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8X7C-0005a0-00 for ipv6-web-archive@ietf.org; Tue, 30 Mar 2004 23:14:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8X5E-0005Oy-00 for ipv6-web-archive@ietf.org; Tue, 30 Mar 2004 23:12:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8X4A-0005d9-7i; Tue, 30 Mar 2004 23:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8X3g-0005bp-Pd for ipv6@optimus.ietf.org; Tue, 30 Mar 2004 23:10:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24995 for ; Tue, 30 Mar 2004 23:10:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8X3b-0005Iy-00 for ipv6@ietf.org; Tue, 30 Mar 2004 23:10:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8X0t-00059I-00 for ipv6@ietf.org; Tue, 30 Mar 2004 23:07:41 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1B8Wyy-00051Q-00 for ipv6@ietf.org; Tue, 30 Mar 2004 23:05:40 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 30 Mar 2004 20:05:28 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 30 Mar 2004 20:02:46 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 Mar 2004 20:05:09 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 30 Mar 2004 20:05:09 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 30 Mar 2004 20:04:58 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 30 Mar 2004 20:05:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-ietf-ipv6-deprecate-site-local-03.txt Date: Tue, 30 Mar 2004 20:01:40 -0800 Message-ID: Thread-Topic: draft-ietf-ipv6-deprecate-site-local-03.txt thread-index: AcQWdWcSQjZNMHyPSz2f+w7iH+5auQAXsZKA From: "Christian Huitema" To: Cc: "Margaret Wasserman" X-OriginalArrivalTime: 31 Mar 2004 04:05:07.0787 (UTC) FILETIME=[5AA5B1B0:01C416D5] Content-Transfer-Encoding: quoted-printable Sender: ipv6-admin@ietf.org Errors-To: ipv6-admin@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Version 6 Working Group (ipv6) List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Following IESG comments, Brian and I have prepared a new version of the draft "Deprecating Site Local Addresses". To quote from the change section: =20 The changes from draft 02 to draft 03 take into account the IESG comments. =20 A reference to the scoped addresses architecture draft has been added to section 2.1, in order to explain the usage of the % sign to document site numbers in site local addresses. =20 Section 2.4 has been reworded following suggestions by Alex Zinin, essentially to change the tone from "this creates a problem" to "this would increase router implementation and management complexity". =20 A new paragraph has been added to the security considerations, reiterating the issues due to ambiguity which were brought up in the preceding sections. =20 The IANA considerations have been rewritten for greater precision. =20 A duplicate reference to RFC 3513 has been removed. The AD asked that we verify that these changes do not alter the (rough) consensus of the WG, as noted during the WG last call. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------