From routing-discussion-admin@ietf.org Wed Mar 12 15:47:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21535 for ; Wed, 12 Mar 2003 15:47:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKo6O12633; Wed, 12 Mar 2003 15:50:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKkFO12465 for ; Wed, 12 Mar 2003 15:46:15 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20998 for ; Wed, 12 Mar 2003 15:31:37 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tCv4-0005FZ-00 for routing-discussion@ietf.org; Wed, 12 Mar 2003 12:33:46 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <65102357302.20030312123333@psg.com> To: routing-discussion@ietf.org Subject: Agenda for SF MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Mar 2003 12:33:33 -0800 Content-Transfer-Encoding: 7bit Folks- Below is the agenda for the area meeting on Monday. 1. Administriva & announcements 5m ADs 2. WG updates 40m var RM: WG charters, mailing lists and docs 3. Atomized routing project. 20m kc RM: http://www.caida.org/projects/routing/atoms/ http://www.caida.org/projects/routing/atoms/documents/report1.xml 4. Liaison statement from ITU-T SG15 10m Kam RM: http://www.ietf.org/IESG/LIAISON/ls15-39-1.htm 5. Revision of RFC1264 15m Alex RM: RFC1264 6. Open mike 7. Bar BOF If I've dropped something incidentally--pls let me know. Regards Alex & Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 12 15:47:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21557 for ; Wed, 12 Mar 2003 15:47:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CL25613185 for routing-discussion-archive@odin.ietf.org; Wed, 12 Mar 2003 16:02:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKo6O12633; Wed, 12 Mar 2003 15:50:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKkFO12465 for ; Wed, 12 Mar 2003 15:46:15 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20998 for ; Wed, 12 Mar 2003 15:31:37 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tCv4-0005FZ-00 for routing-discussion@ietf.org; Wed, 12 Mar 2003 12:33:46 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <65102357302.20030312123333@psg.com> To: routing-discussion@ietf.org Subject: Agenda for SF MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Mar 2003 12:33:33 -0800 Content-Transfer-Encoding: 7bit Folks- Below is the agenda for the area meeting on Monday. 1. Administriva & announcements 5m ADs 2. WG updates 40m var RM: WG charters, mailing lists and docs 3. Atomized routing project. 20m kc RM: http://www.caida.org/projects/routing/atoms/ http://www.caida.org/projects/routing/atoms/documents/report1.xml 4. Liaison statement from ITU-T SG15 10m Kam RM: http://www.ietf.org/IESG/LIAISON/ls15-39-1.htm 5. Revision of RFC1264 15m Alex RM: RFC1264 6. Open mike 7. Bar BOF If I've dropped something incidentally--pls let me know. Regards Alex & Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 12 23:58:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08246 for ; Wed, 12 Mar 2003 23:58:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D57GO14552; Thu, 13 Mar 2003 00:07:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D529O13899 for ; Thu, 13 Mar 2003 00:02:09 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07908 for ; Wed, 12 Mar 2003 23:47:22 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tKeo-000NPl-00 for routing-discussion@ietf.org; Wed, 12 Mar 2003 20:49:30 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <39132079380.20030312204855@psg.com> To: routing-discussion@ietf.org Subject: For discussion: revising RFC1264 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Mar 2003 20:48:55 -0800 Content-Transfer-Encoding: 7bit Folks- We're going to discuss this topic at the RTG area meeting next week. Here's the background for the discussion. RFC1264 defines requirements for routing protocols going to standards track. It was published more than 10 years ago and there are several reasons why we would like to revisit those. The biggest issue with the document is that it does not spell out the requirements for protocol extensions, neither does it say that the requirements described in it are for base protocol specifications exclusively. Here's the draft list of changes/issues that I'd like to solicit your comments on: 1. Number of interoperable implementations. The doc currently says: PS : 1 or more DS : 2 or more, at least 2 independent STD: 3 or more, at least 2 independent Should we raise this req to 2 for PS for both base protocol and extensions? The reason being that this is the only real way to check that the specification gives enough information for independent implementations to interoperate. Plus, of course, it raises the quality bar. The downside would be that if for some reason we would like to encourage implementation of something by making this a proposed standard, we wouldn't be able to do this until we had at least two interoperable implementations. 2. MIBs. The document introduces a dependency between the MIB and the protocol specs: PS : MIB written in an I-D DS : MIB is at PS level STD: MIB goes together with the spec The first thing would be to make the MIB optional for extensions and use common sense to make sure the charter includes the MIB work if needed. For base protocol specs, the meta question is whether we really want to sync these two so much. We don't have such rules written down for other protocols, maybe we shouldn't for routing either, and just use common sense too. (Data point: 2026 does not require this.) The downside of this would potentially be decreased thrust behind the MIB work. Another meta question is whether the MIBs have to be read/write or read-only, i.e., whether we should mandate that MIBs be written for configuration as well as for monitoring or for monitoring only. Recent discussions suggest that we should mandate monitoring and make configuration optional. 3. Reports. The text currently requires two reports submitted to the IESG along with the specs, the reports generally summarize the protocol scalability characteristics, experience in deployment of it, etc. These usually become separate RFCs. The de facto practice we have now is to not require those for extensions. I think the text should ask for only an implementation report (to ensure 2 interop implementations) submitted to the ADs for features. Add the following: 4. Provide guidelines about what sort of details should be described in a specification. There have been discussions recently about what sort of details should be described for routing protocols. i.e., only bits on the wire (message format only) vs including node-local decisions, FSMs, timing, etc. I fundamentally believe that node-local decisions, as well as timing are important for routing protocol specifications (this, in fact, is how currently used protocols are described), and think that the document should spell this out as a requirement. 5. Spell out what routing-specific details are expected in the security section for new protocols, i.e., threat analysis and authentication; and for extensions: changes to the set of possible attacks and to the protocols security mechanisms. 6. For features--the specs should also talk about backwards compatibility, describing how the new feature interoperates with routers not implementing it, if protocol dynamics are changed, how they affect scalability, stability, and robustness of the protocol. 7. For features--note that if the IETF owns the base proto specification, the maturity level for an extension cannot exceed the base spec's one, per 2026 because it is a normative ref. Plus fix the outdated procedural facts--those come from the times when IAB approved RFCs. Opinions are welcome. -- Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 12 23:59:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08273 for ; Wed, 12 Mar 2003 23:59:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D5Dm515212 for routing-discussion-archive@odin.ietf.org; Thu, 13 Mar 2003 00:13:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D57GO14552; Thu, 13 Mar 2003 00:07:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D529O13899 for ; Thu, 13 Mar 2003 00:02:09 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07908 for ; Wed, 12 Mar 2003 23:47:22 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tKeo-000NPl-00 for routing-discussion@ietf.org; Wed, 12 Mar 2003 20:49:30 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <39132079380.20030312204855@psg.com> To: routing-discussion@ietf.org Subject: For discussion: revising RFC1264 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Mar 2003 20:48:55 -0800 Content-Transfer-Encoding: 7bit Folks- We're going to discuss this topic at the RTG area meeting next week. Here's the background for the discussion. RFC1264 defines requirements for routing protocols going to standards track. It was published more than 10 years ago and there are several reasons why we would like to revisit those. The biggest issue with the document is that it does not spell out the requirements for protocol extensions, neither does it say that the requirements described in it are for base protocol specifications exclusively. Here's the draft list of changes/issues that I'd like to solicit your comments on: 1. Number of interoperable implementations. The doc currently says: PS : 1 or more DS : 2 or more, at least 2 independent STD: 3 or more, at least 2 independent Should we raise this req to 2 for PS for both base protocol and extensions? The reason being that this is the only real way to check that the specification gives enough information for independent implementations to interoperate. Plus, of course, it raises the quality bar. The downside would be that if for some reason we would like to encourage implementation of something by making this a proposed standard, we wouldn't be able to do this until we had at least two interoperable implementations. 2. MIBs. The document introduces a dependency between the MIB and the protocol specs: PS : MIB written in an I-D DS : MIB is at PS level STD: MIB goes together with the spec The first thing would be to make the MIB optional for extensions and use common sense to make sure the charter includes the MIB work if needed. For base protocol specs, the meta question is whether we really want to sync these two so much. We don't have such rules written down for other protocols, maybe we shouldn't for routing either, and just use common sense too. (Data point: 2026 does not require this.) The downside of this would potentially be decreased thrust behind the MIB work. Another meta question is whether the MIBs have to be read/write or read-only, i.e., whether we should mandate that MIBs be written for configuration as well as for monitoring or for monitoring only. Recent discussions suggest that we should mandate monitoring and make configuration optional. 3. Reports. The text currently requires two reports submitted to the IESG along with the specs, the reports generally summarize the protocol scalability characteristics, experience in deployment of it, etc. These usually become separate RFCs. The de facto practice we have now is to not require those for extensions. I think the text should ask for only an implementation report (to ensure 2 interop implementations) submitted to the ADs for features. Add the following: 4. Provide guidelines about what sort of details should be described in a specification. There have been discussions recently about what sort of details should be described for routing protocols. i.e., only bits on the wire (message format only) vs including node-local decisions, FSMs, timing, etc. I fundamentally believe that node-local decisions, as well as timing are important for routing protocol specifications (this, in fact, is how currently used protocols are described), and think that the document should spell this out as a requirement. 5. Spell out what routing-specific details are expected in the security section for new protocols, i.e., threat analysis and authentication; and for extensions: changes to the set of possible attacks and to the protocols security mechanisms. 6. For features--the specs should also talk about backwards compatibility, describing how the new feature interoperates with routers not implementing it, if protocol dynamics are changed, how they affect scalability, stability, and robustness of the protocol. 7. For features--note that if the IETF owns the base proto specification, the maturity level for an extension cannot exceed the base spec's one, per 2026 because it is a normative ref. Plus fix the outdated procedural facts--those come from the times when IAB approved RFCs. Opinions are welcome. -- Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 13 01:15:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10002 for ; Thu, 13 Mar 2003 01:15:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D6J0O18966; Thu, 13 Mar 2003 01:19:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D6FMO18896 for ; Thu, 13 Mar 2003 01:15:22 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09776 for ; Thu, 13 Mar 2003 01:00:32 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id BAA87631; Thu, 13 Mar 2003 01:01:52 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303130601.BAA87631@workhorse.fictitious.org> To: Alex Zinin cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Wed, 12 Mar 2003 20:48:55 PST." <39132079380.20030312204855@psg.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 01:01:52 -0500 In message <39132079380.20030312204855@psg.com>, Alex Zinin writes: > Folks- > > We're going to discuss this topic at the RTG area meeting next week. > Here's the background for the discussion. > > RFC1264 defines requirements for routing protocols going to standards > track. It was published more than 10 years ago and there are several > reasons why we would like to revisit those. > > The biggest issue with the document is that it does not spell out the > requirements for protocol extensions, neither does it say that the > requirements described in it are for base protocol specifications > exclusively. > > Here's the draft list of changes/issues that I'd like to solicit your > comments on: > > 1. Number of interoperable implementations. > > The doc currently says: > PS : 1 or more > DS : 2 or more, at least 2 independent > STD: 3 or more, at least 2 independent > > Should we raise this req to 2 for PS for both base protocol and > extensions? > > The reason being that this is the only real way to check that the > specification gives enough information for independent > implementations to interoperate. Plus, of course, it raises the > quality bar. > > The downside would be that if for some reason we would like to > encourage implementation of something by making this a proposed > standard, we wouldn't be able to do this until we had at least > two interoperable implementations. I'm all for raising the quality bar but some work, such as the MPLS-diffserv is very good work but has one implementation (AFAIK there is only one complete implementation in this case). If we do have consensus that something is worthwhile, it's not desireable to keep this as an internet-draft and have it expiring all the time. Maybe downgrade it (to what?) if there are not two implementation reported within 2-3 years. Also requiring that protocols advance, be updated, or be downgraded (to what?) in 2-3 years would prevent what happenned to BGP (not being updated when it needed it for many years). > 2. MIBs. The document introduces a dependency between the MIB > and the protocol specs: > > PS : MIB written in an I-D > DS : MIB is at PS level > STD: MIB goes together with the spec > > The first thing would be to make the MIB optional for extensions > and use common sense to make sure the charter includes the MIB > work if needed. > > For base protocol specs, the meta question is whether we really > want to sync these two so much. We don't have such rules written > down for other protocols, maybe we shouldn't for routing either, > and just use common sense too. (Data point: 2026 does not require > this.) The downside of this would potentially be decreased thrust > behind the MIB work. > > Another meta question is whether the MIBs have to be read/write > or read-only, i.e., whether we should mandate that MIBs be written > for configuration as well as for monitoring or for monitoring > only. Recent discussions suggest that we should mandate monitoring > and make configuration optional. Read-only! No question on that one. There are some things that don't much sense to make read-write so making write optional would be best. A lot of useful stuff gets implemented and doesn't need a MIB to be successfully deployed, particularly protocol extensions. A good example of an extension that will not need a MIB to be successfully deployed is the current soft-preemption draft. It adds 3 bits to two existing bitfields and defines the semantics. You could argue that later on a counter of the number of soft-preemptions vs hard preemptions could/should be added but that shouldn't be needed to get to PS. For DS, yes, keep the MIB requirement. > 3. Reports. > > The text currently requires two reports submitted to the IESG > along with the specs, the reports generally summarize the protocol > scalability characteristics, experience in deployment of it, etc. > These usually become separate RFCs. > > The de facto practice we have now is to not require those for > extensions. I think the text should ask for only an implementation > report (to ensure 2 interop implementations) submitted to the ADs > for features. Why not implementation experience? I could be a 2 pager. (With all the boilerplate there is no such thing as a one pager anymore). > Add the following: > > 4. Provide guidelines about what sort of details should be described > in a specification. > > There have been discussions recently about what sort of details > should be described for routing protocols. i.e., only bits on the > wire (message format only) vs including node-local decisions, > FSMs, timing, etc. More than bits on the wire. OTOH the BGP FSM exercise we just went through IMHO was excessive. > I fundamentally believe that node-local decisions, as well as > timing are important for routing protocol specifications (this, in > fact, is how currently used protocols are described), and think > that the document should spell this out as a requirement. > > 5. Spell out what routing-specific details are expected in the > security section for new protocols, i.e., threat analysis and > authentication; and for extensions: changes to the set of possible > attacks and to the protocols security mechanisms. Yes. > 6. For features--the specs should also talk about backwards > compatibility, describing how the new feature interoperates with > routers not implementing it, if protocol dynamics are changed, how > they affect scalability, stability, and robustness of the protocol. Definitely. > 7. For features--note that if the IETF owns the base proto > specification, the maturity level for an extension cannot exceed > the base spec's one, per 2026 because it is a normative ref. > > Plus fix the outdated procedural facts--those come from the times > when IAB approved RFCs. > > Opinions are welcome. Above I've suggested that instead of making it harder to get a document to PS, make it harder to just get a document to PS and then do nothing for the next decade. A three year threshhold would affect a lot of existing PS documents and force some cleanup. I'm not sure what to call the downgrade. AS - abandoned standard? Thanks > Alex Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Mar 13 01:16:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10017 for ; Thu, 13 Mar 2003 01:16:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D6UZY19364 for routing-discussion-archive@odin.ietf.org; Thu, 13 Mar 2003 01:30:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D6J0O18966; Thu, 13 Mar 2003 01:19:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D6FMO18896 for ; Thu, 13 Mar 2003 01:15:22 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09776 for ; Thu, 13 Mar 2003 01:00:32 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id BAA87631; Thu, 13 Mar 2003 01:01:52 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303130601.BAA87631@workhorse.fictitious.org> To: Alex Zinin cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Wed, 12 Mar 2003 20:48:55 PST." <39132079380.20030312204855@psg.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 01:01:52 -0500 In message <39132079380.20030312204855@psg.com>, Alex Zinin writes: > Folks- > > We're going to discuss this topic at the RTG area meeting next week. > Here's the background for the discussion. > > RFC1264 defines requirements for routing protocols going to standards > track. It was published more than 10 years ago and there are several > reasons why we would like to revisit those. > > The biggest issue with the document is that it does not spell out the > requirements for protocol extensions, neither does it say that the > requirements described in it are for base protocol specifications > exclusively. > > Here's the draft list of changes/issues that I'd like to solicit your > comments on: > > 1. Number of interoperable implementations. > > The doc currently says: > PS : 1 or more > DS : 2 or more, at least 2 independent > STD: 3 or more, at least 2 independent > > Should we raise this req to 2 for PS for both base protocol and > extensions? > > The reason being that this is the only real way to check that the > specification gives enough information for independent > implementations to interoperate. Plus, of course, it raises the > quality bar. > > The downside would be that if for some reason we would like to > encourage implementation of something by making this a proposed > standard, we wouldn't be able to do this until we had at least > two interoperable implementations. I'm all for raising the quality bar but some work, such as the MPLS-diffserv is very good work but has one implementation (AFAIK there is only one complete implementation in this case). If we do have consensus that something is worthwhile, it's not desireable to keep this as an internet-draft and have it expiring all the time. Maybe downgrade it (to what?) if there are not two implementation reported within 2-3 years. Also requiring that protocols advance, be updated, or be downgraded (to what?) in 2-3 years would prevent what happenned to BGP (not being updated when it needed it for many years). > 2. MIBs. The document introduces a dependency between the MIB > and the protocol specs: > > PS : MIB written in an I-D > DS : MIB is at PS level > STD: MIB goes together with the spec > > The first thing would be to make the MIB optional for extensions > and use common sense to make sure the charter includes the MIB > work if needed. > > For base protocol specs, the meta question is whether we really > want to sync these two so much. We don't have such rules written > down for other protocols, maybe we shouldn't for routing either, > and just use common sense too. (Data point: 2026 does not require > this.) The downside of this would potentially be decreased thrust > behind the MIB work. > > Another meta question is whether the MIBs have to be read/write > or read-only, i.e., whether we should mandate that MIBs be written > for configuration as well as for monitoring or for monitoring > only. Recent discussions suggest that we should mandate monitoring > and make configuration optional. Read-only! No question on that one. There are some things that don't much sense to make read-write so making write optional would be best. A lot of useful stuff gets implemented and doesn't need a MIB to be successfully deployed, particularly protocol extensions. A good example of an extension that will not need a MIB to be successfully deployed is the current soft-preemption draft. It adds 3 bits to two existing bitfields and defines the semantics. You could argue that later on a counter of the number of soft-preemptions vs hard preemptions could/should be added but that shouldn't be needed to get to PS. For DS, yes, keep the MIB requirement. > 3. Reports. > > The text currently requires two reports submitted to the IESG > along with the specs, the reports generally summarize the protocol > scalability characteristics, experience in deployment of it, etc. > These usually become separate RFCs. > > The de facto practice we have now is to not require those for > extensions. I think the text should ask for only an implementation > report (to ensure 2 interop implementations) submitted to the ADs > for features. Why not implementation experience? I could be a 2 pager. (With all the boilerplate there is no such thing as a one pager anymore). > Add the following: > > 4. Provide guidelines about what sort of details should be described > in a specification. > > There have been discussions recently about what sort of details > should be described for routing protocols. i.e., only bits on the > wire (message format only) vs including node-local decisions, > FSMs, timing, etc. More than bits on the wire. OTOH the BGP FSM exercise we just went through IMHO was excessive. > I fundamentally believe that node-local decisions, as well as > timing are important for routing protocol specifications (this, in > fact, is how currently used protocols are described), and think > that the document should spell this out as a requirement. > > 5. Spell out what routing-specific details are expected in the > security section for new protocols, i.e., threat analysis and > authentication; and for extensions: changes to the set of possible > attacks and to the protocols security mechanisms. Yes. > 6. For features--the specs should also talk about backwards > compatibility, describing how the new feature interoperates with > routers not implementing it, if protocol dynamics are changed, how > they affect scalability, stability, and robustness of the protocol. Definitely. > 7. For features--note that if the IETF owns the base proto > specification, the maturity level for an extension cannot exceed > the base spec's one, per 2026 because it is a normative ref. > > Plus fix the outdated procedural facts--those come from the times > when IAB approved RFCs. > > Opinions are welcome. Above I've suggested that instead of making it harder to get a document to PS, make it harder to just get a document to PS and then do nothing for the next decade. A three year threshhold would affect a lot of existing PS documents and force some cleanup. I'm not sure what to call the downgrade. AS - abandoned standard? Thanks > Alex Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 13 15:21:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17533 for ; Thu, 13 Mar 2003 15:21:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DKOaO27650; Thu, 13 Mar 2003 15:24:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DKHfO27356 for ; Thu, 13 Mar 2003 15:17:41 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15490 for ; Thu, 13 Mar 2003 15:02:34 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tYwQ-0008zE-00; Thu, 13 Mar 2003 12:04:38 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <88186957801.20030313120334@psg.com> To: Curtis Villamizar CC: routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <200303130601.BAA87631@workhorse.fictitious.org> References: <200303130601.BAA87631@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 12:03:34 -0800 Content-Transfer-Encoding: 7bit Curtis, Thanks for your comments, see inline below, pls. >> The downside would be that if for some reason we would like to >> encourage implementation of something by making this a proposed >> standard, we wouldn't be able to do this until we had at least >> two interoperable implementations. > I'm all for raising the quality bar but some work, such as the > MPLS-diffserv is very good work but has one implementation (AFAIK > there is only one complete implementation in this case). If we do > have consensus that something is worthwhile, it's not desireable to > keep this as an internet-draft and have it expiring all the time. Maybe we should try to agree on what's the most common case and optimize for it while still provide an exception mechanism for rare cases. I.e., if we believe that raised bar would provide helpful noise reduction in the majority of cases, we could then say that this req can be waived if there is a strong consensus that a technology is worth pushing to STD with a single implementation. > Maybe downgrade it (to what?) if there are not two implementation > reported within 2-3 years. > Also requiring that protocols advance, be updated, or be downgraded > (to what?) in 2-3 years would prevent what happenned to BGP (not being > updated when it needed it for many years). Hmmm... I hear you... My first concern would be that we don't have the notion of downgrading other than putting things to historical, and only if believe that practicing a standard may damage things... Even if we came up with a mechanism of downgrading things, where would we downgrade a PS? to an internet-draft? Also, in many cases, it's better to have _some_ specification than nothing. I agree with your concern, however... We need to think how to stimulate people to keep specifications up to date. >> 2. MIBs. The document introduces a dependency between the MIB ... > Read-only! No question on that one. There are some things that don't > much sense to make read-write so making write optional would be best. > A lot of useful stuff gets implemented and doesn't need a MIB to be > successfully deployed, particularly protocol extensions. > A good example of an extension that will not need a MIB to be > successfully deployed is the current soft-preemption draft. It adds 3 > bits to two existing bitfields and defines the semantics. You could > argue that later on a counter of the number of soft-preemptions vs > hard preemptions could/should be added but that shouldn't be needed to > get to PS. For DS, yes, keep the MIB requirement. we seem to be in agreement then--make MIBs optional for extensions and require read-only. >> 3. Reports. >> >> The text currently requires two reports submitted to the IESG >> along with the specs, the reports generally summarize the protocol >> scalability characteristics, experience in deployment of it, etc. >> These usually become separate RFCs. >> >> The de facto practice we have now is to not require those for >> extensions. I think the text should ask for only an implementation >> report (to ensure 2 interop implementations) submitted to the ADs >> for features. > Why not implementation experience? I could be a 2 pager. (With all > the boilerplate there is no such thing as a one pager anymore). I guess it's more of a question of which form to use for this. May be an e-mail message for PS and an implementation experience document for DS and Full STD. >> Add the following: >> >> 4. Provide guidelines about what sort of details should be described >> in a specification. >> >> There have been discussions recently about what sort of details >> should be described for routing protocols. i.e., only bits on the >> wire (message format only) vs including node-local decisions, >> FSMs, timing, etc. > More than bits on the wire. > OTOH the BGP FSM exercise we just went through IMHO was excessive. Opinions vary :) >> I fundamentally believe that node-local decisions, as well as >> timing are important for routing protocol specifications (this, in >> fact, is how currently used protocols are described), and think >> that the document should spell this out as a requirement. >> >> 5. Spell out what routing-specific details are expected in the >> security section for new protocols, i.e., threat analysis and >> authentication; and for extensions: changes to the set of possible >> attacks and to the protocols security mechanisms. > Yes. >> 6. For features--the specs should also talk about backwards >> compatibility, describing how the new feature interoperates with >> routers not implementing it, if protocol dynamics are changed, how >> they affect scalability, stability, and robustness of the protocol. > Definitely. >> 7. For features--note that if the IETF owns the base proto >> specification, the maturity level for an extension cannot exceed >> the base spec's one, per 2026 because it is a normative ref. >> >> Plus fix the outdated procedural facts--those come from the times >> when IAB approved RFCs. >> >> Opinions are welcome. > Above I've suggested that instead of making it harder to get a > document to PS, make it harder to just get a document to PS and then > do nothing for the next decade. A three year threshhold would affect > a lot of existing PS documents and force some cleanup. I'm not sure > what to call the downgrade. AS - abandoned standard? BTW, do we feel that we have people who are interested AND qualified to do the clean-up? This will be an interesting discussion topic for SF... Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Mar 13 15:22:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17565 for ; Thu, 13 Mar 2003 15:22:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DKb0v28389 for routing-discussion-archive@odin.ietf.org; Thu, 13 Mar 2003 15:37:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DKOaO27650; Thu, 13 Mar 2003 15:24:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DKHfO27356 for ; Thu, 13 Mar 2003 15:17:41 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15490 for ; Thu, 13 Mar 2003 15:02:34 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tYwQ-0008zE-00; Thu, 13 Mar 2003 12:04:38 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <88186957801.20030313120334@psg.com> To: Curtis Villamizar CC: routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <200303130601.BAA87631@workhorse.fictitious.org> References: <200303130601.BAA87631@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 12:03:34 -0800 Content-Transfer-Encoding: 7bit Curtis, Thanks for your comments, see inline below, pls. >> The downside would be that if for some reason we would like to >> encourage implementation of something by making this a proposed >> standard, we wouldn't be able to do this until we had at least >> two interoperable implementations. > I'm all for raising the quality bar but some work, such as the > MPLS-diffserv is very good work but has one implementation (AFAIK > there is only one complete implementation in this case). If we do > have consensus that something is worthwhile, it's not desireable to > keep this as an internet-draft and have it expiring all the time. Maybe we should try to agree on what's the most common case and optimize for it while still provide an exception mechanism for rare cases. I.e., if we believe that raised bar would provide helpful noise reduction in the majority of cases, we could then say that this req can be waived if there is a strong consensus that a technology is worth pushing to STD with a single implementation. > Maybe downgrade it (to what?) if there are not two implementation > reported within 2-3 years. > Also requiring that protocols advance, be updated, or be downgraded > (to what?) in 2-3 years would prevent what happenned to BGP (not being > updated when it needed it for many years). Hmmm... I hear you... My first concern would be that we don't have the notion of downgrading other than putting things to historical, and only if believe that practicing a standard may damage things... Even if we came up with a mechanism of downgrading things, where would we downgrade a PS? to an internet-draft? Also, in many cases, it's better to have _some_ specification than nothing. I agree with your concern, however... We need to think how to stimulate people to keep specifications up to date. >> 2. MIBs. The document introduces a dependency between the MIB ... > Read-only! No question on that one. There are some things that don't > much sense to make read-write so making write optional would be best. > A lot of useful stuff gets implemented and doesn't need a MIB to be > successfully deployed, particularly protocol extensions. > A good example of an extension that will not need a MIB to be > successfully deployed is the current soft-preemption draft. It adds 3 > bits to two existing bitfields and defines the semantics. You could > argue that later on a counter of the number of soft-preemptions vs > hard preemptions could/should be added but that shouldn't be needed to > get to PS. For DS, yes, keep the MIB requirement. we seem to be in agreement then--make MIBs optional for extensions and require read-only. >> 3. Reports. >> >> The text currently requires two reports submitted to the IESG >> along with the specs, the reports generally summarize the protocol >> scalability characteristics, experience in deployment of it, etc. >> These usually become separate RFCs. >> >> The de facto practice we have now is to not require those for >> extensions. I think the text should ask for only an implementation >> report (to ensure 2 interop implementations) submitted to the ADs >> for features. > Why not implementation experience? I could be a 2 pager. (With all > the boilerplate there is no such thing as a one pager anymore). I guess it's more of a question of which form to use for this. May be an e-mail message for PS and an implementation experience document for DS and Full STD. >> Add the following: >> >> 4. Provide guidelines about what sort of details should be described >> in a specification. >> >> There have been discussions recently about what sort of details >> should be described for routing protocols. i.e., only bits on the >> wire (message format only) vs including node-local decisions, >> FSMs, timing, etc. > More than bits on the wire. > OTOH the BGP FSM exercise we just went through IMHO was excessive. Opinions vary :) >> I fundamentally believe that node-local decisions, as well as >> timing are important for routing protocol specifications (this, in >> fact, is how currently used protocols are described), and think >> that the document should spell this out as a requirement. >> >> 5. Spell out what routing-specific details are expected in the >> security section for new protocols, i.e., threat analysis and >> authentication; and for extensions: changes to the set of possible >> attacks and to the protocols security mechanisms. > Yes. >> 6. For features--the specs should also talk about backwards >> compatibility, describing how the new feature interoperates with >> routers not implementing it, if protocol dynamics are changed, how >> they affect scalability, stability, and robustness of the protocol. > Definitely. >> 7. For features--note that if the IETF owns the base proto >> specification, the maturity level for an extension cannot exceed >> the base spec's one, per 2026 because it is a normative ref. >> >> Plus fix the outdated procedural facts--those come from the times >> when IAB approved RFCs. >> >> Opinions are welcome. > Above I've suggested that instead of making it harder to get a > document to PS, make it harder to just get a document to PS and then > do nothing for the next decade. A three year threshhold would affect > a lot of existing PS documents and force some cleanup. I'm not sure > what to call the downgrade. AS - abandoned standard? BTW, do we feel that we have people who are interested AND qualified to do the clean-up? This will be an interesting discussion topic for SF... Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 13 16:21:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19599 for ; Thu, 13 Mar 2003 16:21:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLTAO32557; Thu, 13 Mar 2003 16:29:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLPIO32426 for ; Thu, 13 Mar 2003 16:25:18 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19300 for ; Thu, 13 Mar 2003 16:10:07 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA91882; Thu, 13 Mar 2003 16:11:19 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303132111.QAA91882@workhorse.fictitious.org> To: Alex Zinin cc: Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Thu, 13 Mar 2003 12:03:34 PST." <88186957801.20030313120334@psg.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 16:11:19 -0500 In message <88186957801.20030313120334@psg.com>, Alex Zinin writes: > Curtis, > > Thanks for your comments, see inline below, pls. > > >> The downside would be that if for some reason we would like to > >> encourage implementation of something by making this a proposed > >> standard, we wouldn't be able to do this until we had at least > >> two interoperable implementations. > > > I'm all for raising the quality bar but some work, such as the > > MPLS-diffserv is very good work but has one implementation (AFAIK > > there is only one complete implementation in this case). If we do > > have consensus that something is worthwhile, it's not desireable to > > keep this as an internet-draft and have it expiring all the time. > > Maybe we should try to agree on what's the most common case and > optimize for it while still provide an exception mechanism for rare > cases. I.e., if we believe that raised bar would provide helpful noise > reduction in the majority of cases, we could then say that this req > can be waived if there is a strong consensus that a technology is > worth pushing to STD with a single implementation. OK. Raising the bar with an allowance for exceptions sounds good. > >> 3. Reports. > >> > >> The text currently requires two reports submitted to the IESG > >> along with the specs, the reports generally summarize the protocol > >> scalability characteristics, experience in deployment of it, etc. > >> These usually become separate RFCs. > >> > >> The de facto practice we have now is to not require those for > >> extensions. I think the text should ask for only an implementation > >> report (to ensure 2 interop implementations) submitted to the ADs > >> for features. > > > Why not implementation experience? I could be a 2 pager. (With all > > the boilerplate there is no such thing as a one pager anymore). > > I guess it's more of a question of which form to use for this. > May be an e-mail message for PS and an implementation experience > document for DS and Full STD. Implementation experience for PS could be as simple as: we coded and it makes in lab testing and on when we turned it on. Interoperability testing was done with and we worked around and know how to fix and will . This would tell us a bit more than implementation experience of and and . Replace blanks as appropriate. :-) I think an implementation experience even if it says something was coded and lab tested can be a measure of the maturity of spec. If it is simple and seems extremely safe and obviously useful the bar can be low. For something highly complex and controversial, the bar should be higher. If scalability is seriously in question, limited deployment should be required. The IESG gets to decide how much implementation experience a particular PS merits based on complexity, risks, and strength of the consensus. This will very much reduce the noise. > > Above I've suggested that instead of making it harder to get a > > document to PS, make it harder to just get a document to PS and then > > do nothing for the next decade. A three year threshhold would affect > > a lot of existing PS documents and force some cleanup. I'm not sure > > what to call the downgrade. AS - abandoned standard? > > BTW, do we feel that we have people who are interested AND qualified > to do the clean-up? The PS authors and WGs should move drafts forward or expect the PS to get downgraded. If no one cares enough to move from PS to DS, the standard is assumed to have been abandoned. If there was no deployment after 3 years then it makes sense to downgrade since the spec is implemented but unused but no one wants to voluntarily admit their PS is dormant. A good example of an old spec that may need a good look at implementation experience is route flap damping. The spec says: 4.4.3 Per Route State Information must be maintained per some tuple representing a route. At the very minimum, the NLRI (BGP prefix and length) must be contained in the tuple. Different BGP attributes may be included or excluded depending on the specific situation. The AS path should also be contained in the tuple by default. The tuple may also optionally contain other BGP attributes such as MULTI_EXIT_DISCRIMINATOR (MED). The tuple representing a route for the purpose of route flap damping is: tuple entry default options ------------------------------------------- NLRI prefix required length required AS path included option to exclude last AS set in path excluded option to include next hop excluded option to include MED excluded option to include in comparisons only The AS path is generally included in order to identify downstream instability which is not being damped or not being sufficiently damped and is alternating between a stable and an unstable path. The first implementation was by Cisco followed by gated. None of the implementations offerred "AS path" in the tuple. Implementation experience should include comments from Randy Bush and others along the lines of "route flap damping considered harmful". An examination of the types of problems that have occurred would show that if "AS path" was part of the tuple, the problem would not have occurred. As a community, then do we 1) give up on route flap damping or 2) push the issue of including AS path in the tuple. Requiring that the PS go to DS or be considered abandoned would prevent inaction. > This will be an interesting discussion topic for SF... One of the strengths of the IETF in the earlier days was the people proposing protocols were writing the code. If someone proposed something seemingly elegant but massively complex, they were free to go off and implement it and since they'd never finish it, it became a non-issue. Putting the strong emphasis back on implementation and deplyment before something even gets to PS would help cut down the noise. It might even be worth not accepting a draft as a WG item until either at least one implementation exists, or there is strong consensus that the draft is within the charter and worth doing. > Alex Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Mar 13 16:21:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19634 for ; Thu, 13 Mar 2003 16:21:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DLaQm00562 for routing-discussion-archive@odin.ietf.org; Thu, 13 Mar 2003 16:36:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLTAO32557; Thu, 13 Mar 2003 16:29:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DLPIO32426 for ; Thu, 13 Mar 2003 16:25:18 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19300 for ; Thu, 13 Mar 2003 16:10:07 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA91882; Thu, 13 Mar 2003 16:11:19 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303132111.QAA91882@workhorse.fictitious.org> To: Alex Zinin cc: Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Thu, 13 Mar 2003 12:03:34 PST." <88186957801.20030313120334@psg.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 16:11:19 -0500 In message <88186957801.20030313120334@psg.com>, Alex Zinin writes: > Curtis, > > Thanks for your comments, see inline below, pls. > > >> The downside would be that if for some reason we would like to > >> encourage implementation of something by making this a proposed > >> standard, we wouldn't be able to do this until we had at least > >> two interoperable implementations. > > > I'm all for raising the quality bar but some work, such as the > > MPLS-diffserv is very good work but has one implementation (AFAIK > > there is only one complete implementation in this case). If we do > > have consensus that something is worthwhile, it's not desireable to > > keep this as an internet-draft and have it expiring all the time. > > Maybe we should try to agree on what's the most common case and > optimize for it while still provide an exception mechanism for rare > cases. I.e., if we believe that raised bar would provide helpful noise > reduction in the majority of cases, we could then say that this req > can be waived if there is a strong consensus that a technology is > worth pushing to STD with a single implementation. OK. Raising the bar with an allowance for exceptions sounds good. > >> 3. Reports. > >> > >> The text currently requires two reports submitted to the IESG > >> along with the specs, the reports generally summarize the protocol > >> scalability characteristics, experience in deployment of it, etc. > >> These usually become separate RFCs. > >> > >> The de facto practice we have now is to not require those for > >> extensions. I think the text should ask for only an implementation > >> report (to ensure 2 interop implementations) submitted to the ADs > >> for features. > > > Why not implementation experience? I could be a 2 pager. (With all > > the boilerplate there is no such thing as a one pager anymore). > > I guess it's more of a question of which form to use for this. > May be an e-mail message for PS and an implementation experience > document for DS and Full STD. Implementation experience for PS could be as simple as: we coded and it makes in lab testing and on when we turned it on. Interoperability testing was done with and we worked around and know how to fix and will . This would tell us a bit more than implementation experience of and and . Replace blanks as appropriate. :-) I think an implementation experience even if it says something was coded and lab tested can be a measure of the maturity of spec. If it is simple and seems extremely safe and obviously useful the bar can be low. For something highly complex and controversial, the bar should be higher. If scalability is seriously in question, limited deployment should be required. The IESG gets to decide how much implementation experience a particular PS merits based on complexity, risks, and strength of the consensus. This will very much reduce the noise. > > Above I've suggested that instead of making it harder to get a > > document to PS, make it harder to just get a document to PS and then > > do nothing for the next decade. A three year threshhold would affect > > a lot of existing PS documents and force some cleanup. I'm not sure > > what to call the downgrade. AS - abandoned standard? > > BTW, do we feel that we have people who are interested AND qualified > to do the clean-up? The PS authors and WGs should move drafts forward or expect the PS to get downgraded. If no one cares enough to move from PS to DS, the standard is assumed to have been abandoned. If there was no deployment after 3 years then it makes sense to downgrade since the spec is implemented but unused but no one wants to voluntarily admit their PS is dormant. A good example of an old spec that may need a good look at implementation experience is route flap damping. The spec says: 4.4.3 Per Route State Information must be maintained per some tuple representing a route. At the very minimum, the NLRI (BGP prefix and length) must be contained in the tuple. Different BGP attributes may be included or excluded depending on the specific situation. The AS path should also be contained in the tuple by default. The tuple may also optionally contain other BGP attributes such as MULTI_EXIT_DISCRIMINATOR (MED). The tuple representing a route for the purpose of route flap damping is: tuple entry default options ------------------------------------------- NLRI prefix required length required AS path included option to exclude last AS set in path excluded option to include next hop excluded option to include MED excluded option to include in comparisons only The AS path is generally included in order to identify downstream instability which is not being damped or not being sufficiently damped and is alternating between a stable and an unstable path. The first implementation was by Cisco followed by gated. None of the implementations offerred "AS path" in the tuple. Implementation experience should include comments from Randy Bush and others along the lines of "route flap damping considered harmful". An examination of the types of problems that have occurred would show that if "AS path" was part of the tuple, the problem would not have occurred. As a community, then do we 1) give up on route flap damping or 2) push the issue of including AS path in the tuple. Requiring that the PS go to DS or be considered abandoned would prevent inaction. > This will be an interesting discussion topic for SF... One of the strengths of the IETF in the earlier days was the people proposing protocols were writing the code. If someone proposed something seemingly elegant but massively complex, they were free to go off and implement it and since they'd never finish it, it became a non-issue. Putting the strong emphasis back on implementation and deplyment before something even gets to PS would help cut down the noise. It might even be worth not accepting a draft as a WG item until either at least one implementation exists, or there is strong consensus that the draft is within the charter and worth doing. > Alex Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 13 21:08:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29158 for ; Thu, 13 Mar 2003 21:08:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E2HfO20304; Thu, 13 Mar 2003 21:17:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E2AWO20042 for ; Thu, 13 Mar 2003 21:10:32 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28898 for ; Thu, 13 Mar 2003 20:55:19 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18teRo-000DTQ-00; Thu, 13 Mar 2003 17:57:24 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <53208083157.20030313175539@psg.com> To: Curtis Villamizar CC: routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <200303132111.QAA91882@workhorse.fictitious.org> References: <200303132111.QAA91882@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 17:55:39 -0800 Content-Transfer-Encoding: 7bit Curtis, I'll put the points you suggested on the slides for the meeting. On one particular point: >> This will be an interesting discussion topic for SF... > One of the strengths of the IETF in the earlier days was the people > proposing protocols were writing the code. If someone proposed > something seemingly elegant but massively complex, they were free to > go off and implement it and since they'd never finish it, it became a > non-issue. Putting the strong emphasis back on implementation and > deplyment before something even gets to PS would help cut down the > noise. I don't think _deployment_ experience should be required for PS, for several reasons: o We should have a way to encourage deployment of protocols by pushing them to PS o IANA code-point allocations are often done after a doc is approved as an RFC, which means that the implementations would need to be deployed with temporary hacks, and then change to the ones with real values... not good. Plus, even though I believe requiring 2 implementations would be useful, I also hear people say that the bar for PS is already way too high than it was expected to be... > It might even be worth not accepting a draft as a WG item > until either at least one implementation exists, or there is strong > consensus that the draft is within the charter and worth doing. This would be an over-kill, I think. Problems mentioned above apply. Plus, we DO want vendors to come to the IETF early in the process while they are flexible enough with their implementations for the IETF process to be meaningful. Besides, consensus, as well as agreement of the ADs (and often IESG) is already a requirement for a document to become a WG item. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Mar 13 21:09:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29177 for ; Thu, 13 Mar 2003 21:09:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E2O4Y20721 for routing-discussion-archive@odin.ietf.org; Thu, 13 Mar 2003 21:24:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E2HfO20304; Thu, 13 Mar 2003 21:17:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E2AWO20042 for ; Thu, 13 Mar 2003 21:10:32 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28898 for ; Thu, 13 Mar 2003 20:55:19 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18teRo-000DTQ-00; Thu, 13 Mar 2003 17:57:24 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <53208083157.20030313175539@psg.com> To: Curtis Villamizar CC: routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <200303132111.QAA91882@workhorse.fictitious.org> References: <200303132111.QAA91882@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 17:55:39 -0800 Content-Transfer-Encoding: 7bit Curtis, I'll put the points you suggested on the slides for the meeting. On one particular point: >> This will be an interesting discussion topic for SF... > One of the strengths of the IETF in the earlier days was the people > proposing protocols were writing the code. If someone proposed > something seemingly elegant but massively complex, they were free to > go off and implement it and since they'd never finish it, it became a > non-issue. Putting the strong emphasis back on implementation and > deplyment before something even gets to PS would help cut down the > noise. I don't think _deployment_ experience should be required for PS, for several reasons: o We should have a way to encourage deployment of protocols by pushing them to PS o IANA code-point allocations are often done after a doc is approved as an RFC, which means that the implementations would need to be deployed with temporary hacks, and then change to the ones with real values... not good. Plus, even though I believe requiring 2 implementations would be useful, I also hear people say that the bar for PS is already way too high than it was expected to be... > It might even be worth not accepting a draft as a WG item > until either at least one implementation exists, or there is strong > consensus that the draft is within the charter and worth doing. This would be an over-kill, I think. Problems mentioned above apply. Plus, we DO want vendors to come to the IETF early in the process while they are flexible enough with their implementations for the IETF process to be meaningful. Besides, consensus, as well as agreement of the ADs (and often IESG) is already a requirement for a document to become a WG item. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 13 23:24:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02468 for ; Thu, 13 Mar 2003 23:24:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4X5O28819; Thu, 13 Mar 2003 23:33:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4PtO28485 for ; Thu, 13 Mar 2003 23:25:55 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02157 for ; Thu, 13 Mar 2003 23:10:38 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id XAA94988; Thu, 13 Mar 2003 23:11:47 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303140411.XAA94988@workhorse.fictitious.org> To: Alex Zinin cc: Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Thu, 13 Mar 2003 17:55:39 PST." <53208083157.20030313175539@psg.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 23:11:47 -0500 In message <53208083157.20030313175539@psg.com>, Alex Zinin writes: > Curtis, > > I'll put the points you suggested on the slides for the meeting. > > On one particular point: > > >> This will be an interesting discussion topic for SF... > > > One of the strengths of the IETF in the earlier days was the people > > proposing protocols were writing the code. If someone proposed > > something seemingly elegant but massively complex, they were free to > > go off and implement it and since they'd never finish it, it became a > > non-issue. Putting the strong emphasis back on implementation and > > deplyment before something even gets to PS would help cut down the > > noise. > > I don't think _deployment_ experience should be required for PS, > for several reasons: > > o We should have a way to encourage deployment of protocols > by pushing them to PS > > o IANA code-point allocations are often done after a doc is approved > as an RFC, which means that the implementations would need to > be deployed with temporary hacks, and then change to the ones with > real values... not good. > > Plus, even though I believe requiring 2 implementations would be > useful, I also hear people say that the bar for PS is already way too > high than it was expected to be... > > > It might even be worth not accepting a draft as a WG item > > until either at least one implementation exists, or there is strong > > consensus that the draft is within the charter and worth doing. > > This would be an over-kill, I think. Problems mentioned above apply. > Plus, we DO want vendors to come to the IETF early in the process > while they are flexible enough with their implementations for the > IETF process to be meaningful. Its fine to discuss such a draft on the WG mailing list and then make it a WG item when one implemetation exists. This would keep people from coming to the IETF meetings requesting a presentation slot so they can ask for complete vaporware to be added as a WG item. If the answer is already definitely "no" then they are more likely to just submit the draft, ask the WG mailing list for comments and begin the implementation, the way things used to be. Then when the implementation is done or nearly done, report on how well it works and if there is rough consensus make it a WG item. When the second implemetation comes along and interoperates, go for WG last call and pass it along to the IESG. Only if there was strong consensus should an individual submission be accepted as a WG item without at least one completed or nearly complete implementation. > Besides, consensus, as well as agreement of the ADs (and often IESG) > is already a requirement for a document to become a WG item. This would reduce the number of arguments about whether consensus was too rough or sufficient by providing an additiona criteria. There would be far fewer internet-draft meeting the criteria that would make such an argument at all relevant if consensus was not perfect. > Alex Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Mar 13 23:25:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02493 for ; Thu, 13 Mar 2003 23:25:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E4drX29901 for routing-discussion-archive@odin.ietf.org; Thu, 13 Mar 2003 23:39:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4X5O28819; Thu, 13 Mar 2003 23:33:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E4PtO28485 for ; Thu, 13 Mar 2003 23:25:55 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02157 for ; Thu, 13 Mar 2003 23:10:38 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id XAA94988; Thu, 13 Mar 2003 23:11:47 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303140411.XAA94988@workhorse.fictitious.org> To: Alex Zinin cc: Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Thu, 13 Mar 2003 17:55:39 PST." <53208083157.20030313175539@psg.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Mar 2003 23:11:47 -0500 In message <53208083157.20030313175539@psg.com>, Alex Zinin writes: > Curtis, > > I'll put the points you suggested on the slides for the meeting. > > On one particular point: > > >> This will be an interesting discussion topic for SF... > > > One of the strengths of the IETF in the earlier days was the people > > proposing protocols were writing the code. If someone proposed > > something seemingly elegant but massively complex, they were free to > > go off and implement it and since they'd never finish it, it became a > > non-issue. Putting the strong emphasis back on implementation and > > deplyment before something even gets to PS would help cut down the > > noise. > > I don't think _deployment_ experience should be required for PS, > for several reasons: > > o We should have a way to encourage deployment of protocols > by pushing them to PS > > o IANA code-point allocations are often done after a doc is approved > as an RFC, which means that the implementations would need to > be deployed with temporary hacks, and then change to the ones with > real values... not good. > > Plus, even though I believe requiring 2 implementations would be > useful, I also hear people say that the bar for PS is already way too > high than it was expected to be... > > > It might even be worth not accepting a draft as a WG item > > until either at least one implementation exists, or there is strong > > consensus that the draft is within the charter and worth doing. > > This would be an over-kill, I think. Problems mentioned above apply. > Plus, we DO want vendors to come to the IETF early in the process > while they are flexible enough with their implementations for the > IETF process to be meaningful. Its fine to discuss such a draft on the WG mailing list and then make it a WG item when one implemetation exists. This would keep people from coming to the IETF meetings requesting a presentation slot so they can ask for complete vaporware to be added as a WG item. If the answer is already definitely "no" then they are more likely to just submit the draft, ask the WG mailing list for comments and begin the implementation, the way things used to be. Then when the implementation is done or nearly done, report on how well it works and if there is rough consensus make it a WG item. When the second implemetation comes along and interoperates, go for WG last call and pass it along to the IESG. Only if there was strong consensus should an individual submission be accepted as a WG item without at least one completed or nearly complete implementation. > Besides, consensus, as well as agreement of the ADs (and often IESG) > is already a requirement for a document to become a WG item. This would reduce the number of arguments about whether consensus was too rough or sufficient by providing an additiona criteria. There would be far fewer internet-draft meeting the criteria that would make such an argument at all relevant if consensus was not perfect. > Alex Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 15 10:56:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19677 for ; Sat, 15 Mar 2003 10:56:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FG24O15244; Sat, 15 Mar 2003 11:02:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFuqO15121 for ; Sat, 15 Mar 2003 10:56:52 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19322 for ; Sat, 15 Mar 2003 10:40:51 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA07354; Sat, 15 Mar 2003 10:41:39 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303151541.KAA07354@workhorse.fictitious.org> To: Russ White cc: Alex Zinin , Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Sat, 15 Mar 2003 07:26:00 EST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 10:41:39 -0500 In message , Russ White writes: > > > It seems to me that we almost need/want: > > -- this is something that everyone should do, or is a good idea, but it's > not being implemented for some reason we can't fathom (or don't want > to talk about) We could call this a best future practices if it is related to operations. > I don't know, it seems sometimes that good ideas get tossed around, and > then don't get implemented, so they don't get recorded except in a draft > that finally dies. Then, perhaps a year later, we get the same idea in a > different form, and it dies as well. > > Maybe we also need a to push some things directly to historical, so we have > an idea of all the really bad ideas that have been brought up. It just > seems like we're not capturing all we could, sometimes, in the process. Good ideas in principle however in practice we have a manpower problem. Documenting all possible good ideas would add to the load. Documenting all possible bad idea would be too much. They are just too plentiful. Besides, we might hurt someone's feelings. :-) [ aside: You've probably heard the statement "the Internet is growing exponentially but the amount of clue is growing linearly at best" (a quote often attributed to Randy Bush, but whatever the origins it dates back to at least the early 90s). I might also add that participation in the IETF is growing exponentially but the amount of clue is growing linearly at best. Bob Braden has expressed concerns of "increase in entropy" in the IETF. This would make the practice of documenting bad ideas unscalable and the IETF does its best to avoid unscalable undertakings. :-) ] > > >> Add the following: > > >> > > >> 4. Provide guidelines about what sort of details should be described > > >> in a specification. > > >> > > >> There have been discussions recently about what sort of details > > >> should be described for routing protocols. i.e., only bits on the > > >> wire (message format only) vs including node-local decisions, > > >> FSMs, timing, etc. > > > > > More than bits on the wire. > > > > > OTOH the BGP FSM exercise we just went through IMHO was excessive. > > > > Opinions vary :) > > I actually agree--sometimes we get too caught up in over specifying things. > We're losing some of our creativity here, and pushing things into corners, > it feels like. For instance, if someone else comes up with an fsm for bgp > that's _much_ simpler, and still interoperates (a bgp peer can't tell the > new fsm from the old), then why are specifying to this point, and stifling > new things--just so we prevent people from making mistakes on it? > > Maybe things like this (the fsm) should be pulled from the standard, and > made "informational," or "standard contingent," or something like that, so > we have a place to say (again): "this is a really good idea, this is how > some other people may have done it, but we won't hold to this part, as long > as you interperate, and can prove to interoperate." In fact, no-one I know > actually implements the bgp fsm the way it's outlined in the doc (at least > the last one I read). The plain fact in this case is that in a decade of practice virtually no problems where due to the state machine except with brand spanking new and quite naive implementations, even thought the FSM was loosely specified and perhaps not even entirely correct. It would have been better to put effort into 1) very clearly specifying the route decisions (the single area that caused the vast majority of problems), 2) documenting means to make BGP implementations work conserving (by far the most common problem rendering independent implementations unusable when their authors think they are done and have some lab testing behind them), and 3) performance implications of design decsions in view of the large number of routes and high rate of route change that BGP implementation will be subject to. The first item belongs in the BGP spec. The next two items probably belong in the protocol experiences document. The WG's time would have been much better spent discussing these *relevant* issues rather than nailing down the exact wording of the FSM. In this case, a limited number of people have 5 or 10 years (or more) of experience with BGP and with numerous BGP implementations and are aware of the history of operation problems but have to think to remember where in the spec the ambiguities or mistakes were in the cases where the spec lead to problems. Those relatively new to BGP tend to concentrate on the first thing that comes up when implementing and the one thing spec writers who haven't done enough coding seem to concentate on, the FSM. IDR had the manpower to nail down the FSM in great detail and now that the exercise is done we can move on. I do feel that due to the 3-6 months of high noise level over the FSM on the IDR mailing list, other discussion may have been drowned out. Now that -19 will be available after this IETF it would be worth a final pass during the last call to make sure the more problematic parts of the spec got the attention they deserved. Then we can move on to the protocol experiences document. There was no real loss over doing a good job on the FSM except time. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 15 10:57:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19703 for ; Sat, 15 Mar 2003 10:57:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FGCln16311 for routing-discussion-archive@odin.ietf.org; Sat, 15 Mar 2003 11:12:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FG24O15244; Sat, 15 Mar 2003 11:02:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FFuqO15121 for ; Sat, 15 Mar 2003 10:56:52 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19322 for ; Sat, 15 Mar 2003 10:40:51 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA07354; Sat, 15 Mar 2003 10:41:39 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303151541.KAA07354@workhorse.fictitious.org> To: Russ White cc: Alex Zinin , Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Sat, 15 Mar 2003 07:26:00 EST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 10:41:39 -0500 In message , Russ White writes: > > > It seems to me that we almost need/want: > > -- this is something that everyone should do, or is a good idea, but it's > not being implemented for some reason we can't fathom (or don't want > to talk about) We could call this a best future practices if it is related to operations. > I don't know, it seems sometimes that good ideas get tossed around, and > then don't get implemented, so they don't get recorded except in a draft > that finally dies. Then, perhaps a year later, we get the same idea in a > different form, and it dies as well. > > Maybe we also need a to push some things directly to historical, so we have > an idea of all the really bad ideas that have been brought up. It just > seems like we're not capturing all we could, sometimes, in the process. Good ideas in principle however in practice we have a manpower problem. Documenting all possible good ideas would add to the load. Documenting all possible bad idea would be too much. They are just too plentiful. Besides, we might hurt someone's feelings. :-) [ aside: You've probably heard the statement "the Internet is growing exponentially but the amount of clue is growing linearly at best" (a quote often attributed to Randy Bush, but whatever the origins it dates back to at least the early 90s). I might also add that participation in the IETF is growing exponentially but the amount of clue is growing linearly at best. Bob Braden has expressed concerns of "increase in entropy" in the IETF. This would make the practice of documenting bad ideas unscalable and the IETF does its best to avoid unscalable undertakings. :-) ] > > >> Add the following: > > >> > > >> 4. Provide guidelines about what sort of details should be described > > >> in a specification. > > >> > > >> There have been discussions recently about what sort of details > > >> should be described for routing protocols. i.e., only bits on the > > >> wire (message format only) vs including node-local decisions, > > >> FSMs, timing, etc. > > > > > More than bits on the wire. > > > > > OTOH the BGP FSM exercise we just went through IMHO was excessive. > > > > Opinions vary :) > > I actually agree--sometimes we get too caught up in over specifying things. > We're losing some of our creativity here, and pushing things into corners, > it feels like. For instance, if someone else comes up with an fsm for bgp > that's _much_ simpler, and still interoperates (a bgp peer can't tell the > new fsm from the old), then why are specifying to this point, and stifling > new things--just so we prevent people from making mistakes on it? > > Maybe things like this (the fsm) should be pulled from the standard, and > made "informational," or "standard contingent," or something like that, so > we have a place to say (again): "this is a really good idea, this is how > some other people may have done it, but we won't hold to this part, as long > as you interperate, and can prove to interoperate." In fact, no-one I know > actually implements the bgp fsm the way it's outlined in the doc (at least > the last one I read). The plain fact in this case is that in a decade of practice virtually no problems where due to the state machine except with brand spanking new and quite naive implementations, even thought the FSM was loosely specified and perhaps not even entirely correct. It would have been better to put effort into 1) very clearly specifying the route decisions (the single area that caused the vast majority of problems), 2) documenting means to make BGP implementations work conserving (by far the most common problem rendering independent implementations unusable when their authors think they are done and have some lab testing behind them), and 3) performance implications of design decsions in view of the large number of routes and high rate of route change that BGP implementation will be subject to. The first item belongs in the BGP spec. The next two items probably belong in the protocol experiences document. The WG's time would have been much better spent discussing these *relevant* issues rather than nailing down the exact wording of the FSM. In this case, a limited number of people have 5 or 10 years (or more) of experience with BGP and with numerous BGP implementations and are aware of the history of operation problems but have to think to remember where in the spec the ambiguities or mistakes were in the cases where the spec lead to problems. Those relatively new to BGP tend to concentrate on the first thing that comes up when implementing and the one thing spec writers who haven't done enough coding seem to concentate on, the FSM. IDR had the manpower to nail down the FSM in great detail and now that the exercise is done we can move on. I do feel that due to the 3-6 months of high noise level over the FSM on the IDR mailing list, other discussion may have been drowned out. Now that -19 will be available after this IETF it would be worth a final pass during the last call to make sure the more problematic parts of the spec got the attention they deserved. Then we can move on to the protocol experiences document. There was no real loss over doing a good job on the FSM except time. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 15 12:13:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20777 for ; Sat, 15 Mar 2003 12:13:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FHCiO19986; Sat, 15 Mar 2003 12:12:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FH0UO18275 for ; Sat, 15 Mar 2003 12:00:30 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20214 for ; Sat, 15 Mar 2003 11:44:28 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA07681; Sat, 15 Mar 2003 11:45:18 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303151645.LAA07681@workhorse.fictitious.org> To: Russ White cc: Alex Zinin , Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Sat, 15 Mar 2003 07:39:37 EST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 11:45:18 -0500 In message , Russ White writes: > > > > It might even be worth not accepting a draft as a WG item > > > until either at least one implementation exists, or there is strong > > > consensus that the draft is within the charter and worth doing. > > > > This would be an over-kill, I think. Problems mentioned above apply. > > Plus, we DO want vendors to come to the IETF early in the process while > > they are flexible enough with their implementations for the IETF process > > to be meaningful. > > In fact, what we are currently seeing is drafts coming before the ietf with > no implementations. The primary reason for this is "tight money." A lot of > people are now unwilling to simply code something to see if it works, then > take it to the ietf, then recode it. The price you pay for bringing a new > feature into a protocol is now doubled over those who just "follow along," > and thus new ideas in protocols are discouraged--and participation in the > process is discouraraged. The bigger the committee that preceeds the implementation, the less likely implementation will be acheivable and the less likely implementations will work. That's why we're not running OSI. Pushing something all the way to PS before implementing it at all is just a bad idea. Doing this makes the decision of the committee of professional standards body attendees almost final. > So, we need to somehow be sensative to this fact in an industry that is > coming into "maturity," whether or not we like it (feeling old yet?). > > The second reason I see this happen (and I've seen it several times now) is > that someone comes up with an idea. It's not implemented, so they don't > take it anyplace, they just sit on it, thinking about it. Then, suddenly, > another idea is published which would compete with theirs, but they believe > their idea is better, in some sense. Ideas can be brought to the IETF without implementations. An internet-draft can be renewed as many times as it takes for the idea to get attention. I'm not suggesting we don't discuss unimplemented idea, just that we don't standardize unimplemented ideas. > So, the rush publish, with no implementation, to make certain both ideas > that solve the same problem are considered. Again, we need some way to take > this into consideration. Sometimes a draft will, in some way, spur your > thinking on an alternate way of solving a problem.... Again, we need to > have some way to take these sorts of things into account. No implementation and incomplete consensus, no standard. That way there are fewer arguments. > :-) > > Russ Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 15 12:14:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20797 for ; Sat, 15 Mar 2003 12:14:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FHTWc20663 for routing-discussion-archive@odin.ietf.org; Sat, 15 Mar 2003 12:29:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FHCiO19986; Sat, 15 Mar 2003 12:12:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FH0UO18275 for ; Sat, 15 Mar 2003 12:00:30 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20214 for ; Sat, 15 Mar 2003 11:44:28 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA07681; Sat, 15 Mar 2003 11:45:18 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303151645.LAA07681@workhorse.fictitious.org> To: Russ White cc: Alex Zinin , Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Sat, 15 Mar 2003 07:39:37 EST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 11:45:18 -0500 In message , Russ White writes: > > > > It might even be worth not accepting a draft as a WG item > > > until either at least one implementation exists, or there is strong > > > consensus that the draft is within the charter and worth doing. > > > > This would be an over-kill, I think. Problems mentioned above apply. > > Plus, we DO want vendors to come to the IETF early in the process while > > they are flexible enough with their implementations for the IETF process > > to be meaningful. > > In fact, what we are currently seeing is drafts coming before the ietf with > no implementations. The primary reason for this is "tight money." A lot of > people are now unwilling to simply code something to see if it works, then > take it to the ietf, then recode it. The price you pay for bringing a new > feature into a protocol is now doubled over those who just "follow along," > and thus new ideas in protocols are discouraged--and participation in the > process is discouraraged. The bigger the committee that preceeds the implementation, the less likely implementation will be acheivable and the less likely implementations will work. That's why we're not running OSI. Pushing something all the way to PS before implementing it at all is just a bad idea. Doing this makes the decision of the committee of professional standards body attendees almost final. > So, we need to somehow be sensative to this fact in an industry that is > coming into "maturity," whether or not we like it (feeling old yet?). > > The second reason I see this happen (and I've seen it several times now) is > that someone comes up with an idea. It's not implemented, so they don't > take it anyplace, they just sit on it, thinking about it. Then, suddenly, > another idea is published which would compete with theirs, but they believe > their idea is better, in some sense. Ideas can be brought to the IETF without implementations. An internet-draft can be renewed as many times as it takes for the idea to get attention. I'm not suggesting we don't discuss unimplemented idea, just that we don't standardize unimplemented ideas. > So, the rush publish, with no implementation, to make certain both ideas > that solve the same problem are considered. Again, we need some way to take > this into consideration. Sometimes a draft will, in some way, spur your > thinking on an alternate way of solving a problem.... Again, we need to > have some way to take these sorts of things into account. No implementation and incomplete consensus, no standard. That way there are fewer arguments. > :-) > > Russ Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 15 21:15:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02249 for ; Sat, 15 Mar 2003 21:15:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2OfO16994; Sat, 15 Mar 2003 21:24:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2JqO16845 for ; Sat, 15 Mar 2003 21:19:52 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01893 for ; Sat, 15 Mar 2003 21:03:40 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18uNX0-0003M6-00; Sat, 15 Mar 2003 18:05:46 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2070393861.20030315120444@psg.com> To: Russ White CC: Curtis Villamizar , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: References: <200303130601.BAA87631@workhorse.fictitious.org> <88186957801.20030313120334@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 12:04:44 -0800 Content-Transfer-Encoding: 7bit Russ- Saturday, March 15, 2003, 4:26:00 AM, Russ White wrote: ... > It seems to me that we almost need/want: > -- this is something that everyone should do, or is a good idea, but it's > not being implemented for some reason we can't fathom (or don't want > to talk about) This looks like a "recommendation" type of thing. However, if we think there's a consensus that something is a really good idea, and we really want it to go forward, 2026 tells us we can make it a PS. It won't go any further without an implementation, but PS should be a good stimulus. On the other hand, if we think it might be a good idea, but we don't really want people to implement and/or deploy it, there must be a reason for this and hence why give someone a false sense of quality by documenting this as a "good idea"?... > I don't know, it seems sometimes that good ideas get tossed around, and > then don't get implemented, so they don't get recorded except in a draft > that finally dies. Then, perhaps a year later, we get the same idea in a > different form, and it dies as well. > Maybe we also need a to push some things directly to historical, so we have > an idea of all the really bad ideas that have been brought up. It just > seems like we're not capturing all we could, sometimes, in the process. It seems that if someone really wants the community to know that something is a really bad idea, one can come up with a " considered harmful" Informational doc. >> > OTOH the BGP FSM exercise we just went through IMHO was excessive. >> >> Opinions vary :) > I actually agree--sometimes we get too caught up in over specifying things. > We're losing some of our creativity here, and pushing things into corners, > it feels like. For instance, if someone else comes up with an fsm for bgp > that's _much_ simpler, and still interoperates (a bgp peer can't tell the > new fsm from the old), then why are specifying to this point, and stifling > new things--just so we prevent people from making mistakes on it? > Maybe things like this (the fsm) should be pulled from the standard, and > made "informational," or "standard contingent," or something like that, so > we have a place to say (again): "this is a really good idea, this is how > some other people may have done it, but we won't hold to this part, as long > as you interperate, and can prove to interoperate." In fact, no-one I know > actually implements the bgp fsm the way it's outlined in the doc (at least > the last one I read). I believe that the quality of a protocol specification should be such that the protocol is implementable by reading the spec (no reverse engineering of existing implementations) and be interoperable with others, plus implementations need to exhibit consistent behavior in those corner cases that matter in real life. When message processing, generation, or general behavior depends on previously received and sent messages, FSM is the commonly accepted and one of the most efficient ways of describing the algorithm. FSM allows one to exhaustively describe required behavior and ensure adequate coverage of state/event or state/message combinations in a human readable and (more importantly) understandable way. Trying to describe the same with just human language will inevitably lead to underspeficiation, inconsistency in interpretations and behavior, which, as we know, may be quite drastic for routing protocols. >> BTW, do we feel that we have people who are interested AND qualified >> to do the clean-up? > I think people would be interested, but it's a matter of time. The next rfc > passed should specify, in the standards track, a 30 hour day, of which 6 > hours are reserved for ietf work, and the remainder are for "normal > living." Exactly... Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 15 21:16:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02312 for ; Sat, 15 Mar 2003 21:16:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2G2W3517201 for routing-discussion-archive@odin.ietf.org; Sat, 15 Mar 2003 21:32:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2OfO16994; Sat, 15 Mar 2003 21:24:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2JqO16845 for ; Sat, 15 Mar 2003 21:19:52 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01893 for ; Sat, 15 Mar 2003 21:03:40 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18uNX0-0003M6-00; Sat, 15 Mar 2003 18:05:46 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2070393861.20030315120444@psg.com> To: Russ White CC: Curtis Villamizar , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: References: <200303130601.BAA87631@workhorse.fictitious.org> <88186957801.20030313120334@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 12:04:44 -0800 Content-Transfer-Encoding: 7bit Russ- Saturday, March 15, 2003, 4:26:00 AM, Russ White wrote: ... > It seems to me that we almost need/want: > -- this is something that everyone should do, or is a good idea, but it's > not being implemented for some reason we can't fathom (or don't want > to talk about) This looks like a "recommendation" type of thing. However, if we think there's a consensus that something is a really good idea, and we really want it to go forward, 2026 tells us we can make it a PS. It won't go any further without an implementation, but PS should be a good stimulus. On the other hand, if we think it might be a good idea, but we don't really want people to implement and/or deploy it, there must be a reason for this and hence why give someone a false sense of quality by documenting this as a "good idea"?... > I don't know, it seems sometimes that good ideas get tossed around, and > then don't get implemented, so they don't get recorded except in a draft > that finally dies. Then, perhaps a year later, we get the same idea in a > different form, and it dies as well. > Maybe we also need a to push some things directly to historical, so we have > an idea of all the really bad ideas that have been brought up. It just > seems like we're not capturing all we could, sometimes, in the process. It seems that if someone really wants the community to know that something is a really bad idea, one can come up with a " considered harmful" Informational doc. >> > OTOH the BGP FSM exercise we just went through IMHO was excessive. >> >> Opinions vary :) > I actually agree--sometimes we get too caught up in over specifying things. > We're losing some of our creativity here, and pushing things into corners, > it feels like. For instance, if someone else comes up with an fsm for bgp > that's _much_ simpler, and still interoperates (a bgp peer can't tell the > new fsm from the old), then why are specifying to this point, and stifling > new things--just so we prevent people from making mistakes on it? > Maybe things like this (the fsm) should be pulled from the standard, and > made "informational," or "standard contingent," or something like that, so > we have a place to say (again): "this is a really good idea, this is how > some other people may have done it, but we won't hold to this part, as long > as you interperate, and can prove to interoperate." In fact, no-one I know > actually implements the bgp fsm the way it's outlined in the doc (at least > the last one I read). I believe that the quality of a protocol specification should be such that the protocol is implementable by reading the spec (no reverse engineering of existing implementations) and be interoperable with others, plus implementations need to exhibit consistent behavior in those corner cases that matter in real life. When message processing, generation, or general behavior depends on previously received and sent messages, FSM is the commonly accepted and one of the most efficient ways of describing the algorithm. FSM allows one to exhaustively describe required behavior and ensure adequate coverage of state/event or state/message combinations in a human readable and (more importantly) understandable way. Trying to describe the same with just human language will inevitably lead to underspeficiation, inconsistency in interpretations and behavior, which, as we know, may be quite drastic for routing protocols. >> BTW, do we feel that we have people who are interested AND qualified >> to do the clean-up? > I think people would be interested, but it's a matter of time. The next rfc > passed should specify, in the standards track, a 30 hour day, of which 6 > hours are reserved for ietf work, and the remainder are for "normal > living." Exactly... Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 15 21:19:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02435 for ; Sat, 15 Mar 2003 21:19:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2SfO17085; Sat, 15 Mar 2003 21:28:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2JqO16847 for ; Sat, 15 Mar 2003 21:19:52 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01894 for ; Sat, 15 Mar 2003 21:03:41 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18uNX1-0003M6-00; Sat, 15 Mar 2003 18:05:48 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14370760167.20030315121050@psg.com> To: Russ White CC: Curtis Villamizar , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: References: <200303132111.QAA91882@workhorse.fictitious.org> <53208083157.20030313175539@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 12:10:50 -0800 Content-Transfer-Encoding: 7bit Russ, > In fact, what we are currently seeing is drafts coming before the ietf with > no implementations. The primary reason for this is "tight money." A lot of > people are now unwilling to simply code something to see if it works, then > take it to the ietf, then recode it. The price you pay for bringing a new > feature into a protocol is now doubled over those who just "follow along," > and thus new ideas in protocols are discouraged--and participation in the > process is discouraraged. Hey, look at this from the positive side--less extensions means more stable routing code == more stable Internet ;) > So, we need to somehow be sensative to this fact in an industry that is > coming into "maturity," whether or not we like it (feeling old yet?). > The second reason I see this happen (and I've seen it several times now) is > that someone comes up with an idea. It's not implemented, so they don't > take it anyplace, they just sit on it, thinking about it. Then, suddenly, > another idea is published which would compete with theirs, but they believe > their idea is better, in some sense. > So, the rush publish, with no implementation, to make certain both ideas > that solve the same problem are considered. Again, we need some way to take > this into consideration. Sometimes a draft will, in some way, spur your > thinking on an alternate way of solving a problem.... Again, we need to > have some way to take these sorts of things into account. Agreed. I think the easiest way to take these into consideration would be NOT to require an implementation for a draft. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 15 21:20:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02498 for ; Sat, 15 Mar 2003 21:20:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2G2ZlI17312 for routing-discussion-archive@odin.ietf.org; Sat, 15 Mar 2003 21:35:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2SfO17085; Sat, 15 Mar 2003 21:28:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2JqO16847 for ; Sat, 15 Mar 2003 21:19:52 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01894 for ; Sat, 15 Mar 2003 21:03:41 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18uNX1-0003M6-00; Sat, 15 Mar 2003 18:05:48 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14370760167.20030315121050@psg.com> To: Russ White CC: Curtis Villamizar , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: References: <200303132111.QAA91882@workhorse.fictitious.org> <53208083157.20030313175539@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 12:10:50 -0800 Content-Transfer-Encoding: 7bit Russ, > In fact, what we are currently seeing is drafts coming before the ietf with > no implementations. The primary reason for this is "tight money." A lot of > people are now unwilling to simply code something to see if it works, then > take it to the ietf, then recode it. The price you pay for bringing a new > feature into a protocol is now doubled over those who just "follow along," > and thus new ideas in protocols are discouraged--and participation in the > process is discouraraged. Hey, look at this from the positive side--less extensions means more stable routing code == more stable Internet ;) > So, we need to somehow be sensative to this fact in an industry that is > coming into "maturity," whether or not we like it (feeling old yet?). > The second reason I see this happen (and I've seen it several times now) is > that someone comes up with an idea. It's not implemented, so they don't > take it anyplace, they just sit on it, thinking about it. Then, suddenly, > another idea is published which would compete with theirs, but they believe > their idea is better, in some sense. > So, the rush publish, with no implementation, to make certain both ideas > that solve the same problem are considered. Again, we need some way to take > this into consideration. Sometimes a draft will, in some way, spur your > thinking on an alternate way of solving a problem.... Again, we need to > have some way to take these sorts of things into account. Agreed. I think the easiest way to take these into consideration would be NOT to require an implementation for a draft. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 15 21:23:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02634 for ; Sat, 15 Mar 2003 21:23:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2WWO17231; Sat, 15 Mar 2003 21:32:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2JrO16853 for ; Sat, 15 Mar 2003 21:19:53 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01896 for ; Sat, 15 Mar 2003 21:03:42 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18uNX3-0003M6-00; Sat, 15 Mar 2003 18:05:49 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9673000719.20030315124811@psg.com> To: Curtis Villamizar CC: Russ White , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <200303151541.KAA07354@workhorse.fictitious.org> References: <200303151541.KAA07354@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 12:48:11 -0800 Content-Transfer-Encoding: 7bit Curtis, > The plain fact in this case is that in a decade of practice virtually > no problems where due to the state machine except with brand spanking > new and quite naive implementations, even thought the FSM was loosely > specified and perhaps not even entirely correct. It would have been > better to put effort into 1) very clearly specifying the route > decisions (the single area that caused the vast majority of problems), > 2) documenting means to make BGP implementations work conserving (by > far the most common problem rendering independent implementations > unusable when their authors think they are done and have some lab > testing behind them), and 3) performance implications of design > decsions in view of the large number of routes and high rate of route > change that BGP implementation will be subject to. The first item > belongs in the BGP spec. The next two items probably belong in the > protocol experiences document. The WG's time would have been much > better spent discussing these *relevant* issues rather than nailing > down the exact wording of the FSM. Agree it would be very useful to address the three topics you mentioned above, not sure it should have been done at the expense of the protocol specification and FSM in particular. This part of the spec (admittedly not the only one) was commonly known to be ammm... not quite correct... and the reason we didn't see too many problems is because a) people knew they couldn't trust completely that part of the spec, so they went directly to reverse engineering, and b) problems with FSM are not globally visible. We couldn't continue living with the spec that was widely know to have problems. ... > I do feel that due to the 3-6 months of high noise level over the FSM > on the IDR mailing list, other discussion may have been drowned out. It wasn't _only_ about FSM, though. The discussions have touch pretty much all parts of the spec. > Now that -19 will be available after this IETF it would be worth a > final pass during the last call to make sure the more problematic > parts of the spec got the attention they deserved. Would be really great! > Then we can move > on to the protocol experiences document. There was no real loss over > doing a good job on the FSM except time. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 15 21:24:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02655 for ; Sat, 15 Mar 2003 21:24:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2G2e4E18260 for routing-discussion-archive@odin.ietf.org; Sat, 15 Mar 2003 21:40:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2WWO17231; Sat, 15 Mar 2003 21:32:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2JrO16853 for ; Sat, 15 Mar 2003 21:19:53 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01896 for ; Sat, 15 Mar 2003 21:03:42 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18uNX3-0003M6-00; Sat, 15 Mar 2003 18:05:49 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9673000719.20030315124811@psg.com> To: Curtis Villamizar CC: Russ White , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <200303151541.KAA07354@workhorse.fictitious.org> References: <200303151541.KAA07354@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 12:48:11 -0800 Content-Transfer-Encoding: 7bit Curtis, > The plain fact in this case is that in a decade of practice virtually > no problems where due to the state machine except with brand spanking > new and quite naive implementations, even thought the FSM was loosely > specified and perhaps not even entirely correct. It would have been > better to put effort into 1) very clearly specifying the route > decisions (the single area that caused the vast majority of problems), > 2) documenting means to make BGP implementations work conserving (by > far the most common problem rendering independent implementations > unusable when their authors think they are done and have some lab > testing behind them), and 3) performance implications of design > decsions in view of the large number of routes and high rate of route > change that BGP implementation will be subject to. The first item > belongs in the BGP spec. The next two items probably belong in the > protocol experiences document. The WG's time would have been much > better spent discussing these *relevant* issues rather than nailing > down the exact wording of the FSM. Agree it would be very useful to address the three topics you mentioned above, not sure it should have been done at the expense of the protocol specification and FSM in particular. This part of the spec (admittedly not the only one) was commonly known to be ammm... not quite correct... and the reason we didn't see too many problems is because a) people knew they couldn't trust completely that part of the spec, so they went directly to reverse engineering, and b) problems with FSM are not globally visible. We couldn't continue living with the spec that was widely know to have problems. ... > I do feel that due to the 3-6 months of high noise level over the FSM > on the IDR mailing list, other discussion may have been drowned out. It wasn't _only_ about FSM, though. The discussions have touch pretty much all parts of the spec. > Now that -19 will be available after this IETF it would be worth a > final pass during the last call to make sure the more problematic > parts of the spec got the attention they deserved. Would be really great! > Then we can move > on to the protocol experiences document. There was no real loss over > doing a good job on the FSM except time. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 15 21:27:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02712 for ; Sat, 15 Mar 2003 21:27:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2aQO17342; Sat, 15 Mar 2003 21:36:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2JsO16857 for ; Sat, 15 Mar 2003 21:19:54 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01900 for ; Sat, 15 Mar 2003 21:03:43 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18uNX3-0003M6-01; Sat, 15 Mar 2003 18:05:49 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5873178965.20030315125109@psg.com> To: Curtis Villamizar CC: Russ White , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <200303151645.LAA07681@workhorse.fictitious.org> References: <200303151645.LAA07681@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 12:51:09 -0800 Content-Transfer-Encoding: 7bit Curtis, ... > Pushing something all the way to PS before implementing it at all is > just a bad idea. Doing this makes the decision of the committee of > professional standards body attendees almost final. ... > I'm not suggesting we don't discuss unimplemented idea, just that we > don't standardize unimplemented ideas. ... > No implementation and incomplete consensus, no standard. That way > there are fewer arguments. This is a little different from what you suggested about the drafts, but we seem to be converging: PS should require implementations (in fact it does already), but I wouldn't like us to require this for internet-draft before they become WG items. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 15 21:27:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02731 for ; Sat, 15 Mar 2003 21:27:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2G2hb718357 for routing-discussion-archive@odin.ietf.org; Sat, 15 Mar 2003 21:43:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2aQO17342; Sat, 15 Mar 2003 21:36:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2JsO16857 for ; Sat, 15 Mar 2003 21:19:54 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01900 for ; Sat, 15 Mar 2003 21:03:43 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18uNX3-0003M6-01; Sat, 15 Mar 2003 18:05:49 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5873178965.20030315125109@psg.com> To: Curtis Villamizar CC: Russ White , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <200303151645.LAA07681@workhorse.fictitious.org> References: <200303151645.LAA07681@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 12:51:09 -0800 Content-Transfer-Encoding: 7bit Curtis, ... > Pushing something all the way to PS before implementing it at all is > just a bad idea. Doing this makes the decision of the committee of > professional standards body attendees almost final. ... > I'm not suggesting we don't discuss unimplemented idea, just that we > don't standardize unimplemented ideas. ... > No implementation and incomplete consensus, no standard. That way > there are fewer arguments. This is a little different from what you suggested about the drafts, but we seem to be converging: PS should require implementations (in fact it does already), but I wouldn't like us to require this for internet-draft before they become WG items. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 15 22:03:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03769 for ; Sat, 15 Mar 2003 22:03:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G3D1O19953; Sat, 15 Mar 2003 22:13:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G382O19777 for ; Sat, 15 Mar 2003 22:08:02 -0500 Received: from mail.cad.zju.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03403 for ; Sat, 15 Mar 2003 21:51:47 -0500 (EST) Received: (qmail 31442 invoked from network); 16 Mar 2003 03:01:19 -0000 Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97) by 210.32.131.2 with SMTP; 16 Mar 2003 03:01:19 -0000 Message-ID: <3E73E791.BBE94040@cad.zju.edu.cn> From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: Curtis Villamizar , Russ White , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 References: <200303151541.KAA07354@workhorse.fictitious.org> <9673000719.20030315124811@psg.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 16 Mar 2003 10:55:13 +0800 Content-Transfer-Encoding: 7bit I'm sorry if my question is out-of-the-interest. I want to know wether there is some guideline on making up a FSM of a routing algo., sometimes I find it a little difficult to understand FSM if text explanation is not well written. thanks > > > I do feel that due to the 3-6 months of high noise level over the FSM > > on the IDR mailing list, other discussion may have been drowned out. > > It wasn't _only_ about FSM, though. The discussions have touch pretty > much all parts of the spec. > > > Now that -19 will be available after this IETF it would be worth a > > final pass during the last call to make sure the more problematic > > parts of the spec got the attention they deserved. > > Would be really great! > > > Then we can move > > on to the protocol experiences document. There was no real loss over > > doing a good job on the FSM except time. > > Alex > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion Regards -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 15 22:04:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03788 for ; Sat, 15 Mar 2003 22:04:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2G3JwN20159 for routing-discussion-archive@odin.ietf.org; Sat, 15 Mar 2003 22:19:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G3D1O19953; Sat, 15 Mar 2003 22:13:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G382O19777 for ; Sat, 15 Mar 2003 22:08:02 -0500 Received: from mail.cad.zju.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03403 for ; Sat, 15 Mar 2003 21:51:47 -0500 (EST) Received: (qmail 31442 invoked from network); 16 Mar 2003 03:01:19 -0000 Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97) by 210.32.131.2 with SMTP; 16 Mar 2003 03:01:19 -0000 Message-ID: <3E73E791.BBE94040@cad.zju.edu.cn> From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: Curtis Villamizar , Russ White , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 References: <200303151541.KAA07354@workhorse.fictitious.org> <9673000719.20030315124811@psg.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 16 Mar 2003 10:55:13 +0800 Content-Transfer-Encoding: 7bit I'm sorry if my question is out-of-the-interest. I want to know wether there is some guideline on making up a FSM of a routing algo., sometimes I find it a little difficult to understand FSM if text explanation is not well written. thanks > > > I do feel that due to the 3-6 months of high noise level over the FSM > > on the IDR mailing list, other discussion may have been drowned out. > > It wasn't _only_ about FSM, though. The discussions have touch pretty > much all parts of the spec. > > > Now that -19 will be available after this IETF it would be worth a > > final pass during the last call to make sure the more problematic > > parts of the spec got the attention they deserved. > > Would be really great! > > > Then we can move > > on to the protocol experiences document. There was no real loss over > > doing a good job on the FSM except time. > > Alex > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion Regards -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sun Mar 16 16:07:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07690 for ; Sun, 16 Mar 2003 16:07:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLGPO23908; Sun, 16 Mar 2003 16:16:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FCePO05435 for ; Sat, 15 Mar 2003 07:40:25 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14912 for ; Sat, 15 Mar 2003 07:24:29 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2FCQVSc022615; Sat, 15 Mar 2003 07:26:31 -0500 (EST) Received: from russpc (rtp-vpn2-406.cisco.com [10.82.241.150]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA09216; Sat, 15 Mar 2003 07:26:30 -0500 (EST) From: Russ White Reply-To: Russ White To: Alex Zinin cc: Curtis Villamizar , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <88186957801.20030313120334@psg.com> Message-ID: References: <200303130601.BAA87631@workhorse.fictitious.org> <88186957801.20030313120334@psg.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 07:26:00 -0500 (Eastern Standard Time) > Maybe we should try to agree on what's the most common case and optimize > for it while still provide an exception mechanism for rare cases. I.e., > if we believe that raised bar would provide helpful noise reduction in > the majority of cases, we could then say that this req can be waived if > there is a strong consensus that a technology is worth pushing to STD > with a single implementation. > > > Maybe downgrade it (to what?) if there are not two implementation > > reported within 2-3 years. > > > Also requiring that protocols advance, be updated, or be downgraded > > (to what?) in 2-3 years would prevent what happenned to BGP (not being > > updated when it needed it for many years). > > Hmmm... I hear you... > > My first concern would be that we don't have the notion of downgrading > other than putting things to historical, and only if believe that > practicing a standard may damage things... Even if we came up with a > mechanism of downgrading things, where would we downgrade a PS? to an > internet-draft? > > Also, in many cases, it's better to have _some_ specification than > nothing. > > I agree with your concern, however... We need to think how to > stimulate people to keep specifications up to date. I think we also might need a category that we don't have today--it seems to me that we only have: -- this is a standard -- this is experimental (we're not really certain this will work, but it seems worth playing with to see) -- this is just informational -- this is in common use, but doesn't impact any protocol, so it's best common practice It seems to me that we almost need/want: -- this is something that everyone should do, or is a good idea, but it's not being implemented for some reason we can't fathom (or don't want to talk about) I don't know, it seems sometimes that good ideas get tossed around, and then don't get implemented, so they don't get recorded except in a draft that finally dies. Then, perhaps a year later, we get the same idea in a different form, and it dies as well. Maybe we also need a to push some things directly to historical, so we have an idea of all the really bad ideas that have been brought up. It just seems like we're not capturing all we could, sometimes, in the process. > >> 2. MIBs. The document introduces a dependency between the MIB > ... > > Read-only! No question on that one. There are some things that don't > > much sense to make read-write so making write optional would be best. > > > A lot of useful stuff gets implemented and doesn't need a MIB to be > > successfully deployed, particularly protocol extensions. > > > A good example of an extension that will not need a MIB to be > > successfully deployed is the current soft-preemption draft. It adds 3 > > bits to two existing bitfields and defines the semantics. You could > > argue that later on a counter of the number of soft-preemptions vs > > hard preemptions could/should be added but that shouldn't be needed to > > get to PS. For DS, yes, keep the MIB requirement. > > we seem to be in agreement then--make MIBs optional for extensions > and require read-only. Yes. > >> Add the following: > >> > >> 4. Provide guidelines about what sort of details should be described > >> in a specification. > >> > >> There have been discussions recently about what sort of details > >> should be described for routing protocols. i.e., only bits on the > >> wire (message format only) vs including node-local decisions, > >> FSMs, timing, etc. > > > More than bits on the wire. > > > OTOH the BGP FSM exercise we just went through IMHO was excessive. > > Opinions vary :) I actually agree--sometimes we get too caught up in over specifying things. We're losing some of our creativity here, and pushing things into corners, it feels like. For instance, if someone else comes up with an fsm for bgp that's _much_ simpler, and still interoperates (a bgp peer can't tell the new fsm from the old), then why are specifying to this point, and stifling new things--just so we prevent people from making mistakes on it? Maybe things like this (the fsm) should be pulled from the standard, and made "informational," or "standard contingent," or something like that, so we have a place to say (again): "this is a really good idea, this is how some other people may have done it, but we won't hold to this part, as long as you interperate, and can prove to interoperate." In fact, no-one I know actually implements the bgp fsm the way it's outlined in the doc (at least the last one I read). > >> 5. Spell out what routing-specific details are expected in the > >> security section for new protocols, i.e., threat analysis and > >> authentication; and for extensions: changes to the set of possible > >> attacks and to the protocols security mechanisms. > > > Yes. Agreed. > > Above I've suggested that instead of making it harder to get a > > document to PS, make it harder to just get a document to PS and then > > do nothing for the next decade. A three year threshhold would affect > > a lot of existing PS documents and force some cleanup. I'm not sure > > what to call the downgrade. AS - abandoned standard? > > BTW, do we feel that we have people who are interested AND qualified > to do the clean-up? I think people would be interested, but it's a matter of time. The next rfc passed should specify, in the standards track, a 30 hour day, of which 6 hours are reserved for ietf work, and the remainder are for "normal living." :-) Russ -- riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sun Mar 16 16:08:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07717 for ; Sun, 16 Mar 2003 16:08:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GLOkw25026 for routing-discussion-archive@odin.ietf.org; Sun, 16 Mar 2003 16:24:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLGPO23908; Sun, 16 Mar 2003 16:16:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FCePO05435 for ; Sat, 15 Mar 2003 07:40:25 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14912 for ; Sat, 15 Mar 2003 07:24:29 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2FCQVSc022615; Sat, 15 Mar 2003 07:26:31 -0500 (EST) Received: from russpc (rtp-vpn2-406.cisco.com [10.82.241.150]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA09216; Sat, 15 Mar 2003 07:26:30 -0500 (EST) From: Russ White Reply-To: Russ White To: Alex Zinin cc: Curtis Villamizar , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <88186957801.20030313120334@psg.com> Message-ID: References: <200303130601.BAA87631@workhorse.fictitious.org> <88186957801.20030313120334@psg.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 07:26:00 -0500 (Eastern Standard Time) > Maybe we should try to agree on what's the most common case and optimize > for it while still provide an exception mechanism for rare cases. I.e., > if we believe that raised bar would provide helpful noise reduction in > the majority of cases, we could then say that this req can be waived if > there is a strong consensus that a technology is worth pushing to STD > with a single implementation. > > > Maybe downgrade it (to what?) if there are not two implementation > > reported within 2-3 years. > > > Also requiring that protocols advance, be updated, or be downgraded > > (to what?) in 2-3 years would prevent what happenned to BGP (not being > > updated when it needed it for many years). > > Hmmm... I hear you... > > My first concern would be that we don't have the notion of downgrading > other than putting things to historical, and only if believe that > practicing a standard may damage things... Even if we came up with a > mechanism of downgrading things, where would we downgrade a PS? to an > internet-draft? > > Also, in many cases, it's better to have _some_ specification than > nothing. > > I agree with your concern, however... We need to think how to > stimulate people to keep specifications up to date. I think we also might need a category that we don't have today--it seems to me that we only have: -- this is a standard -- this is experimental (we're not really certain this will work, but it seems worth playing with to see) -- this is just informational -- this is in common use, but doesn't impact any protocol, so it's best common practice It seems to me that we almost need/want: -- this is something that everyone should do, or is a good idea, but it's not being implemented for some reason we can't fathom (or don't want to talk about) I don't know, it seems sometimes that good ideas get tossed around, and then don't get implemented, so they don't get recorded except in a draft that finally dies. Then, perhaps a year later, we get the same idea in a different form, and it dies as well. Maybe we also need a to push some things directly to historical, so we have an idea of all the really bad ideas that have been brought up. It just seems like we're not capturing all we could, sometimes, in the process. > >> 2. MIBs. The document introduces a dependency between the MIB > ... > > Read-only! No question on that one. There are some things that don't > > much sense to make read-write so making write optional would be best. > > > A lot of useful stuff gets implemented and doesn't need a MIB to be > > successfully deployed, particularly protocol extensions. > > > A good example of an extension that will not need a MIB to be > > successfully deployed is the current soft-preemption draft. It adds 3 > > bits to two existing bitfields and defines the semantics. You could > > argue that later on a counter of the number of soft-preemptions vs > > hard preemptions could/should be added but that shouldn't be needed to > > get to PS. For DS, yes, keep the MIB requirement. > > we seem to be in agreement then--make MIBs optional for extensions > and require read-only. Yes. > >> Add the following: > >> > >> 4. Provide guidelines about what sort of details should be described > >> in a specification. > >> > >> There have been discussions recently about what sort of details > >> should be described for routing protocols. i.e., only bits on the > >> wire (message format only) vs including node-local decisions, > >> FSMs, timing, etc. > > > More than bits on the wire. > > > OTOH the BGP FSM exercise we just went through IMHO was excessive. > > Opinions vary :) I actually agree--sometimes we get too caught up in over specifying things. We're losing some of our creativity here, and pushing things into corners, it feels like. For instance, if someone else comes up with an fsm for bgp that's _much_ simpler, and still interoperates (a bgp peer can't tell the new fsm from the old), then why are specifying to this point, and stifling new things--just so we prevent people from making mistakes on it? Maybe things like this (the fsm) should be pulled from the standard, and made "informational," or "standard contingent," or something like that, so we have a place to say (again): "this is a really good idea, this is how some other people may have done it, but we won't hold to this part, as long as you interperate, and can prove to interoperate." In fact, no-one I know actually implements the bgp fsm the way it's outlined in the doc (at least the last one I read). > >> 5. Spell out what routing-specific details are expected in the > >> security section for new protocols, i.e., threat analysis and > >> authentication; and for extensions: changes to the set of possible > >> attacks and to the protocols security mechanisms. > > > Yes. Agreed. > > Above I've suggested that instead of making it harder to get a > > document to PS, make it harder to just get a document to PS and then > > do nothing for the next decade. A three year threshhold would affect > > a lot of existing PS documents and force some cleanup. I'm not sure > > what to call the downgrade. AS - abandoned standard? > > BTW, do we feel that we have people who are interested AND qualified > to do the clean-up? I think people would be interested, but it's a matter of time. The next rfc passed should specify, in the standards track, a 30 hour day, of which 6 hours are reserved for ietf work, and the remainder are for "normal living." :-) Russ -- riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sun Mar 16 16:11:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07782 for ; Sun, 16 Mar 2003 16:11:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLKnO24032; Sun, 16 Mar 2003 16:20:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FCs0O05652 for ; Sat, 15 Mar 2003 07:54:00 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15024 for ; Sat, 15 Mar 2003 07:38:05 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2FCe8Sc023313; Sat, 15 Mar 2003 07:40:08 -0500 (EST) Received: from russpc (rtp-vpn2-406.cisco.com [10.82.241.150]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA09401; Sat, 15 Mar 2003 07:40:07 -0500 (EST) From: Russ White Reply-To: Russ White To: Alex Zinin cc: Curtis Villamizar , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <53208083157.20030313175539@psg.com> Message-ID: References: <200303132111.QAA91882@workhorse.fictitious.org> <53208083157.20030313175539@psg.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 07:39:37 -0500 (Eastern Standard Time) > > It might even be worth not accepting a draft as a WG item > > until either at least one implementation exists, or there is strong > > consensus that the draft is within the charter and worth doing. > > This would be an over-kill, I think. Problems mentioned above apply. > Plus, we DO want vendors to come to the IETF early in the process while > they are flexible enough with their implementations for the IETF process > to be meaningful. In fact, what we are currently seeing is drafts coming before the ietf with no implementations. The primary reason for this is "tight money." A lot of people are now unwilling to simply code something to see if it works, then take it to the ietf, then recode it. The price you pay for bringing a new feature into a protocol is now doubled over those who just "follow along," and thus new ideas in protocols are discouraged--and participation in the process is discouraraged. So, we need to somehow be sensative to this fact in an industry that is coming into "maturity," whether or not we like it (feeling old yet?). The second reason I see this happen (and I've seen it several times now) is that someone comes up with an idea. It's not implemented, so they don't take it anyplace, they just sit on it, thinking about it. Then, suddenly, another idea is published which would compete with theirs, but they believe their idea is better, in some sense. So, the rush publish, with no implementation, to make certain both ideas that solve the same problem are considered. Again, we need some way to take this into consideration. Sometimes a draft will, in some way, spur your thinking on an alternate way of solving a problem.... Again, we need to have some way to take these sorts of things into account. :-) Russ -- riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sun Mar 16 16:11:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07828 for ; Sun, 16 Mar 2003 16:11:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GLRr825250 for routing-discussion-archive@odin.ietf.org; Sun, 16 Mar 2003 16:27:53 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GLKnO24032; Sun, 16 Mar 2003 16:20:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FCs0O05652 for ; Sat, 15 Mar 2003 07:54:00 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15024 for ; Sat, 15 Mar 2003 07:38:05 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2FCe8Sc023313; Sat, 15 Mar 2003 07:40:08 -0500 (EST) Received: from russpc (rtp-vpn2-406.cisco.com [10.82.241.150]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA09401; Sat, 15 Mar 2003 07:40:07 -0500 (EST) From: Russ White Reply-To: Russ White To: Alex Zinin cc: Curtis Villamizar , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <53208083157.20030313175539@psg.com> Message-ID: References: <200303132111.QAA91882@workhorse.fictitious.org> <53208083157.20030313175539@psg.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Mar 2003 07:39:37 -0500 (Eastern Standard Time) > > It might even be worth not accepting a draft as a WG item > > until either at least one implementation exists, or there is strong > > consensus that the draft is within the charter and worth doing. > > This would be an over-kill, I think. Problems mentioned above apply. > Plus, we DO want vendors to come to the IETF early in the process while > they are flexible enough with their implementations for the IETF process > to be meaningful. In fact, what we are currently seeing is drafts coming before the ietf with no implementations. The primary reason for this is "tight money." A lot of people are now unwilling to simply code something to see if it works, then take it to the ietf, then recode it. The price you pay for bringing a new feature into a protocol is now doubled over those who just "follow along," and thus new ideas in protocols are discouraged--and participation in the process is discouraraged. So, we need to somehow be sensative to this fact in an industry that is coming into "maturity," whether or not we like it (feeling old yet?). The second reason I see this happen (and I've seen it several times now) is that someone comes up with an idea. It's not implemented, so they don't take it anyplace, they just sit on it, thinking about it. Then, suddenly, another idea is published which would compete with theirs, but they believe their idea is better, in some sense. So, the rush publish, with no implementation, to make certain both ideas that solve the same problem are considered. Again, we need some way to take this into consideration. Sometimes a draft will, in some way, spur your thinking on an alternate way of solving a problem.... Again, we need to have some way to take these sorts of things into account. :-) Russ -- riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 17 10:48:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17832 for ; Mon, 17 Mar 2003 10:48:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFuGO09437; Mon, 17 Mar 2003 10:56:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4MXO18069 for ; Sun, 16 Mar 2003 23:22:33 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18418 for ; Sun, 16 Mar 2003 23:05:50 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2H47YvD005107; Sun, 16 Mar 2003 23:07:34 -0500 (EST) Received: from wl-132-187.wireless.ietf56.ietf.org (sjc-vpn4-1037.cisco.com [10.21.84.12]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA19016; Sun, 16 Mar 2003 23:07:34 -0500 (EST) From: Russ White X-X-Sender: ruwhite@wl-132-187.wireless.ietf56.ietf.org Reply-To: Russ White To: Alex Zinin cc: Curtis Villamizar , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <5873178965.20030315125109@psg.com> Message-ID: References: <200303151645.LAA07681@workhorse.fictitious.org> <5873178965.20030315125109@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 16 Mar 2003 23:07:37 -0500 (EST) > > Pushing something all the way to PS before implementing it at all is > > just a bad idea. Doing this makes the decision of the committee of > > professional standards body attendees almost final. > > ... > > I'm not suggesting we don't discuss unimplemented idea, just that we > > don't standardize unimplemented ideas. > > ... > > No implementation and incomplete consensus, no standard. That way > > there are fewer arguments. > > This is a little different from what you suggested about the drafts, but > we seem to be converging: PS should require implementations (in fact it > does already), but I wouldn't like us to require this for internet-draft > before they become WG items. Right--but should we have something other than "standard," "best common practice," and "experimental" to choose from on the menu? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 17 10:49:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17861 for ; Mon, 17 Mar 2003 10:49:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HG6AM09958 for routing-discussion-archive@odin.ietf.org; Mon, 17 Mar 2003 11:06:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFuGO09437; Mon, 17 Mar 2003 10:56:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4MXO18069 for ; Sun, 16 Mar 2003 23:22:33 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18418 for ; Sun, 16 Mar 2003 23:05:50 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2H47YvD005107; Sun, 16 Mar 2003 23:07:34 -0500 (EST) Received: from wl-132-187.wireless.ietf56.ietf.org (sjc-vpn4-1037.cisco.com [10.21.84.12]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id XAA19016; Sun, 16 Mar 2003 23:07:34 -0500 (EST) From: Russ White X-X-Sender: ruwhite@wl-132-187.wireless.ietf56.ietf.org Reply-To: Russ White To: Alex Zinin cc: Curtis Villamizar , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <5873178965.20030315125109@psg.com> Message-ID: References: <200303151645.LAA07681@workhorse.fictitious.org> <5873178965.20030315125109@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 16 Mar 2003 23:07:37 -0500 (EST) > > Pushing something all the way to PS before implementing it at all is > > just a bad idea. Doing this makes the decision of the committee of > > professional standards body attendees almost final. > > ... > > I'm not suggesting we don't discuss unimplemented idea, just that we > > don't standardize unimplemented ideas. > > ... > > No implementation and incomplete consensus, no standard. That way > > there are fewer arguments. > > This is a little different from what you suggested about the drafts, but > we seem to be converging: PS should require implementations (in fact it > does already), but I wouldn't like us to require this for internet-draft > before they become WG items. Right--but should we have something other than "standard," "best common practice," and "experimental" to choose from on the menu? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 17 11:10:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18355 for ; Mon, 17 Mar 2003 11:10:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGHmO11209; Mon, 17 Mar 2003 11:17:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGBcO10931 for ; Mon, 17 Mar 2003 11:11:38 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17966 for ; Mon, 17 Mar 2003 10:54:40 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA30742; Mon, 17 Mar 2003 10:54:20 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303171554.KAA30742@workhorse.fictitious.org> To: Russ White cc: Alex Zinin , Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Sun, 16 Mar 2003 23:07:37 EST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 10:54:20 -0500 In message , Russ White writes: > > > > Pushing something all the way to PS before implementing it at all is > > > just a bad idea. Doing this makes the decision of the committee of > > > professional standards body attendees almost final. > > > > ... > > > I'm not suggesting we don't discuss unimplemented idea, just that we > > > don't standardize unimplemented ideas. > > > > ... > > > No implementation and incomplete consensus, no standard. That way > > > there are fewer arguments. > > > > This is a little different from what you suggested about the drafts, but > > we seem to be converging: PS should require implementations (in fact it > > does already), but I wouldn't like us to require this for internet-draft > > before they become WG items. > > Right--but should we have something other than "standard," "best common > practice," and "experimental" to choose from on the menu? > > :-) > > Russ I suggested "best future practice" for operational issues in which there was a very clear consensus that something should be done but deployment was moving slowly. Operational guidelines for security come to mind. For example, no service which can change the configuration of routers or expose information critical to security should be unencrypted. In the mid-90s there was widespread agreement on this but a widely deployed router lacked encryption, so it was not "common practice". There have been other cases in which operators advocate a change in their own practices and widely agree that a particular change would be beneficial but are unable to move forward with the change for some reason (lacking protocol support, needing cooperation of others which has not materialized, etc). An example would be a any solution from the ptomaine WG (though I don't know that one was every finalized, though the problem was stated). I don't think we should have a "neat ideas that no one has really tried" category. That would overlap experimental. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 17 11:10:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18394 for ; Mon, 17 Mar 2003 11:10:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HGRLv11681 for routing-discussion-archive@odin.ietf.org; Mon, 17 Mar 2003 11:27:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGHmO11209; Mon, 17 Mar 2003 11:17:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGBcO10931 for ; Mon, 17 Mar 2003 11:11:38 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17966 for ; Mon, 17 Mar 2003 10:54:40 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA30742; Mon, 17 Mar 2003 10:54:20 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303171554.KAA30742@workhorse.fictitious.org> To: Russ White cc: Alex Zinin , Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Sun, 16 Mar 2003 23:07:37 EST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 10:54:20 -0500 In message , Russ White writes: > > > > Pushing something all the way to PS before implementing it at all is > > > just a bad idea. Doing this makes the decision of the committee of > > > professional standards body attendees almost final. > > > > ... > > > I'm not suggesting we don't discuss unimplemented idea, just that we > > > don't standardize unimplemented ideas. > > > > ... > > > No implementation and incomplete consensus, no standard. That way > > > there are fewer arguments. > > > > This is a little different from what you suggested about the drafts, but > > we seem to be converging: PS should require implementations (in fact it > > does already), but I wouldn't like us to require this for internet-draft > > before they become WG items. > > Right--but should we have something other than "standard," "best common > practice," and "experimental" to choose from on the menu? > > :-) > > Russ I suggested "best future practice" for operational issues in which there was a very clear consensus that something should be done but deployment was moving slowly. Operational guidelines for security come to mind. For example, no service which can change the configuration of routers or expose information critical to security should be unencrypted. In the mid-90s there was widespread agreement on this but a widely deployed router lacked encryption, so it was not "common practice". There have been other cases in which operators advocate a change in their own practices and widely agree that a particular change would be beneficial but are unable to move forward with the change for some reason (lacking protocol support, needing cooperation of others which has not materialized, etc). An example would be a any solution from the ptomaine WG (though I don't know that one was every finalized, though the problem was stated). I don't think we should have a "neat ideas that no one has really tried" category. That would overlap experimental. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 17 12:18:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21112 for ; Mon, 17 Mar 2003 12:18:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHRSO16669; Mon, 17 Mar 2003 12:27:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHMqO16437 for ; Mon, 17 Mar 2003 12:22:52 -0500 Received: from web14806.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20663 for ; Mon, 17 Mar 2003 12:05:53 -0500 (EST) Message-ID: <20030317170805.95521.qmail@web14806.mail.yahoo.com> Received: from [65.213.193.49] by web14806.mail.yahoo.com via HTTP; Mon, 17 Mar 2003 09:08:05 PST From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Papers To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1981000835-1047920885=:94881" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 09:08:05 -0800 (PST) --0-1981000835-1047920885=:94881 Content-Type: text/plain; charset=us-ascii Dear Colleagues: Our sincere apologies if you receive multiple copies of this announcement. CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS Internetworking 2003 June 22-24, 2003 San Jose, California In technical cooperation with IEEE, IFIP, and ACM (Pending) Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE , or Daniel Awduche . --0-1981000835-1047920885=:94881 Content-Type: text/html; charset=us-ascii

Dear Colleagues:

Our sincere apologies if you receive multiple copies of this announcement.

     CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS

                   Internetworking 2003
                      June 22-24, 2003
                   San Jose, California
      In technical cooperation with IEEE, IFIP, and ACM (Pending)


Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots


The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE <gagnaire@enst.fr>, or Daniel Awduche <Awduche@awduche.com>.

--0-1981000835-1047920885=:94881-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 17 12:19:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21179 for ; Mon, 17 Mar 2003 12:19:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HHa9H17318 for routing-discussion-archive@odin.ietf.org; Mon, 17 Mar 2003 12:36:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHRSO16669; Mon, 17 Mar 2003 12:27:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHMqO16437 for ; Mon, 17 Mar 2003 12:22:52 -0500 Received: from web14806.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20663 for ; Mon, 17 Mar 2003 12:05:53 -0500 (EST) Message-ID: <20030317170805.95521.qmail@web14806.mail.yahoo.com> Received: from [65.213.193.49] by web14806.mail.yahoo.com via HTTP; Mon, 17 Mar 2003 09:08:05 PST From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Papers To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1981000835-1047920885=:94881" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 09:08:05 -0800 (PST) --0-1981000835-1047920885=:94881 Content-Type: text/plain; charset=us-ascii Dear Colleagues: Our sincere apologies if you receive multiple copies of this announcement. CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS Internetworking 2003 June 22-24, 2003 San Jose, California In technical cooperation with IEEE, IFIP, and ACM (Pending) Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE , or Daniel Awduche . --0-1981000835-1047920885=:94881 Content-Type: text/html; charset=us-ascii

Dear Colleagues:

Our sincere apologies if you receive multiple copies of this announcement.

     CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS

                   Internetworking 2003
                      June 22-24, 2003
                   San Jose, California
      In technical cooperation with IEEE, IFIP, and ACM (Pending)


Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots


The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE <gagnaire@enst.fr>, or Daniel Awduche <Awduche@awduche.com>.

--0-1981000835-1047920885=:94881-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 17 16:13:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01499 for ; Mon, 17 Mar 2003 16:13:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HLJTO02613; Mon, 17 Mar 2003 16:19:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HLEmO02413 for ; Mon, 17 Mar 2003 16:14:48 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00932 for ; Mon, 17 Mar 2003 15:57:43 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18v1hO-000G3O-00; Mon, 17 Mar 2003 12:59:10 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1522631904.20030317125854@psg.com> To: Curtis Villamizar CC: Russ White , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <200303171554.KAA30742@workhorse.fictitious.org> References: <200303171554.KAA30742@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 12:58:54 -0800 Content-Transfer-Encoding: 7bit Curtis, RFC2026: > 5. BEST CURRENT PRACTICE (BCP) RFCs > ... is a vehicle by which the IETF > community can define and ratify the community's best current thinking > on a statement of principle or on what is believed to be the best way > to perform some operations or IETF process function. note the "best current thinking on..." Also note that we're using BCP to describe the IETF process, including the changes to it, which means that what's described doesn't necessarily have to be deployed/practiced before it becomes a BCP, best current _thinking_ on the problem is enough. -- Alex Monday, March 17, 2003, 7:54:20 AM, Curtis Villamizar wrote: > In message >, Russ White writes: >> >> > > Pushing something all the way to PS before implementing it at all is >> > > just a bad idea. Doing this makes the decision of the committee of >> > > professional standards body attendees almost final. >> > >> > ... >> > > I'm not suggesting we don't discuss unimplemented idea, just that we >> > > don't standardize unimplemented ideas. >> > >> > ... >> > > No implementation and incomplete consensus, no standard. That way >> > > there are fewer arguments. >> > >> > This is a little different from what you suggested about the drafts, but >> > we seem to be converging: PS should require implementations (in fact it >> > does already), but I wouldn't like us to require this for internet-draft >> > before they become WG items. >> >> Right--but should we have something other than "standard," "best common >> practice," and "experimental" to choose from on the menu? >> >> :-) >> >> Russ > I suggested "best future practice" for operational issues in which > there was a very clear consensus that something should be done but > deployment was moving slowly. Operational guidelines for security > come to mind. For example, no service which can change the > configuration of routers or expose information critical to security > should be unencrypted. In the mid-90s there was widespread agreement > on this but a widely deployed router lacked encryption, so it was not > "common practice". There have been other cases in which operators > advocate a change in their own practices and widely agree that a > particular change would be beneficial but are unable to move forward > with the change for some reason (lacking protocol support, needing > cooperation of others which has not materialized, etc). An example > would be a any solution from the ptomaine WG (though I don't know that > one was every finalized, though the problem was stated). > I don't think we should have a "neat ideas that no one has really > tried" category. That would overlap experimental. > Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 17 16:14:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01521 for ; Mon, 17 Mar 2003 16:14:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HLUt503285 for routing-discussion-archive@odin.ietf.org; Mon, 17 Mar 2003 16:30:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HLJTO02613; Mon, 17 Mar 2003 16:19:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HLEmO02413 for ; Mon, 17 Mar 2003 16:14:48 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00932 for ; Mon, 17 Mar 2003 15:57:43 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18v1hO-000G3O-00; Mon, 17 Mar 2003 12:59:10 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1522631904.20030317125854@psg.com> To: Curtis Villamizar CC: Russ White , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 In-Reply-To: <200303171554.KAA30742@workhorse.fictitious.org> References: <200303171554.KAA30742@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 12:58:54 -0800 Content-Transfer-Encoding: 7bit Curtis, RFC2026: > 5. BEST CURRENT PRACTICE (BCP) RFCs > ... is a vehicle by which the IETF > community can define and ratify the community's best current thinking > on a statement of principle or on what is believed to be the best way > to perform some operations or IETF process function. note the "best current thinking on..." Also note that we're using BCP to describe the IETF process, including the changes to it, which means that what's described doesn't necessarily have to be deployed/practiced before it becomes a BCP, best current _thinking_ on the problem is enough. -- Alex Monday, March 17, 2003, 7:54:20 AM, Curtis Villamizar wrote: > In message >, Russ White writes: >> >> > > Pushing something all the way to PS before implementing it at all is >> > > just a bad idea. Doing this makes the decision of the committee of >> > > professional standards body attendees almost final. >> > >> > ... >> > > I'm not suggesting we don't discuss unimplemented idea, just that we >> > > don't standardize unimplemented ideas. >> > >> > ... >> > > No implementation and incomplete consensus, no standard. That way >> > > there are fewer arguments. >> > >> > This is a little different from what you suggested about the drafts, but >> > we seem to be converging: PS should require implementations (in fact it >> > does already), but I wouldn't like us to require this for internet-draft >> > before they become WG items. >> >> Right--but should we have something other than "standard," "best common >> practice," and "experimental" to choose from on the menu? >> >> :-) >> >> Russ > I suggested "best future practice" for operational issues in which > there was a very clear consensus that something should be done but > deployment was moving slowly. Operational guidelines for security > come to mind. For example, no service which can change the > configuration of routers or expose information critical to security > should be unencrypted. In the mid-90s there was widespread agreement > on this but a widely deployed router lacked encryption, so it was not > "common practice". There have been other cases in which operators > advocate a change in their own practices and widely agree that a > particular change would be beneficial but are unable to move forward > with the change for some reason (lacking protocol support, needing > cooperation of others which has not materialized, etc). An example > would be a any solution from the ptomaine WG (though I don't know that > one was every finalized, though the problem was stated). > I don't think we should have a "neat ideas that no one has really > tried" category. That would overlap experimental. > Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 18 00:05:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18252 for ; Tue, 18 Mar 2003 00:05:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I5AvO05687; Tue, 18 Mar 2003 00:10:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I55cO04718 for ; Tue, 18 Mar 2003 00:05:38 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17723 for ; Mon, 17 Mar 2003 23:48:25 -0500 (EST) Received: by mail-blue.research.att.com (Postfix, from userid 612) id C408BB7C8A; Mon, 17 Mar 2003 23:51:05 -0500 (EST) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mail-blue.research.att.com (Postfix) with ESMTP id 82234B7C89 for ; Mon, 17 Mar 2003 23:51:05 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.12.8) with ESMTP id h2I4oBBh001730 for ; Mon, 17 Mar 2003 23:50:11 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h2I4obH25744; Mon, 17 Mar 2003 20:50:37 -0800 (PST) Message-Id: <200303180450.h2I4obH25744@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: routing-discussion@ietf.org Subject: Correct URL for Liasion statement Versions: dmail (solaris) 2.5a/makemail 2.9d X-Spam-Status: No, hits=-106.6 required=5.0 tests=BAYES_01,USER_IN_WHITELIST version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 20:50:37 -0800 The correct URL from the Q.14/15 liasion discussed at the Routing Area meeting (http://www.ietf.org/IESG/LIAISON/ls15-39-1.htm) is: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html Note: "otxchange", not "otxchage". Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 18 00:06:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18303 for ; Tue, 18 Mar 2003 00:06:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I5MvT06244 for routing-discussion-archive@odin.ietf.org; Tue, 18 Mar 2003 00:22:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I5AvO05687; Tue, 18 Mar 2003 00:10:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I55cO04718 for ; Tue, 18 Mar 2003 00:05:38 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17723 for ; Mon, 17 Mar 2003 23:48:25 -0500 (EST) Received: by mail-blue.research.att.com (Postfix, from userid 612) id C408BB7C8A; Mon, 17 Mar 2003 23:51:05 -0500 (EST) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mail-blue.research.att.com (Postfix) with ESMTP id 82234B7C89 for ; Mon, 17 Mar 2003 23:51:05 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.12.8) with ESMTP id h2I4oBBh001730 for ; Mon, 17 Mar 2003 23:50:11 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h2I4obH25744; Mon, 17 Mar 2003 20:50:37 -0800 (PST) Message-Id: <200303180450.h2I4obH25744@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: routing-discussion@ietf.org Subject: Correct URL for Liasion statement Versions: dmail (solaris) 2.5a/makemail 2.9d X-Spam-Status: No, hits=-106.6 required=5.0 tests=BAYES_01,USER_IN_WHITELIST version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Mar 2003 20:50:37 -0800 The correct URL from the Q.14/15 liasion discussed at the Routing Area meeting (http://www.ietf.org/IESG/LIAISON/ls15-39-1.htm) is: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html Note: "otxchange", not "otxchage". Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 18 11:30:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16556 for ; Tue, 18 Mar 2003 11:30:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IGcaO25915; Tue, 18 Mar 2003 11:38:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IGWBO24910 for ; Tue, 18 Mar 2003 11:32:11 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15514 for ; Tue, 18 Mar 2003 11:14:41 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA49060; Tue, 18 Mar 2003 11:15:00 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303181615.LAA49060@workhorse.fictitious.org> To: Bill Fenner cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Correct URL for Liasion statement In-reply-to: Your message of "Mon, 17 Mar 2003 20:50:37 PST." <200303180450.h2I4obH25744@windsor.research.att.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 11:15:00 -0500 In message <200303180450.h2I4obH25744@windsor.research.att.com>, Bill Fenner wr ites: > > The correct URL from the Q.14/15 liasion discussed at the > Routing Area meeting (http://www.ietf.org/IESG/LIAISON/ls15-39-1.htm) > is: > > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS > /index.html > > Note: "otxchange", not "otxchage". > > Bill Bill, I'm still only able to read the index and not any of the statements to the WG. Could we please ask the ITU to either make their liason statements completely public (no password protection at all and no restrictions on redistribution) or we won't honor them. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 18 11:31:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16600 for ; Tue, 18 Mar 2003 11:31:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IGm9i26674 for routing-discussion-archive@odin.ietf.org; Tue, 18 Mar 2003 11:48:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IGcaO25915; Tue, 18 Mar 2003 11:38:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IGWBO24910 for ; Tue, 18 Mar 2003 11:32:11 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15514 for ; Tue, 18 Mar 2003 11:14:41 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA49060; Tue, 18 Mar 2003 11:15:00 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303181615.LAA49060@workhorse.fictitious.org> To: Bill Fenner cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Correct URL for Liasion statement In-reply-to: Your message of "Mon, 17 Mar 2003 20:50:37 PST." <200303180450.h2I4obH25744@windsor.research.att.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 11:15:00 -0500 In message <200303180450.h2I4obH25744@windsor.research.att.com>, Bill Fenner wr ites: > > The correct URL from the Q.14/15 liasion discussed at the > Routing Area meeting (http://www.ietf.org/IESG/LIAISON/ls15-39-1.htm) > is: > > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS > /index.html > > Note: "otxchange", not "otxchage". > > Bill Bill, I'm still only able to read the index and not any of the statements to the WG. Could we please ask the ITU to either make their liason statements completely public (no password protection at all and no restrictions on redistribution) or we won't honor them. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 18 14:11:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24706 for ; Tue, 18 Mar 2003 14:11:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJBdO08367; Tue, 18 Mar 2003 14:11:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJ63O07356 for ; Tue, 18 Mar 2003 14:06:03 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23580 for ; Tue, 18 Mar 2003 13:48:31 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2IIoR9l034811; Tue, 18 Mar 2003 13:50:27 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2IIoNNp034804; Tue, 18 Mar 2003 13:50:23 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2IIoIE01906; Tue, 18 Mar 2003 13:50:18 -0500 (EST) From: Jeffrey Haas To: Curtis Villamizar Cc: routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 Message-ID: <20030318135017.A1768@nexthop.com> References: <200303151541.KAA07354@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200303151541.KAA07354@workhorse.fictitious.org>; from curtis@fictitious.org on Sat, Mar 15, 2003 at 10:41:39AM -0500 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 13:50:17 -0500 Curtis, On Sat, Mar 15, 2003 at 10:41:39AM -0500, Curtis Villamizar wrote: > The plain fact in this case is that in a decade of practice virtually > no problems where due to the state machine except with brand spanking > new and quite naive implementations, even thought the FSM was loosely > specified and perhaps not even entirely correct. [...] > The WG's time would have been much > better spent discussing these *relevant* issues rather than nailing > down the exact wording of the FSM. > > In this case, a limited number of people have 5 or 10 years (or more) > of experience with BGP and with numerous BGP implementations and are > aware of the history of operation problems but have to think to > remember where in the spec the ambiguities or mistakes were in the > cases where the spec lead to problems. The above excerpt is somewhat out of context, but really brings up the point I wish to make. My original motivation for participation in the IETF was the fact that I was now working on the BGP protocol and the specification WAS NOT SPECIFIC. In some cases it was outright wrong. I realize IETF RFC's are not specifications to the same level that ISO specifications are (thank the powers that be). However, one should be able to proceed from the document to an interoperable implementation without needing to delve into necromancy much less attempting to reverse engineer what another implmentation actually does. This is *especially* important when an almost-correct implementation can break our unfortunately fragile Internet. In some cases, it was obvious in the document that there were Things That Should Not Be Done. When there was inadequate explanation for it, people would ask "why are we doing this?" proceed to do it and discover things painfully often too late. Hard won wisdom should be embedded somewhere. That wisdom should not die off with the passing of people from the working group. What we have found, IMO, from the FSM exercise is that it was pretty easy to describe in a very *general* way how the FSM should look and let most people get it pretty close to right and still interoperate. However, if you leave the vagaries in, you require people to do that "extra work" to get things correct. The sheer size of the current FSM section shows what a lot of that "extra work" would look like in someone's implementation. The fact that the implementations I'm familiar with don't actually treat the FSM as an actual state machine in most cases, much less a deterministic one, is beside the fact. It lets a new implementation interoperate without resorting to reverse engineering - or at least that is the goal. If we could have done the same job by getting rid of the FSM and still make the powers that be happy, that would have been good. However, the powers that be seemed to have demanded a FSM. I'm not going to argue that we got what we really wanted. The BGP-4 FSM section is huge, somewhat hard to follow, but at least tries to reflect the specifics that were glossed over for a long time. I place no value judgement on this or your own (well known!) opinion on it. I will summarize my point: Don't leave things vague in the spec. It will confuse those who try to implement things in the future and the cleanup is almost more trouble than it is really worth. -- Jeff _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 18 14:12:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24815 for ; Tue, 18 Mar 2003 14:12:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJTM709645 for routing-discussion-archive@odin.ietf.org; Tue, 18 Mar 2003 14:29:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJBdO08367; Tue, 18 Mar 2003 14:11:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJ63O07356 for ; Tue, 18 Mar 2003 14:06:03 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23580 for ; Tue, 18 Mar 2003 13:48:31 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2IIoR9l034811; Tue, 18 Mar 2003 13:50:27 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2IIoNNp034804; Tue, 18 Mar 2003 13:50:23 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2IIoIE01906; Tue, 18 Mar 2003 13:50:18 -0500 (EST) From: Jeffrey Haas To: Curtis Villamizar Cc: routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 Message-ID: <20030318135017.A1768@nexthop.com> References: <200303151541.KAA07354@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200303151541.KAA07354@workhorse.fictitious.org>; from curtis@fictitious.org on Sat, Mar 15, 2003 at 10:41:39AM -0500 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 13:50:17 -0500 Curtis, On Sat, Mar 15, 2003 at 10:41:39AM -0500, Curtis Villamizar wrote: > The plain fact in this case is that in a decade of practice virtually > no problems where due to the state machine except with brand spanking > new and quite naive implementations, even thought the FSM was loosely > specified and perhaps not even entirely correct. [...] > The WG's time would have been much > better spent discussing these *relevant* issues rather than nailing > down the exact wording of the FSM. > > In this case, a limited number of people have 5 or 10 years (or more) > of experience with BGP and with numerous BGP implementations and are > aware of the history of operation problems but have to think to > remember where in the spec the ambiguities or mistakes were in the > cases where the spec lead to problems. The above excerpt is somewhat out of context, but really brings up the point I wish to make. My original motivation for participation in the IETF was the fact that I was now working on the BGP protocol and the specification WAS NOT SPECIFIC. In some cases it was outright wrong. I realize IETF RFC's are not specifications to the same level that ISO specifications are (thank the powers that be). However, one should be able to proceed from the document to an interoperable implementation without needing to delve into necromancy much less attempting to reverse engineer what another implmentation actually does. This is *especially* important when an almost-correct implementation can break our unfortunately fragile Internet. In some cases, it was obvious in the document that there were Things That Should Not Be Done. When there was inadequate explanation for it, people would ask "why are we doing this?" proceed to do it and discover things painfully often too late. Hard won wisdom should be embedded somewhere. That wisdom should not die off with the passing of people from the working group. What we have found, IMO, from the FSM exercise is that it was pretty easy to describe in a very *general* way how the FSM should look and let most people get it pretty close to right and still interoperate. However, if you leave the vagaries in, you require people to do that "extra work" to get things correct. The sheer size of the current FSM section shows what a lot of that "extra work" would look like in someone's implementation. The fact that the implementations I'm familiar with don't actually treat the FSM as an actual state machine in most cases, much less a deterministic one, is beside the fact. It lets a new implementation interoperate without resorting to reverse engineering - or at least that is the goal. If we could have done the same job by getting rid of the FSM and still make the powers that be happy, that would have been good. However, the powers that be seemed to have demanded a FSM. I'm not going to argue that we got what we really wanted. The BGP-4 FSM section is huge, somewhat hard to follow, but at least tries to reflect the specifics that were glossed over for a long time. I place no value judgement on this or your own (well known!) opinion on it. I will summarize my point: Don't leave things vague in the spec. It will confuse those who try to implement things in the future and the cleanup is almost more trouble than it is really worth. -- Jeff _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 18 14:29:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25452 for ; Tue, 18 Mar 2003 14:29:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJcIO10963; Tue, 18 Mar 2003 14:38:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJVHO09848 for ; Tue, 18 Mar 2003 14:31:17 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24900 for ; Tue, 18 Mar 2003 14:13:44 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA51765; Tue, 18 Mar 2003 14:13:54 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303181913.OAA51765@workhorse.fictitious.org> To: Jeffrey Haas cc: Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Tue, 18 Mar 2003 13:50:17 EST." <20030318135017.A1768@nexthop.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 14:13:54 -0500 In message <20030318135017.A1768@nexthop.com>, Jeffrey Haas writes: > Curtis, > > On Sat, Mar 15, 2003 at 10:41:39AM -0500, Curtis Villamizar wrote: > > The plain fact in this case is that in a decade of practice virtually > > no problems where due to the state machine except with brand spanking > > new and quite naive implementations, even thought the FSM was loosely > > specified and perhaps not even entirely correct. > > [...] > > > The WG's time would have been much > > better spent discussing these *relevant* issues rather than nailing > > down the exact wording of the FSM. > > > > In this case, a limited number of people have 5 or 10 years (or more) > > of experience with BGP and with numerous BGP implementations and are > > aware of the history of operation problems but have to think to > > remember where in the spec the ambiguities or mistakes were in the > > cases where the spec lead to problems. > > The above excerpt is somewhat out of context, but really brings up > the point I wish to make. > > My original motivation for participation in the IETF was the fact > that I was now working on the BGP protocol and the specification > WAS NOT SPECIFIC. In some cases it was outright wrong. > > I realize IETF RFC's are not specifications to the same level that > ISO specifications are (thank the powers that be). However, one should > be able to proceed from the document to an interoperable implementation > without needing to delve into necromancy much less attempting to > reverse engineer what another implmentation actually does. This is > *especially* important when an almost-correct implementation can > break our unfortunately fragile Internet. > > In some cases, it was obvious in the document that there were Things > That Should Not Be Done. When there was inadequate explanation for it, > people would ask "why are we doing this?" proceed to do it and discover > things painfully often too late. Hard won wisdom should be embedded > somewhere. That wisdom should not die off with the passing of people > from the working group. > > What we have found, IMO, from the FSM exercise is that it was pretty easy > to describe in a very *general* way how the FSM should look and let > most people get it pretty close to right and still interoperate. However, > if you leave the vagaries in, you require people to do that "extra work" > to get things correct. The sheer size of the current FSM section > shows what a lot of that "extra work" would look like in someone's > implementation. > > The fact that the implementations I'm familiar with don't actually treat > the FSM as an actual state machine in most cases, much less a deterministic > one, is beside the fact. It lets a new implementation interoperate > without resorting to reverse engineering - or at least that is the goal. > > If we could have done the same job by getting rid of the FSM and > still make the powers that be happy, that would have been good. > However, the powers that be seemed to have demanded a FSM. > > I'm not going to argue that we got what we really wanted. The BGP-4 > FSM section is huge, somewhat hard to follow, but at least tries to > reflect the specifics that were glossed over for a long time. I place > no value judgement on this or your own (well known!) opinion on it. > I will summarize my point: > > Don't leave things vague in the spec. It will confuse those who try to > implement things in the future and the cleanup is almost more trouble > than it is really worth. > > -- Jeff Jeff, I agree that keeping things wrong or vague is not good. OTOH, the route decision is actually where you did have to do reverse engineering to determine that the spec was wrong in subtle ways that could lead to route loops, not the state machine. I've never advocated leaving the spec as is, in fact I insisted that it not go to FS as is 2-3 years ago when IDR considered it for FS. I pushed to get the problem areas fixed before advancing. I just never viewed the FSM as being as important since having dealt with a number of independent implementations, this is not where they had trouble. Now that the FSM is in good shape that exercise is behind us (I hope). Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 18 14:30:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25573 for ; Tue, 18 Mar 2003 14:30:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJljB11801 for routing-discussion-archive@odin.ietf.org; Tue, 18 Mar 2003 14:47:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJcIO10963; Tue, 18 Mar 2003 14:38:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJVHO09848 for ; Tue, 18 Mar 2003 14:31:17 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24900 for ; Tue, 18 Mar 2003 14:13:44 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA51765; Tue, 18 Mar 2003 14:13:54 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303181913.OAA51765@workhorse.fictitious.org> To: Jeffrey Haas cc: Curtis Villamizar , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: For discussion: revising RFC1264 In-reply-to: Your message of "Tue, 18 Mar 2003 13:50:17 EST." <20030318135017.A1768@nexthop.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Mar 2003 14:13:54 -0500 In message <20030318135017.A1768@nexthop.com>, Jeffrey Haas writes: > Curtis, > > On Sat, Mar 15, 2003 at 10:41:39AM -0500, Curtis Villamizar wrote: > > The plain fact in this case is that in a decade of practice virtually > > no problems where due to the state machine except with brand spanking > > new and quite naive implementations, even thought the FSM was loosely > > specified and perhaps not even entirely correct. > > [...] > > > The WG's time would have been much > > better spent discussing these *relevant* issues rather than nailing > > down the exact wording of the FSM. > > > > In this case, a limited number of people have 5 or 10 years (or more) > > of experience with BGP and with numerous BGP implementations and are > > aware of the history of operation problems but have to think to > > remember where in the spec the ambiguities or mistakes were in the > > cases where the spec lead to problems. > > The above excerpt is somewhat out of context, but really brings up > the point I wish to make. > > My original motivation for participation in the IETF was the fact > that I was now working on the BGP protocol and the specification > WAS NOT SPECIFIC. In some cases it was outright wrong. > > I realize IETF RFC's are not specifications to the same level that > ISO specifications are (thank the powers that be). However, one should > be able to proceed from the document to an interoperable implementation > without needing to delve into necromancy much less attempting to > reverse engineer what another implmentation actually does. This is > *especially* important when an almost-correct implementation can > break our unfortunately fragile Internet. > > In some cases, it was obvious in the document that there were Things > That Should Not Be Done. When there was inadequate explanation for it, > people would ask "why are we doing this?" proceed to do it and discover > things painfully often too late. Hard won wisdom should be embedded > somewhere. That wisdom should not die off with the passing of people > from the working group. > > What we have found, IMO, from the FSM exercise is that it was pretty easy > to describe in a very *general* way how the FSM should look and let > most people get it pretty close to right and still interoperate. However, > if you leave the vagaries in, you require people to do that "extra work" > to get things correct. The sheer size of the current FSM section > shows what a lot of that "extra work" would look like in someone's > implementation. > > The fact that the implementations I'm familiar with don't actually treat > the FSM as an actual state machine in most cases, much less a deterministic > one, is beside the fact. It lets a new implementation interoperate > without resorting to reverse engineering - or at least that is the goal. > > If we could have done the same job by getting rid of the FSM and > still make the powers that be happy, that would have been good. > However, the powers that be seemed to have demanded a FSM. > > I'm not going to argue that we got what we really wanted. The BGP-4 > FSM section is huge, somewhat hard to follow, but at least tries to > reflect the specifics that were glossed over for a long time. I place > no value judgement on this or your own (well known!) opinion on it. > I will summarize my point: > > Don't leave things vague in the spec. It will confuse those who try to > implement things in the future and the cleanup is almost more trouble > than it is really worth. > > -- Jeff Jeff, I agree that keeping things wrong or vague is not good. OTOH, the route decision is actually where you did have to do reverse engineering to determine that the spec was wrong in subtle ways that could lead to route loops, not the state machine. I've never advocated leaving the spec as is, in fact I insisted that it not go to FS as is 2-3 years ago when IDR considered it for FS. I pushed to get the problem areas fixed before advancing. I just never viewed the FSM as being as important since having dealt with a number of independent implementations, this is not where they had trouble. Now that the FSM is in good shape that exercise is behind us (I hope). Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 20 15:16:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04349 for ; Thu, 20 Mar 2003 15:16:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KKRfO22073; Thu, 20 Mar 2003 15:27:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KKKBO21671 for ; Thu, 20 Mar 2003 15:20:11 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02416 for ; Thu, 20 Mar 2003 15:01:41 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18w6Ga-000H4s-00 for routing-discussion@ietf.org; Thu, 20 Mar 2003 12:03:56 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5149738590.20030320120334@psg.com> To: routing-discussion@ietf.org Subject: IPv6 site-locals... end of story... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 12:03:34 -0800 Content-Transfer-Encoding: 7bit Folks, Breaking news: I am told that the IPv6 WG with overwhelming consensus decided to deprecate site-local addresses. Appears that I left the room just 20 minutes earlier than I should have ;) More details coming. -- Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Mar 20 15:17:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04452 for ; Thu, 20 Mar 2003 15:17:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KKZBG22509 for routing-discussion-archive@odin.ietf.org; Thu, 20 Mar 2003 15:35:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KKRfO22073; Thu, 20 Mar 2003 15:27:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KKKBO21671 for ; Thu, 20 Mar 2003 15:20:11 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02416 for ; Thu, 20 Mar 2003 15:01:41 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18w6Ga-000H4s-00 for routing-discussion@ietf.org; Thu, 20 Mar 2003 12:03:56 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5149738590.20030320120334@psg.com> To: routing-discussion@ietf.org Subject: IPv6 site-locals... end of story... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 12:03:34 -0800 Content-Transfer-Encoding: 7bit Folks, Breaking news: I am told that the IPv6 WG with overwhelming consensus decided to deprecate site-local addresses. Appears that I left the room just 20 minutes earlier than I should have ;) More details coming. -- Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 20 16:59:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09698 for ; Thu, 20 Mar 2003 16:59:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KM5ZO32212; Thu, 20 Mar 2003 17:05:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KM2AO32022 for ; Thu, 20 Mar 2003 17:02:10 -0500 Received: from ms-smtp-01.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08835 for ; Thu, 20 Mar 2003 16:43:37 -0500 (EST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2KLfsgA029812; Thu, 20 Mar 2003 16:41:54 -0500 (EST) Received: from nc.rr.com ([130.129.130.143]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 20 Mar 2003 16:47:27 -0500 Message-ID: <3E7A3611.6080707@nc.rr.com> From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <5149738590.20030320120334@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 16:43:45 -0500 Content-Transfer-Encoding: 7bit Alex, Pending ratification on the mailing list... :) As I mentioned in the meeting, we still may have an issue with scoped multicast addresses. I will be trying to pull more data together on that in the next few weeks. Anyone who wants to help, let me know... Regards, Brian Alex Zinin wrote: > Folks, > > Breaking news: I am told that the IPv6 WG with overwhelming > consensus decided to deprecate site-local addresses. Appears > that I left the room just 20 minutes earlier than I should > have ;) More details coming. > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Mar 20 17:00:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09742 for ; Thu, 20 Mar 2003 17:00:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KMI5Q01119 for routing-discussion-archive@odin.ietf.org; Thu, 20 Mar 2003 17:18:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KM5ZO32212; Thu, 20 Mar 2003 17:05:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KM2AO32022 for ; Thu, 20 Mar 2003 17:02:10 -0500 Received: from ms-smtp-01.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08835 for ; Thu, 20 Mar 2003 16:43:37 -0500 (EST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2KLfsgA029812; Thu, 20 Mar 2003 16:41:54 -0500 (EST) Received: from nc.rr.com ([130.129.130.143]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 20 Mar 2003 16:47:27 -0500 Message-ID: <3E7A3611.6080707@nc.rr.com> From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <5149738590.20030320120334@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 16:43:45 -0500 Content-Transfer-Encoding: 7bit Alex, Pending ratification on the mailing list... :) As I mentioned in the meeting, we still may have an issue with scoped multicast addresses. I will be trying to pull more data together on that in the next few weeks. Anyone who wants to help, let me know... Regards, Brian Alex Zinin wrote: > Folks, > > Breaking news: I am told that the IPv6 WG with overwhelming > consensus decided to deprecate site-local addresses. Appears > that I left the room just 20 minutes earlier than I should > have ;) More details coming. > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 21 15:41:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26989 for ; Fri, 21 Mar 2003 15:41:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LKreO04399; Fri, 21 Mar 2003 15:53:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LKnCO04221 for ; Fri, 21 Mar 2003 15:49:12 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26608 for ; Fri, 21 Mar 2003 15:30:12 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2LKWPnW022891; Fri, 21 Mar 2003 15:32:25 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2LKWLNp022884; Fri, 21 Mar 2003 15:32:21 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2LKWGh09866; Fri, 21 Mar 2003 15:32:16 -0500 (EST) From: Jeffrey Haas To: Jing Shen , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 Message-ID: <20030321153216.B8704@nexthop.com> References: <200303151541.KAA07354@workhorse.fictitious.org> <9673000719.20030315124811@psg.com> <3E73E791.BBE94040@cad.zju.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3E73E791.BBE94040@cad.zju.edu.cn>; from jshen@cad.zju.edu.cn on Sun, Mar 16, 2003 at 10:55:13AM +0800 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 15:32:16 -0500 On Sun, Mar 16, 2003 at 10:55:13AM +0800, Jing Shen wrote: > I'm sorry if my question is out-of-the-interest. > > I want to know wether there is some guideline on making up > a FSM of a routing algo., sometimes I find it a little difficult > to understand FSM if text explanation is not well written. Ideally, it should represent a standard deterministic finite state machine. You should have states and events. The BGP FSM is a poor example of this for complicated reasons. The VRRP FSM is a pretty reasonable example of one well done. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Mar 21 15:42:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27010 for ; Fri, 21 Mar 2003 15:42:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LL0uB04775 for routing-discussion-archive@odin.ietf.org; Fri, 21 Mar 2003 16:00:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LKreO04399; Fri, 21 Mar 2003 15:53:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LKnCO04221 for ; Fri, 21 Mar 2003 15:49:12 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26608 for ; Fri, 21 Mar 2003 15:30:12 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2LKWPnW022891; Fri, 21 Mar 2003 15:32:25 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2LKWLNp022884; Fri, 21 Mar 2003 15:32:21 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2LKWGh09866; Fri, 21 Mar 2003 15:32:16 -0500 (EST) From: Jeffrey Haas To: Jing Shen , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 Message-ID: <20030321153216.B8704@nexthop.com> References: <200303151541.KAA07354@workhorse.fictitious.org> <9673000719.20030315124811@psg.com> <3E73E791.BBE94040@cad.zju.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3E73E791.BBE94040@cad.zju.edu.cn>; from jshen@cad.zju.edu.cn on Sun, Mar 16, 2003 at 10:55:13AM +0800 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 15:32:16 -0500 On Sun, Mar 16, 2003 at 10:55:13AM +0800, Jing Shen wrote: > I'm sorry if my question is out-of-the-interest. > > I want to know wether there is some guideline on making up > a FSM of a routing algo., sometimes I find it a little difficult > to understand FSM if text explanation is not well written. Ideally, it should represent a standard deterministic finite state machine. You should have states and events. The BGP FSM is a poor example of this for complicated reasons. The VRRP FSM is a pretty reasonable example of one well done. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 21 17:02:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28853 for ; Fri, 21 Mar 2003 17:02:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LMAaO11268; Fri, 21 Mar 2003 17:10:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LM77O10526 for ; Fri, 21 Mar 2003 17:07:07 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28638 for ; Fri, 21 Mar 2003 16:48:05 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2LLoIps025361; Fri, 21 Mar 2003 16:50:18 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2LLoFNp025354; Fri, 21 Mar 2003 16:50:15 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2LLoAS16290; Fri, 21 Mar 2003 16:50:10 -0500 (EST) From: Jeffrey Haas To: Tony Li Cc: Jing Shen , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 Message-ID: <20030321165010.C10329@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Fri, Mar 21, 2003 at 01:11:16PM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 16:50:10 -0500 On Fri, Mar 21, 2003 at 01:11:16PM -0800, Tony Li wrote: > | The BGP FSM is a poor example of this for complicated reasons. > > Agreed. This probably should have been described via some other > mechanism such as pseudo-code. Although I'd argue that pseudo-code can be hard to prove to completely cover all event cases. A FSM, by definition, doesn't have this problem. But I'm generalizing rather than talking about our specific icky case. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Mar 21 17:03:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28867 for ; Fri, 21 Mar 2003 17:03:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LMMGq11862 for routing-discussion-archive@odin.ietf.org; Fri, 21 Mar 2003 17:22:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LMAaO11268; Fri, 21 Mar 2003 17:10:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LM77O10526 for ; Fri, 21 Mar 2003 17:07:07 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28638 for ; Fri, 21 Mar 2003 16:48:05 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2LLoIps025361; Fri, 21 Mar 2003 16:50:18 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2LLoFNp025354; Fri, 21 Mar 2003 16:50:15 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2LLoAS16290; Fri, 21 Mar 2003 16:50:10 -0500 (EST) From: Jeffrey Haas To: Tony Li Cc: Jing Shen , routing-discussion@ietf.org Subject: Re: For discussion: revising RFC1264 Message-ID: <20030321165010.C10329@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Fri, Mar 21, 2003 at 01:11:16PM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 16:50:10 -0500 On Fri, Mar 21, 2003 at 01:11:16PM -0800, Tony Li wrote: > | The BGP FSM is a poor example of this for complicated reasons. > > Agreed. This probably should have been described via some other > mechanism such as pseudo-code. Although I'd argue that pseudo-code can be hard to prove to completely cover all event cases. A FSM, by definition, doesn't have this problem. But I'm generalizing rather than talking about our specific icky case. -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 21 17:41:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29775 for ; Fri, 21 Mar 2003 17:41:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LMnDO13719; Fri, 21 Mar 2003 17:49:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KL5hO25714 for ; Thu, 20 Mar 2003 16:05:43 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05682 for ; Thu, 20 Mar 2003 15:47:11 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 5FDE323C61; Thu, 20 Mar 2003 13:11:38 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2KKnQYB014285; Thu, 20 Mar 2003 12:49:26 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLvH1N/aVA57W5oRni8hXRAsl6UDwAAo9vg From: "Tony Li" To: "Alex Zinin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2KL5hO25715 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 12:49:26 -0800 Content-Transfer-Encoding: 8bit | Breaking news: I am told that the IPv6 WG with overwhelming | consensus decided to deprecate site-local addresses. Appears | that I left the room just 20 minutes earlier than I should | have ;) More details coming. There's not that much more to say. The chairs ARE going to poll the WG via the mailing list, but assuming that the statistics aren't too wildly different, it will be hard to overcome the 5:1 ratio that we saw today. In any case, IMHO, routing just got a bit easier today. ;-) Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Mar 21 17:42:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29820 for ; Fri, 21 Mar 2003 17:42:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LN1Ek14489 for routing-discussion-archive@odin.ietf.org; Fri, 21 Mar 2003 18:01:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LMnDO13719; Fri, 21 Mar 2003 17:49:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KL5hO25714 for ; Thu, 20 Mar 2003 16:05:43 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05682 for ; Thu, 20 Mar 2003 15:47:11 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 5FDE323C61; Thu, 20 Mar 2003 13:11:38 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2KKnQYB014285; Thu, 20 Mar 2003 12:49:26 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLvH1N/aVA57W5oRni8hXRAsl6UDwAAo9vg From: "Tony Li" To: "Alex Zinin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2KL5hO25715 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Mar 2003 12:49:26 -0800 Content-Transfer-Encoding: 8bit | Breaking news: I am told that the IPv6 WG with overwhelming | consensus decided to deprecate site-local addresses. Appears | that I left the room just 20 minutes earlier than I should | have ;) More details coming. There's not that much more to say. The chairs ARE going to poll the WG via the mailing list, but assuming that the statistics aren't too wildly different, it will be hard to overcome the 5:1 ratio that we saw today. In any case, IMHO, routing just got a bit easier today. ;-) Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 21 17:43:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29858 for ; Fri, 21 Mar 2003 17:43:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LMpHO13801; Fri, 21 Mar 2003 17:51:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LLS2O06916 for ; Fri, 21 Mar 2003 16:28:02 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27660 for ; Fri, 21 Mar 2003 16:09:01 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 1B18234469; Fri, 21 Mar 2003 12:24:24 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2LLBHYB023905; Fri, 21 Mar 2003 13:11:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: For discussion: revising RFC1264 Message-ID: Thread-Topic: For discussion: revising RFC1264 Thread-Index: AcLv6rvioIe9viRgTP+LKhZAeEDWpAAA5jUA From: "Tony Li" To: "Jeffrey Haas" , "Jing Shen" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2LLS2O06917 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 13:11:16 -0800 Content-Transfer-Encoding: 8bit | The BGP FSM is a poor example of this for complicated reasons. Agreed. This probably should have been described via some other mechanism such as pseudo-code. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Mar 21 17:44:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29881 for ; Fri, 21 Mar 2003 17:44:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LN2ZF14582 for routing-discussion-archive@odin.ietf.org; Fri, 21 Mar 2003 18:02:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LMpHO13801; Fri, 21 Mar 2003 17:51:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LLS2O06916 for ; Fri, 21 Mar 2003 16:28:02 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27660 for ; Fri, 21 Mar 2003 16:09:01 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 1B18234469; Fri, 21 Mar 2003 12:24:24 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2LLBHYB023905; Fri, 21 Mar 2003 13:11:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: For discussion: revising RFC1264 Message-ID: Thread-Topic: For discussion: revising RFC1264 Thread-Index: AcLv6rvioIe9viRgTP+LKhZAeEDWpAAA5jUA From: "Tony Li" To: "Jeffrey Haas" , "Jing Shen" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2LLS2O06917 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 13:11:16 -0800 Content-Transfer-Encoding: 8bit | The BGP FSM is a poor example of this for complicated reasons. Agreed. This probably should have been described via some other mechanism such as pseudo-code. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 21 18:03:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00395 for ; Fri, 21 Mar 2003 18:03:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNFlO16061; Fri, 21 Mar 2003 18:15:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNC2O15921 for ; Fri, 21 Mar 2003 18:12:02 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00142 for ; Fri, 21 Mar 2003 17:52:59 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2LMtE65028053; Fri, 21 Mar 2003 17:55:14 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2LMt9Np028039; Fri, 21 Mar 2003 17:55:09 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2LMt3V16468; Fri, 21 Mar 2003 17:55:03 -0500 (EST) From: Jeffrey Haas To: Tony Li Cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... Message-ID: <20030321175503.G10329@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Thu, Mar 20, 2003 at 12:49:26PM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 17:55:03 -0500 On Thu, Mar 20, 2003 at 12:49:26PM -0800, Tony Li wrote: > There's not that much more to say. The chairs ARE going to poll the > WG via the mailing list, but assuming that the statistics aren't too > wildly different, it will be hard to overcome the 5:1 ratio that we > saw today. I'm aware of the headaches that site locals cause, but... What are we going to do about the equivalent of rfc1918 addresses in ipv6? As much as we also might find this semantically/architectually unclean, NATs aren't going to go away, nor is private internal addressing. (Especially at the rates the RIR's want to charge.) -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Mar 21 18:03:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00502 for ; Fri, 21 Mar 2003 18:03:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LNMMw16436 for routing-discussion-archive@odin.ietf.org; Fri, 21 Mar 2003 18:22:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNFlO16061; Fri, 21 Mar 2003 18:15:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNC2O15921 for ; Fri, 21 Mar 2003 18:12:02 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00142 for ; Fri, 21 Mar 2003 17:52:59 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2LMtE65028053; Fri, 21 Mar 2003 17:55:14 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2LMt9Np028039; Fri, 21 Mar 2003 17:55:09 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2LMt3V16468; Fri, 21 Mar 2003 17:55:03 -0500 (EST) From: Jeffrey Haas To: Tony Li Cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... Message-ID: <20030321175503.G10329@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Thu, Mar 20, 2003 at 12:49:26PM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 17:55:03 -0500 On Thu, Mar 20, 2003 at 12:49:26PM -0800, Tony Li wrote: > There's not that much more to say. The chairs ARE going to poll the > WG via the mailing list, but assuming that the statistics aren't too > wildly different, it will be hard to overcome the 5:1 ratio that we > saw today. I'm aware of the headaches that site locals cause, but... What are we going to do about the equivalent of rfc1918 addresses in ipv6? As much as we also might find this semantically/architectually unclean, NATs aren't going to go away, nor is private internal addressing. (Especially at the rates the RIR's want to charge.) -- Jeff Haas NextHop Technologies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 21 18:12:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01634 for ; Fri, 21 Mar 2003 18:12:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNPAO16553; Fri, 21 Mar 2003 18:25:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNITO16238 for ; Fri, 21 Mar 2003 18:18:29 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00299 for ; Fri, 21 Mar 2003 17:59:25 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 9E5DB23C24; Fri, 21 Mar 2003 15:22:24 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2LN1fYB027502; Fri, 21 Mar 2003 15:01:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLv/PTvGS5YLIrTQOO3MLFZ8yexLgAAGAvg From: "Tony Li" To: "Jeffrey Haas" Cc: "Alex Zinin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2LNITO16239 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 15:01:41 -0800 Content-Transfer-Encoding: 8bit | On Thu, Mar 20, 2003 at 12:49:26PM -0800, Tony Li wrote: | > There's not that much more to say. The chairs ARE going | to poll the | > WG via the mailing list, but assuming that the | statistics aren't too | > wildly different, it will be hard to overcome the 5:1 | ratio that we | > saw today. | | I'm aware of the headaches that site locals cause, but... | What are we going to do about the equivalent of rfc1918 | addresses in ipv6? | As much as we also might find this semantically/architectually | unclean, NATs aren't going to go away, nor is private | internal addressing. I fully realize that. However, I believe that anything that effectively sanctions rfc1918 basically is equivalent to admitting that NAT is here to stay. And if one accepts that, the need for IPv6 is nil. Ergo, we must see if we can make IPv6 work without this. Next protocol please... ;-) Tony p.s. Yes, this is an educational exercise for some people, but it seems like we have been working at this for a decade now and folks are not inclined to learn except by making the mistakes. So let's make 'em and get on with it. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Mar 21 18:13:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01712 for ; Fri, 21 Mar 2003 18:13:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LNVil16968 for routing-discussion-archive@odin.ietf.org; Fri, 21 Mar 2003 18:31:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNPAO16553; Fri, 21 Mar 2003 18:25:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNITO16238 for ; Fri, 21 Mar 2003 18:18:29 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00299 for ; Fri, 21 Mar 2003 17:59:25 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 9E5DB23C24; Fri, 21 Mar 2003 15:22:24 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2LN1fYB027502; Fri, 21 Mar 2003 15:01:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLv/PTvGS5YLIrTQOO3MLFZ8yexLgAAGAvg From: "Tony Li" To: "Jeffrey Haas" Cc: "Alex Zinin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2LNITO16239 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 15:01:41 -0800 Content-Transfer-Encoding: 8bit | On Thu, Mar 20, 2003 at 12:49:26PM -0800, Tony Li wrote: | > There's not that much more to say. The chairs ARE going | to poll the | > WG via the mailing list, but assuming that the | statistics aren't too | > wildly different, it will be hard to overcome the 5:1 | ratio that we | > saw today. | | I'm aware of the headaches that site locals cause, but... | What are we going to do about the equivalent of rfc1918 | addresses in ipv6? | As much as we also might find this semantically/architectually | unclean, NATs aren't going to go away, nor is private | internal addressing. I fully realize that. However, I believe that anything that effectively sanctions rfc1918 basically is equivalent to admitting that NAT is here to stay. And if one accepts that, the need for IPv6 is nil. Ergo, we must see if we can make IPv6 work without this. Next protocol please... ;-) Tony p.s. Yes, this is an educational exercise for some people, but it seems like we have been working at this for a decade now and folks are not inclined to learn except by making the mistakes. So let's make 'em and get on with it. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 21 18:44:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02650 for ; Fri, 21 Mar 2003 18:44:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNqAO18567; Fri, 21 Mar 2003 18:52:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNnpO18480 for ; Fri, 21 Mar 2003 18:49:51 -0500 Received: from dino-pc.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02290 for ; Fri, 21 Mar 2003 18:30:46 -0500 (EST) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id PAA19766; Fri, 21 Mar 2003 15:38:36 -0800 Message-Id: <200303212338.PAA19766@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: jhaas@nexthop.com CC: Tony.Li@procket.com, zinin@psg.com, routing-discussion@ietf.org In-reply-to: <20030321175503.G10329@nexthop.com> (message from Jeffrey Haas on Fri, 21 Mar 2003 17:55:03 -0500) Subject: Re: IPv6 site-locals... end of story... References: <20030321175503.G10329@nexthop.com> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 15:38:36 -0800 >> I'm aware of the headaches that site locals cause, but... >> What are we going to do about the equivalent of rfc1918 addresses in ipv6? >> As much as we also might find this semantically/architectually >> unclean, NATs aren't going to go away, nor is private internal addressing. I'd assert that if people wanted to use private addresses they make sure those addresses are not advertised outside of their domain. And if they are accidentially, their ISP should have ingress filtering enabled. Those addresses could be from anywhere in the address space. So using an FEC0::/16 prefix is not bad or should be banned, it's the special treatment by routers that shouldn't be required. To a router, any prefix is just a longest match lookup (and this should be the case for anycast addresses too). Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Mar 21 18:45:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02680 for ; Fri, 21 Mar 2003 18:45:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2M03aQ19141 for routing-discussion-archive@odin.ietf.org; Fri, 21 Mar 2003 19:03:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNqAO18567; Fri, 21 Mar 2003 18:52:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNnpO18480 for ; Fri, 21 Mar 2003 18:49:51 -0500 Received: from dino-pc.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02290 for ; Fri, 21 Mar 2003 18:30:46 -0500 (EST) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id PAA19766; Fri, 21 Mar 2003 15:38:36 -0800 Message-Id: <200303212338.PAA19766@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: jhaas@nexthop.com CC: Tony.Li@procket.com, zinin@psg.com, routing-discussion@ietf.org In-reply-to: <20030321175503.G10329@nexthop.com> (message from Jeffrey Haas on Fri, 21 Mar 2003 17:55:03 -0500) Subject: Re: IPv6 site-locals... end of story... References: <20030321175503.G10329@nexthop.com> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 15:38:36 -0800 >> I'm aware of the headaches that site locals cause, but... >> What are we going to do about the equivalent of rfc1918 addresses in ipv6? >> As much as we also might find this semantically/architectually >> unclean, NATs aren't going to go away, nor is private internal addressing. I'd assert that if people wanted to use private addresses they make sure those addresses are not advertised outside of their domain. And if they are accidentially, their ISP should have ingress filtering enabled. Those addresses could be from anywhere in the address space. So using an FEC0::/16 prefix is not bad or should be banned, it's the special treatment by routers that shouldn't be required. To a router, any prefix is just a longest match lookup (and this should be the case for anycast addresses too). Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 21 21:02:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05260 for ; Fri, 21 Mar 2003 21:02:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M2FYO26854; Fri, 21 Mar 2003 21:15:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M2BPO26714 for ; Fri, 21 Mar 2003 21:11:25 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05086 for ; Fri, 21 Mar 2003 20:52:17 -0500 (EST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18wYDN-0009zg-00; Fri, 21 Mar 2003 17:54:30 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18wYCP-00032T-00; Fri, 21 Mar 2003 17:53:29 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Tony Li" Cc: "Alex Zinin" , Subject: RE: IPv6 site-locals... end of story... References: Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 17:53:00 -0800 Content-Transfer-Encoding: 7bit > In any case, IMHO, routing just got a bit easier today. ;-) how often does that happen? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Mar 21 21:03:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05281 for ; Fri, 21 Mar 2003 21:03:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2M2M7S27140 for routing-discussion-archive@odin.ietf.org; Fri, 21 Mar 2003 21:22:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M2FYO26854; Fri, 21 Mar 2003 21:15:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M2BPO26714 for ; Fri, 21 Mar 2003 21:11:25 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05086 for ; Fri, 21 Mar 2003 20:52:17 -0500 (EST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18wYDN-0009zg-00; Fri, 21 Mar 2003 17:54:30 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18wYCP-00032T-00; Fri, 21 Mar 2003 17:53:29 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Tony Li" Cc: "Alex Zinin" , Subject: RE: IPv6 site-locals... end of story... References: Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Mar 2003 17:53:00 -0800 Content-Transfer-Encoding: 7bit > In any case, IMHO, routing just got a bit easier today. ;-) how often does that happen? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 22 04:25:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22740 for ; Sat, 22 Mar 2003 04:25:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M9cnO29128; Sat, 22 Mar 2003 04:38:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M9XoO28245 for ; Sat, 22 Mar 2003 04:33:50 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22620 for ; Sat, 22 Mar 2003 04:14:34 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 277C934479; Sat, 22 Mar 2003 00:29:58 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2M9GoYB012840; Sat, 22 Mar 2003 01:16:50 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLwFgEpGYisdCzYSs22LNaU+wnEaAAPXRjA From: "Tony Li" To: "Randy Bush" Cc: "Alex Zinin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2M9XoO28246 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Mar 2003 01:16:50 -0800 Content-Transfer-Encoding: 8bit | > In any case, IMHO, routing just got a bit easier today. ;-) | | how often does that happen? 1) EGP deprecated 2) RIP deprecated 3) CIDR approved as BCP Four times in 12 years, so on average once every three. ;-) Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 22 04:26:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22756 for ; Sat, 22 Mar 2003 04:26:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2M9jCI29393 for routing-discussion-archive@odin.ietf.org; Sat, 22 Mar 2003 04:45:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M9cnO29128; Sat, 22 Mar 2003 04:38:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M9XoO28245 for ; Sat, 22 Mar 2003 04:33:50 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22620 for ; Sat, 22 Mar 2003 04:14:34 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 277C934479; Sat, 22 Mar 2003 00:29:58 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2M9GoYB012840; Sat, 22 Mar 2003 01:16:50 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLwFgEpGYisdCzYSs22LNaU+wnEaAAPXRjA From: "Tony Li" To: "Randy Bush" Cc: "Alex Zinin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2M9XoO28246 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Mar 2003 01:16:50 -0800 Content-Transfer-Encoding: 8bit | > In any case, IMHO, routing just got a bit easier today. ;-) | | how often does that happen? 1) EGP deprecated 2) RIP deprecated 3) CIDR approved as BCP Four times in 12 years, so on average once every three. ;-) Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 22 10:10:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27607 for ; Sat, 22 Mar 2003 10:10:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MFMvO14558; Sat, 22 Mar 2003 10:22:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MFHmO14359 for ; Sat, 22 Mar 2003 10:17:48 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26713 for ; Sat, 22 Mar 2003 09:58:24 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA87953; Sat, 22 Mar 2003 09:57:48 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303221457.JAA87953@workhorse.fictitious.org> To: "Tony Li" cc: "Randy Bush" , "Alex Zinin" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Sat, 22 Mar 2003 01:16:50 PST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Mar 2003 09:57:48 -0500 In message , "Tony Li" writes: > > > | > In any case, IMHO, routing just got a bit easier today. ;-) > | > | how often does that happen? > > 1) EGP deprecated > 2) RIP deprecated > 3) CIDR approved as BCP > > Four times in 12 years, so on average once every three. > > ;-) > > Tony You forgot to include CR-LDP deprecated. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 22 10:11:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27691 for ; Sat, 22 Mar 2003 10:11:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2MFTt314777 for routing-discussion-archive@odin.ietf.org; Sat, 22 Mar 2003 10:29:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MFMvO14558; Sat, 22 Mar 2003 10:22:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MFHmO14359 for ; Sat, 22 Mar 2003 10:17:48 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26713 for ; Sat, 22 Mar 2003 09:58:24 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA87953; Sat, 22 Mar 2003 09:57:48 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303221457.JAA87953@workhorse.fictitious.org> To: "Tony Li" cc: "Randy Bush" , "Alex Zinin" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Sat, 22 Mar 2003 01:16:50 PST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Mar 2003 09:57:48 -0500 In message , "Tony Li" writes: > > > | > In any case, IMHO, routing just got a bit easier today. ;-) > | > | how often does that happen? > > 1) EGP deprecated > 2) RIP deprecated > 3) CIDR approved as BCP > > Four times in 12 years, so on average once every three. > > ;-) > > Tony You forgot to include CR-LDP deprecated. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 22 12:13:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00082 for ; Sat, 22 Mar 2003 12:13:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MHMHO21931; Sat, 22 Mar 2003 12:22:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MHHqO21781 for ; Sat, 22 Mar 2003 12:17:52 -0500 Received: from dino-pc.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29837 for ; Sat, 22 Mar 2003 11:58:27 -0500 (EST) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id JAA22006; Sat, 22 Mar 2003 09:06:29 -0800 Message-Id: <200303221706.JAA22006@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: Tony.Li@procket.com CC: randy@psg.com, zinin@psg.com, routing-discussion@ietf.org In-reply-to: (Tony.Li@procket.com) Subject: Re: IPv6 site-locals... end of story... References: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Mar 2003 09:06:29 -0800 >> 1) EGP deprecated >> 2) RIP deprecated >> 3) CIDR approved as BCP >> >> Four times in 12 years, so on average once every three. >> >> ;-) >> >> Tony But RIP is having a revival for colon cancer. ;-) Dino P.S. Not the colon in your belly either. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 22 12:14:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00113 for ; Sat, 22 Mar 2003 12:14:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2MHXcD22343 for routing-discussion-archive@odin.ietf.org; Sat, 22 Mar 2003 12:33:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MHMHO21931; Sat, 22 Mar 2003 12:22:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MHHqO21781 for ; Sat, 22 Mar 2003 12:17:52 -0500 Received: from dino-pc.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29837 for ; Sat, 22 Mar 2003 11:58:27 -0500 (EST) Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id JAA22006; Sat, 22 Mar 2003 09:06:29 -0800 Message-Id: <200303221706.JAA22006@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: Tony.Li@procket.com CC: randy@psg.com, zinin@psg.com, routing-discussion@ietf.org In-reply-to: (Tony.Li@procket.com) Subject: Re: IPv6 site-locals... end of story... References: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Mar 2003 09:06:29 -0800 >> 1) EGP deprecated >> 2) RIP deprecated >> 3) CIDR approved as BCP >> >> Four times in 12 years, so on average once every three. >> >> ;-) >> >> Tony But RIP is having a revival for colon cancer. ;-) Dino P.S. Not the colon in your belly either. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 22 17:47:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06598 for ; Sat, 22 Mar 2003 17:47:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MN02O10990; Sat, 22 Mar 2003 18:00:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MMqFO10743 for ; Sat, 22 Mar 2003 17:52:15 -0500 Received: from kahuna.telstra.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06463 for ; Sat, 22 Mar 2003 17:32:42 -0500 (EST) Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h2MMYkMK066916; Sun, 23 Mar 2003 09:34:56 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030323092844.01bb2fb0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Jeffrey Haas From: Geoff Huston Subject: Re: IPv6 site-locals... end of story... Cc: Alex Zinin , routing-discussion@ietf.org In-Reply-To: <20030321175503.G10329@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 09:34:07 +1100 At 05:55 PM 3/21/2003 -0500, Jeffrey Haas wrote: >I'm aware of the headaches that site locals cause, but... >What are we going to do about the equivalent of rfc1918 addresses in ipv6? >As much as we also might find this semantically/architectually >unclean, NATs aren't going to go away, nor is private internal addressing. Do what we did before private addresses were declared - use public ones and not announce them to the routing system was a common solution in the late 80's. It appeared to work at the time. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 22 17:48:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06629 for ; Sat, 22 Mar 2003 17:48:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2MN7aJ12004 for routing-discussion-archive@odin.ietf.org; Sat, 22 Mar 2003 18:07:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MN02O10990; Sat, 22 Mar 2003 18:00:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MMqFO10743 for ; Sat, 22 Mar 2003 17:52:15 -0500 Received: from kahuna.telstra.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06463 for ; Sat, 22 Mar 2003 17:32:42 -0500 (EST) Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h2MMYkMK066916; Sun, 23 Mar 2003 09:34:56 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030323092844.01bb2fb0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Jeffrey Haas From: Geoff Huston Subject: Re: IPv6 site-locals... end of story... Cc: Alex Zinin , routing-discussion@ietf.org In-Reply-To: <20030321175503.G10329@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 09:34:07 +1100 At 05:55 PM 3/21/2003 -0500, Jeffrey Haas wrote: >I'm aware of the headaches that site locals cause, but... >What are we going to do about the equivalent of rfc1918 addresses in ipv6? >As much as we also might find this semantically/architectually >unclean, NATs aren't going to go away, nor is private internal addressing. Do what we did before private addresses were declared - use public ones and not announce them to the routing system was a common solution in the late 80's. It appeared to work at the time. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sat Mar 22 22:25:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11714 for ; Sat, 22 Mar 2003 22:25:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N3ZrO24672; Sat, 22 Mar 2003 22:35:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N3UYO24579 for ; Sat, 22 Mar 2003 22:30:34 -0500 Received: from garlic.amaranth.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11409 for ; Sat, 22 Mar 2003 22:10:55 -0500 (EST) Received: from Willow.senie.com (66-108-41-155.nyc.rr.com [66.108.41.155]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id h2N3DD915505 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Sat, 22 Mar 2003 22:13:13 -0500 Message-Id: <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: routing-discussion@ietf.org From: Daniel Senie Subject: Re: IPv6 site-locals... end of story... In-Reply-To: <5.1.0.14.2.20030323092844.01bb2fb0@localhost> References: <20030321175503.G10329@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Mar 2003 21:47:33 -0500 At 05:34 PM 3/22/2003, Geoff Huston wrote: >At 05:55 PM 3/21/2003 -0500, Jeffrey Haas wrote: > >>I'm aware of the headaches that site locals cause, but... >>What are we going to do about the equivalent of rfc1918 addresses in ipv6? >>As much as we also might find this semantically/architectually >>unclean, NATs aren't going to go away, nor is private internal addressing. > >Do what we did before private addresses were declared - use public >ones and not announce them to the routing system was a common >solution in the late 80's. It appeared to work at the time. And resulted in a major mess for many folk when networks were linked to the public network. How many folks had to renumber large networks out of Sun Microsystems' IP address space (after all, the addresses in the examples in the manuals used that space!). Private address space is useful with out NAT, folks. There are network nodes in many places that do not need to consume public address space. Whether that's a back-side network between web servers and a database server, a network segment containing nothing but storage devices accessed only locally, or a network segment containing only printers, there's a good argument for NOT wasting public address space. In none of these cases is NAT employed. Site local address space, in some fashion, has a place in this world. Announcements of such space to the rest of the world should not occur, and can be blocked by border routers, just as it should be today with the use of RFC1918 space. In the zeal to deploy IPv6 and its "boundless" address space let us not presume to dictate the implementation strategies for private network segments. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sat Mar 22 22:26:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11738 for ; Sat, 22 Mar 2003 22:26:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2N3jsK25765 for routing-discussion-archive@odin.ietf.org; Sat, 22 Mar 2003 22:45:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N3ZrO24672; Sat, 22 Mar 2003 22:35:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N3UYO24579 for ; Sat, 22 Mar 2003 22:30:34 -0500 Received: from garlic.amaranth.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11409 for ; Sat, 22 Mar 2003 22:10:55 -0500 (EST) Received: from Willow.senie.com (66-108-41-155.nyc.rr.com [66.108.41.155]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id h2N3DD915505 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Sat, 22 Mar 2003 22:13:13 -0500 Message-Id: <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: routing-discussion@ietf.org From: Daniel Senie Subject: Re: IPv6 site-locals... end of story... In-Reply-To: <5.1.0.14.2.20030323092844.01bb2fb0@localhost> References: <20030321175503.G10329@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Mar 2003 21:47:33 -0500 At 05:34 PM 3/22/2003, Geoff Huston wrote: >At 05:55 PM 3/21/2003 -0500, Jeffrey Haas wrote: > >>I'm aware of the headaches that site locals cause, but... >>What are we going to do about the equivalent of rfc1918 addresses in ipv6? >>As much as we also might find this semantically/architectually >>unclean, NATs aren't going to go away, nor is private internal addressing. > >Do what we did before private addresses were declared - use public >ones and not announce them to the routing system was a common >solution in the late 80's. It appeared to work at the time. And resulted in a major mess for many folk when networks were linked to the public network. How many folks had to renumber large networks out of Sun Microsystems' IP address space (after all, the addresses in the examples in the manuals used that space!). Private address space is useful with out NAT, folks. There are network nodes in many places that do not need to consume public address space. Whether that's a back-side network between web servers and a database server, a network segment containing nothing but storage devices accessed only locally, or a network segment containing only printers, there's a good argument for NOT wasting public address space. In none of these cases is NAT employed. Site local address space, in some fashion, has a place in this world. Announcements of such space to the rest of the world should not occur, and can be blocked by border routers, just as it should be today with the use of RFC1918 space. In the zeal to deploy IPv6 and its "boundless" address space let us not presume to dictate the implementation strategies for private network segments. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sun Mar 23 13:35:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06470 for ; Sun, 23 Mar 2003 13:35:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NImEO19948; Sun, 23 Mar 2003 13:48:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NIhwO19781 for ; Sun, 23 Mar 2003 13:43:58 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06311 for ; Sun, 23 Mar 2003 13:24:02 -0500 (EST) Received: from cisco.com (sjc-vpn1-650.cisco.com [10.21.98.138]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA26557; Sun, 23 Mar 2003 10:26:16 -0800 (PST) Message-ID: <3E7DFC47.9090800@cisco.com> From: Eliot Lear 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: Daniel Senie CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <20030321175503.G10329@nexthop.com> <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> In-Reply-To: <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 10:26:15 -0800 Content-Transfer-Encoding: 7bit Daniel Senie wrote: > Private address space is useful with out NAT, folks. There are network > nodes in many places that do not need to consume public address space. > Whether that's a back-side network between web servers and a database > server, a network segment containing nothing but storage devices > accessed only locally, or a network segment containing only printers, > there's a good argument for NOT wasting public address space. In none of > these cases is NAT employed. This belies the notion of an engineering trade-off. There is no reason to create an architectural mess by saving an address here or there. We have 2^128 of them to use. Registries should see that this is the case. > Site local address space, in some fashion, has a place in this world. > Announcements of such space to the rest of the world should not occur, > and can be blocked by border routers, just as it should be today with > the use of RFC1918 space. The only potential legitimate use of site locals is a completely disconnected network and those networks tend to be quite small. > > In the zeal to deploy IPv6 and its "boundless" address space let us not > presume to dictate the implementation strategies for private network > segments. Let's not engineer for corner cases, please. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sun Mar 23 13:36:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06524 for ; Sun, 23 Mar 2003 13:36:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2NIttW20288 for routing-discussion-archive@odin.ietf.org; Sun, 23 Mar 2003 13:55:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NImEO19948; Sun, 23 Mar 2003 13:48:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NIhwO19781 for ; Sun, 23 Mar 2003 13:43:58 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06311 for ; Sun, 23 Mar 2003 13:24:02 -0500 (EST) Received: from cisco.com (sjc-vpn1-650.cisco.com [10.21.98.138]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA26557; Sun, 23 Mar 2003 10:26:16 -0800 (PST) Message-ID: <3E7DFC47.9090800@cisco.com> From: Eliot Lear 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: Daniel Senie CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <20030321175503.G10329@nexthop.com> <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> In-Reply-To: <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 10:26:15 -0800 Content-Transfer-Encoding: 7bit Daniel Senie wrote: > Private address space is useful with out NAT, folks. There are network > nodes in many places that do not need to consume public address space. > Whether that's a back-side network between web servers and a database > server, a network segment containing nothing but storage devices > accessed only locally, or a network segment containing only printers, > there's a good argument for NOT wasting public address space. In none of > these cases is NAT employed. This belies the notion of an engineering trade-off. There is no reason to create an architectural mess by saving an address here or there. We have 2^128 of them to use. Registries should see that this is the case. > Site local address space, in some fashion, has a place in this world. > Announcements of such space to the rest of the world should not occur, > and can be blocked by border routers, just as it should be today with > the use of RFC1918 space. The only potential legitimate use of site locals is a completely disconnected network and those networks tend to be quite small. > > In the zeal to deploy IPv6 and its "boundless" address space let us not > presume to dictate the implementation strategies for private network > segments. Let's not engineer for corner cases, please. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sun Mar 23 17:09:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12106 for ; Sun, 23 Mar 2003 17:09:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NMLdO32038; Sun, 23 Mar 2003 17:21:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NMI6O31962 for ; Sun, 23 Mar 2003 17:18:06 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11934 for ; Sun, 23 Mar 2003 16:58:04 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id E64023442A; Sun, 23 Mar 2003 13:13:32 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2NM0MYB019929; Sun, 23 Mar 2003 14:00:22 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLxa66yTdjKrbRfSBuwvxjsyaKZdAAG860Q From: "Tony Li" To: "Eliot Lear" , "Daniel Senie" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2NMI6O31963 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 14:00:22 -0800 Content-Transfer-Encoding: 8bit | This belies the notion of an engineering trade-off. There | is no reason | to create an architectural mess by saving an address here | or there. We | have 2^128 of them to use. Registries should see that | this is the case. Folks should also remember that renumber in IPv6 is easy. So picking something and then changing when you get connected should not be a big deal. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sun Mar 23 17:10:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12123 for ; Sun, 23 Mar 2003 17:10:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2NMTYE32269 for routing-discussion-archive@odin.ietf.org; Sun, 23 Mar 2003 17:29:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NMLdO32038; Sun, 23 Mar 2003 17:21:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NMI6O31962 for ; Sun, 23 Mar 2003 17:18:06 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11934 for ; Sun, 23 Mar 2003 16:58:04 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id E64023442A; Sun, 23 Mar 2003 13:13:32 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2NM0MYB019929; Sun, 23 Mar 2003 14:00:22 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLxa66yTdjKrbRfSBuwvxjsyaKZdAAG860Q From: "Tony Li" To: "Eliot Lear" , "Daniel Senie" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2NMI6O31963 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 14:00:22 -0800 Content-Transfer-Encoding: 8bit | This belies the notion of an engineering trade-off. There | is no reason | to create an architectural mess by saving an address here | or there. We | have 2^128 of them to use. Registries should see that | this is the case. Folks should also remember that renumber in IPv6 is easy. So picking something and then changing when you get connected should not be a big deal. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sun Mar 23 17:14:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12291 for ; Sun, 23 Mar 2003 17:14:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NMS9O32213; Sun, 23 Mar 2003 17:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NMPsO32165 for ; Sun, 23 Mar 2003 17:25:54 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12040 for ; Sun, 23 Mar 2003 17:05:52 -0500 (EST) Received: from cisco.com (sjc-vpn4-667.cisco.com [10.21.82.155]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA29014; Sun, 23 Mar 2003 14:08:02 -0800 (PST) Message-ID: <3E7E3041.4050006@cisco.com> From: Eliot Lear 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: David Conrad CC: Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> In-Reply-To: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 14:08:01 -0800 Content-Transfer-Encoding: 7bit David, You're right- the law's of physics haven't changed. But we also don't live in the '80s. Anyone doing work to convert to IPv6 should not make the same mistakes of the 80s by splattering IP addresses everywhere. Let's not make our decisions based on bad design and operational choices. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sun Mar 23 17:15:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12305 for ; Sun, 23 Mar 2003 17:15:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2NMZ2632461 for routing-discussion-archive@odin.ietf.org; Sun, 23 Mar 2003 17:35:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NMS9O32213; Sun, 23 Mar 2003 17:28:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NMPsO32165 for ; Sun, 23 Mar 2003 17:25:54 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12040 for ; Sun, 23 Mar 2003 17:05:52 -0500 (EST) Received: from cisco.com (sjc-vpn4-667.cisco.com [10.21.82.155]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA29014; Sun, 23 Mar 2003 14:08:02 -0800 (PST) Message-ID: <3E7E3041.4050006@cisco.com> From: Eliot Lear 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: David Conrad CC: Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> In-Reply-To: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 14:08:01 -0800 Content-Transfer-Encoding: 7bit David, You're right- the law's of physics haven't changed. But we also don't live in the '80s. Anyone doing work to convert to IPv6 should not make the same mistakes of the 80s by splattering IP addresses everywhere. Let's not make our decisions based on bad design and operational choices. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sun Mar 23 21:31:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18683 for ; Sun, 23 Mar 2003 21:31:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O2gQO13746; Sun, 23 Mar 2003 21:42:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O2cfO13616 for ; Sun, 23 Mar 2003 21:38:41 -0500 Received: from india-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18265 for ; Sun, 23 Mar 2003 21:18:33 -0500 (EST) Received: from cbin2-mira-01.cisco.com (localhost [127.0.0.1]) by india-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2O7nEw6019507; Mon, 24 Mar 2003 07:49:14 GMT Received: from cisco.com (sjc-vpn3-972.cisco.com [10.21.67.204]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AAW02176 (AUTH raraghun); Mon, 24 Mar 2003 07:41:06 +0530 (IST) Message-ID: <3E7E6B6E.F8460767@cisco.com> From: Rajiv Raghunarayan Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Eliot Lear CC: David Conrad , Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> <3E7E3041.4050006@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 18:20:30 -0800 Content-Transfer-Encoding: 7bit Hi Eliot, Eliot Lear wrote: > > David, > > You're right- the law's of physics haven't changed. But we also don't > live in the '80s. Anyone doing work to convert to IPv6 should not make > the same mistakes of the 80s by splattering IP addresses everywhere. > Let's not make our decisions based on bad design and operational choices. > Yep. Agree with your point. But to extend on the point Daniel makes.. if we do away with the site-locals, people may come around to making the same mistakes were done in the past, unless they are educated about the issues that occured back in the 80s (and not all people associated with designing networks were around in the 80s ;-) Would it be useful if someone, with experience of the issues, puts a small document ("Potential pitfalls in the absence of private address space"??) about the issues with no private address space and possible ways to work around them (or does such a document already exist??). This may/would help the network designers in avoiding same issues. IMHO, dropping the ball here and as is may result in re-opening past wounds!! My 2 cents.. -Rajiv. > Eliot > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Sun Mar 23 21:32:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18711 for ; Sun, 23 Mar 2003 21:32:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O2qBx14173 for routing-discussion-archive@odin.ietf.org; Sun, 23 Mar 2003 21:52:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O2gQO13746; Sun, 23 Mar 2003 21:42:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O2cfO13616 for ; Sun, 23 Mar 2003 21:38:41 -0500 Received: from india-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18265 for ; Sun, 23 Mar 2003 21:18:33 -0500 (EST) Received: from cbin2-mira-01.cisco.com (localhost [127.0.0.1]) by india-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2O7nEw6019507; Mon, 24 Mar 2003 07:49:14 GMT Received: from cisco.com (sjc-vpn3-972.cisco.com [10.21.67.204]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AAW02176 (AUTH raraghun); Mon, 24 Mar 2003 07:41:06 +0530 (IST) Message-ID: <3E7E6B6E.F8460767@cisco.com> From: Rajiv Raghunarayan Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Eliot Lear CC: David Conrad , Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> <3E7E3041.4050006@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 18:20:30 -0800 Content-Transfer-Encoding: 7bit Hi Eliot, Eliot Lear wrote: > > David, > > You're right- the law's of physics haven't changed. But we also don't > live in the '80s. Anyone doing work to convert to IPv6 should not make > the same mistakes of the 80s by splattering IP addresses everywhere. > Let's not make our decisions based on bad design and operational choices. > Yep. Agree with your point. But to extend on the point Daniel makes.. if we do away with the site-locals, people may come around to making the same mistakes were done in the past, unless they are educated about the issues that occured back in the 80s (and not all people associated with designing networks were around in the 80s ;-) Would it be useful if someone, with experience of the issues, puts a small document ("Potential pitfalls in the absence of private address space"??) about the issues with no private address space and possible ways to work around them (or does such a document already exist??). This may/would help the network designers in avoiding same issues. IMHO, dropping the ball here and as is may result in re-opening past wounds!! My 2 cents.. -Rajiv. > Eliot > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 01:58:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24241 for ; Mon, 24 Mar 2003 01:58:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O7AsO04725; Mon, 24 Mar 2003 02:10:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O77ZO01277 for ; Mon, 24 Mar 2003 02:07:35 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23976 for ; Mon, 24 Mar 2003 01:47:24 -0500 (EST) Received: from cisco.com (sjc-vpn4-101.cisco.com [10.21.80.101]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id WAA28785; Sun, 23 Mar 2003 22:49:32 -0800 (PST) Message-ID: <3E7EAA7B.7000505@cisco.com> From: Eliot Lear 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: Rajiv Raghunarayan CC: David Conrad , Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> <3E7E3041.4050006@cisco.com> <3E7E6B6E.F8460767@cisco.com> In-Reply-To: <3E7E6B6E.F8460767@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 22:49:31 -0800 Content-Transfer-Encoding: 7bit Rajiv, Maybe some guidance is deserved. What do you think of RFC 1627? ;-) Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 02:00:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24288 for ; Mon, 24 Mar 2003 02:00:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O7Jf907988 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 02:19:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O7AsO04725; Mon, 24 Mar 2003 02:10:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O77ZO01277 for ; Mon, 24 Mar 2003 02:07:35 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23976 for ; Mon, 24 Mar 2003 01:47:24 -0500 (EST) Received: from cisco.com (sjc-vpn4-101.cisco.com [10.21.80.101]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id WAA28785; Sun, 23 Mar 2003 22:49:32 -0800 (PST) Message-ID: <3E7EAA7B.7000505@cisco.com> From: Eliot Lear 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: Rajiv Raghunarayan CC: David Conrad , Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> <3E7E3041.4050006@cisco.com> <3E7E6B6E.F8460767@cisco.com> In-Reply-To: <3E7E6B6E.F8460767@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 22:49:31 -0800 Content-Transfer-Encoding: 7bit Rajiv, Maybe some guidance is deserved. What do you think of RFC 1627? ;-) Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 04:09:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08028 for ; Mon, 24 Mar 2003 04:09:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O9LZO16189; Mon, 24 Mar 2003 04:21:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O9H1O16054 for ; Mon, 24 Mar 2003 04:17:01 -0500 Received: from pheriche.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07883 for ; Mon, 24 Mar 2003 03:56:46 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09524; Mon, 24 Mar 2003 01:59:04 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2O8x3K04140; Mon, 24 Mar 2003 09:59:03 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 site-locals... end of story... To: Daniel Senie Cc: routing-discussion@ietf.org In-Reply-To: "Your message with ID" <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 09:55:02 +0100 (CET) > And resulted in a major mess for many folk when networks were linked to the > public network. How many folks had to renumber large networks out of Sun > Microsystems' IP address space (after all, the addresses in the examples in > the manuals used that space!). But what's the difference between this and renumbering from site-local space to global space when the site gets connected? I don't know of a scheme that doesn't require renumbering the addresses/locators when a never-connected site gets connected. Erik _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 04:11:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08048 for ; Mon, 24 Mar 2003 04:11:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O9UoU16409 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 04:30:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O9LZO16189; Mon, 24 Mar 2003 04:21:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O9H1O16054 for ; Mon, 24 Mar 2003 04:17:01 -0500 Received: from pheriche.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07883 for ; Mon, 24 Mar 2003 03:56:46 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09524; Mon, 24 Mar 2003 01:59:04 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2O8x3K04140; Mon, 24 Mar 2003 09:59:03 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 site-locals... end of story... To: Daniel Senie Cc: routing-discussion@ietf.org In-Reply-To: "Your message with ID" <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 09:55:02 +0100 (CET) > And resulted in a major mess for many folk when networks were linked to the > public network. How many folks had to renumber large networks out of Sun > Microsystems' IP address space (after all, the addresses in the examples in > the manuals used that space!). But what's the difference between this and renumbering from site-local space to global space when the site gets connected? I don't know of a scheme that doesn't require renumbering the addresses/locators when a never-connected site gets connected. Erik _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 05:01:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09124 for ; Mon, 24 Mar 2003 05:01:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OADLO19536; Mon, 24 Mar 2003 05:13:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OA9xO19403 for ; Mon, 24 Mar 2003 05:09:59 -0500 Received: from mailhost.packetfront.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08945 for ; Mon, 24 Mar 2003 04:49:42 -0500 (EST) Received: from [192.168.1.11] (helo=Mtw10) by mailhost.packetfront.com with esmtp (Exim 3.35 #1 (Debian)) id 18xOcJ-0002FQ-00; Mon, 24 Mar 2003 10:51:44 +0100 From: "Fredrik Nyman" Organization: PacketFront Sweden AB To: Eliot Lear MIME-Version: 1.0 Subject: Re: IPv6 site-locals... end of story... Reply-to: fredrik@packetfront.com CC: Daniel Senie , routing-discussion@ietf.org Message-ID: <3E7EE0BE.822.5B4FF316@localhost> Priority: normal In-reply-to: <3E7E3041.4050006@cisco.com> References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 10:41:02 +0100 Content-Transfer-Encoding: 7BIT On 23 Mar 2003 at 14:08, Eliot Lear wrote: > David, > > You're right- the law's of physics haven't changed. But we also don't > live in the '80s. Anyone doing work to convert to IPv6 should not make > the same mistakes of the 80s by splattering IP addresses everywhere. > Let's not make our decisions based on bad design and operational choices. If people *use* the protocols in a way not intended by its designers, the designers were wrong.... You can have the best idea in the world, but unless people adapt to it, it is worthless. If it turns out that the operational people will use NAT for IPv6, then there is a reason for it and then it was wrong by us not to take that into consideration when designing the specs. -- Fredrik Nyman PacketFront Sweden AB http://www.packetfront.com/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 05:02:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09161 for ; Mon, 24 Mar 2003 05:02:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OAMQL19966 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 05:22:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OADLO19536; Mon, 24 Mar 2003 05:13:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OA9xO19403 for ; Mon, 24 Mar 2003 05:09:59 -0500 Received: from mailhost.packetfront.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08945 for ; Mon, 24 Mar 2003 04:49:42 -0500 (EST) Received: from [192.168.1.11] (helo=Mtw10) by mailhost.packetfront.com with esmtp (Exim 3.35 #1 (Debian)) id 18xOcJ-0002FQ-00; Mon, 24 Mar 2003 10:51:44 +0100 From: "Fredrik Nyman" Organization: PacketFront Sweden AB To: Eliot Lear MIME-Version: 1.0 Subject: Re: IPv6 site-locals... end of story... Reply-to: fredrik@packetfront.com CC: Daniel Senie , routing-discussion@ietf.org Message-ID: <3E7EE0BE.822.5B4FF316@localhost> Priority: normal In-reply-to: <3E7E3041.4050006@cisco.com> References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 10:41:02 +0100 Content-Transfer-Encoding: 7BIT On 23 Mar 2003 at 14:08, Eliot Lear wrote: > David, > > You're right- the law's of physics haven't changed. But we also don't > live in the '80s. Anyone doing work to convert to IPv6 should not make > the same mistakes of the 80s by splattering IP addresses everywhere. > Let's not make our decisions based on bad design and operational choices. If people *use* the protocols in a way not intended by its designers, the designers were wrong.... You can have the best idea in the world, but unless people adapt to it, it is worthless. If it turns out that the operational people will use NAT for IPv6, then there is a reason for it and then it was wrong by us not to take that into consideration when designing the specs. -- Fredrik Nyman PacketFront Sweden AB http://www.packetfront.com/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 13:08:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27404 for ; Mon, 24 Mar 2003 13:08:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OIGNO20709; Mon, 24 Mar 2003 13:16:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OIA8O20517 for ; Mon, 24 Mar 2003 13:10:08 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26812 for ; Mon, 24 Mar 2003 12:49:41 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 078BC34437; Mon, 24 Mar 2003 09:05:13 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2OHq0YB000960; Mon, 24 Mar 2003 09:52:01 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLx7mEOEwwlFejSTAqrOHM/TpeUrwAP0mYw From: "Tony Li" To: , "Eliot Lear" Cc: "Daniel Senie" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OIA8O20520 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 09:52:00 -0800 Content-Transfer-Encoding: 8bit With all due respect, this is backwards. No matter how well we design, what we produce will be used for something that it's not intended for. How many times have you used a screwdriver as a pry bar? This is the human condition: we adapt, abusing the tools around us to fit the job. Yes, obviously the architecture SHOULD be able to support NAT, and it clearly does. However, we do NOT have to actively support NAT, especially when support of NAT eliminates the only true need for v6. Tony | -----Original Message----- | From: Fredrik Nyman [mailto:fredrik@packetfront.com] | Sent: Monday, March 24, 2003 1:41 AM | To: Eliot Lear | Cc: Daniel Senie; routing-discussion@ietf.org | Subject: Re: IPv6 site-locals... end of story... | | | On 23 Mar 2003 at 14:08, Eliot Lear wrote: | | > David, | > | > You're right- the law's of physics haven't changed. But | we also don't | > live in the '80s. Anyone doing work to convert to IPv6 | should not make | > the same mistakes of the 80s by splattering IP addresses | everywhere. | > Let's not make our decisions based on bad design and | operational choices. | | If people *use* the protocols in a way not intended by its | designers, the | designers were wrong.... You can have the best idea in the | world, but | unless people adapt to it, it is worthless. | | If it turns out that the operational people will use NAT | for IPv6, then | there is a reason for it and then it was wrong by us not | to take that into | consideration when designing the specs. | | -- | Fredrik Nyman | PacketFront Sweden AB | http://www.packetfront.com/ | | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 13:09:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27421 for ; Mon, 24 Mar 2003 13:09:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OID6O20587; Mon, 24 Mar 2003 13:13:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OI9pO20496 for ; Mon, 24 Mar 2003 13:09:51 -0500 Received: from cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26806 for ; Mon, 24 Mar 2003 12:49:24 -0500 (EST) Received: from mordred.cs.ucla.edu (yfe9kcvbir7gtd20@localhost [127.0.0.1]) by cs.ucla.edu (8.12.8/8.12.7) with ESMTP id h2OHpiB8056451; Mon, 24 Mar 2003 09:51:44 -0800 (PST) (envelope-from scottm@mordred.cs.ucla.edu) Received: from localhost (localhost [[UNIX: localhost]]) by mordred.cs.ucla.edu (8.12.8/8.12.7/Submit) id h2OHphCN056450; Mon, 24 Mar 2003 09:51:43 -0800 (PST) From: Scott Michel Organization: UCLA Computer Chaos To: "Tony Li" , "Jeffrey Haas" Subject: Re: IPv6 site-locals... end of story... User-Agent: KMail/1.5 Cc: "Alex Zinin" , 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: <200303240951.43643.scottm@cs.ucla.edu> Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 09:51:43 -0800 Content-Transfer-Encoding: 7bit On Friday 21 March 2003 15:01, Tony Li wrote: > p.s. Yes, this is an educational exercise for some people, but > it seems like we have been working at this for a decade now > and folks are not inclined to learn except by making the > mistakes. So let's make 'em and get on with it. To quote one of my favorite high school teachers, "We learn by making better mistakes." Let's hope that's the case with this evolution. -scooter _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 13:09:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27459 for ; Mon, 24 Mar 2003 13:09:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OITq821264 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 13:29:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OID6O20587; Mon, 24 Mar 2003 13:13:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OI9pO20496 for ; Mon, 24 Mar 2003 13:09:51 -0500 Received: from cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26806 for ; Mon, 24 Mar 2003 12:49:24 -0500 (EST) Received: from mordred.cs.ucla.edu (yfe9kcvbir7gtd20@localhost [127.0.0.1]) by cs.ucla.edu (8.12.8/8.12.7) with ESMTP id h2OHpiB8056451; Mon, 24 Mar 2003 09:51:44 -0800 (PST) (envelope-from scottm@mordred.cs.ucla.edu) Received: from localhost (localhost [[UNIX: localhost]]) by mordred.cs.ucla.edu (8.12.8/8.12.7/Submit) id h2OHphCN056450; Mon, 24 Mar 2003 09:51:43 -0800 (PST) From: Scott Michel Organization: UCLA Computer Chaos To: "Tony Li" , "Jeffrey Haas" Subject: Re: IPv6 site-locals... end of story... User-Agent: KMail/1.5 Cc: "Alex Zinin" , 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: <200303240951.43643.scottm@cs.ucla.edu> Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 09:51:43 -0800 Content-Transfer-Encoding: 7bit On Friday 21 March 2003 15:01, Tony Li wrote: > p.s. Yes, this is an educational exercise for some people, but > it seems like we have been working at this for a decade now > and folks are not inclined to learn except by making the > mistakes. So let's make 'em and get on with it. To quote one of my favorite high school teachers, "We learn by making better mistakes." Let's hope that's the case with this evolution. -scooter _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 13:10:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27472 for ; Mon, 24 Mar 2003 13:10:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OITtM21278 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 13:29:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OIGNO20709; Mon, 24 Mar 2003 13:16:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OIA8O20517 for ; Mon, 24 Mar 2003 13:10:08 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26812 for ; Mon, 24 Mar 2003 12:49:41 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 078BC34437; Mon, 24 Mar 2003 09:05:13 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2OHq0YB000960; Mon, 24 Mar 2003 09:52:01 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLx7mEOEwwlFejSTAqrOHM/TpeUrwAP0mYw From: "Tony Li" To: , "Eliot Lear" Cc: "Daniel Senie" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OIA8O20520 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 09:52:00 -0800 Content-Transfer-Encoding: 8bit With all due respect, this is backwards. No matter how well we design, what we produce will be used for something that it's not intended for. How many times have you used a screwdriver as a pry bar? This is the human condition: we adapt, abusing the tools around us to fit the job. Yes, obviously the architecture SHOULD be able to support NAT, and it clearly does. However, we do NOT have to actively support NAT, especially when support of NAT eliminates the only true need for v6. Tony | -----Original Message----- | From: Fredrik Nyman [mailto:fredrik@packetfront.com] | Sent: Monday, March 24, 2003 1:41 AM | To: Eliot Lear | Cc: Daniel Senie; routing-discussion@ietf.org | Subject: Re: IPv6 site-locals... end of story... | | | On 23 Mar 2003 at 14:08, Eliot Lear wrote: | | > David, | > | > You're right- the law's of physics haven't changed. But | we also don't | > live in the '80s. Anyone doing work to convert to IPv6 | should not make | > the same mistakes of the 80s by splattering IP addresses | everywhere. | > Let's not make our decisions based on bad design and | operational choices. | | If people *use* the protocols in a way not intended by its | designers, the | designers were wrong.... You can have the best idea in the | world, but | unless people adapt to it, it is worthless. | | If it turns out that the operational people will use NAT | for IPv6, then | there is a reason for it and then it was wrong by us not | to take that into | consideration when designing the specs. | | -- | Fredrik Nyman | PacketFront Sweden AB | http://www.packetfront.com/ | | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 13:31:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28214 for ; Mon, 24 Mar 2003 13:31:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OIYNO21544; Mon, 24 Mar 2003 13:34:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OIVIO21357 for ; Mon, 24 Mar 2003 13:31:18 -0500 Received: from slb-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27503 for ; Mon, 24 Mar 2003 13:10:53 -0500 (EST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA10965; Mon, 24 Mar 2003 10:12:53 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id KAA24628; Mon, 24 Mar 2003 10:13:09 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2OID6H24760; Mon, 24 Mar 2003 10:13:06 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 13:12:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLx7mEOEwwlFejSTAqrOHM/TpeUrwAP0mYwAAB60NA= From: "Manfredi, Albert E" To: "Tony Li" Cc: X-OriginalArrivalTime: 24 Mar 2003 18:12:31.0955 (UTC) FILETIME=[F00D4A30:01C2F230] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OIVIO21358 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 13:12:31 -0500 Content-Transfer-Encoding: 8bit Tony Li wrote: > Yes, obviously the architecture SHOULD be able to support NAT, > and it clearly does. However, we do NOT have to actively > support NAT, especially when support of NAT eliminates the > only true need for v6. Tony, You said a mouthful in that last sentence. Too bad IPv6 couldn't have been simply an application of (perhaps) NSAP Addresses to IPv4. I'm still not clear why a well-defined private address space is considered useless with IPv6. If I use the global address space in a private network, or worse in many private networks that I configured identically, and somehow one or more of these gets inadvertently connected to the Internet, wouldn't it be easier to have a well-defined address space that all routers would by default NOT route? The argument that 128-bit addresses are enough for everyone does not preclude the point that these addresses must still be unique. Perhaps I'm missing the whole story, since I wasn't at the meeting. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 13:32:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28236 for ; Mon, 24 Mar 2003 13:32:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OIqOO23119 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 13:52:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OIYNO21544; Mon, 24 Mar 2003 13:34:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OIVIO21357 for ; Mon, 24 Mar 2003 13:31:18 -0500 Received: from slb-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27503 for ; Mon, 24 Mar 2003 13:10:53 -0500 (EST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA10965; Mon, 24 Mar 2003 10:12:53 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id KAA24628; Mon, 24 Mar 2003 10:13:09 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2OID6H24760; Mon, 24 Mar 2003 10:13:06 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 13:12:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLx7mEOEwwlFejSTAqrOHM/TpeUrwAP0mYwAAB60NA= From: "Manfredi, Albert E" To: "Tony Li" Cc: X-OriginalArrivalTime: 24 Mar 2003 18:12:31.0955 (UTC) FILETIME=[F00D4A30:01C2F230] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OIVIO21358 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 13:12:31 -0500 Content-Transfer-Encoding: 8bit Tony Li wrote: > Yes, obviously the architecture SHOULD be able to support NAT, > and it clearly does. However, we do NOT have to actively > support NAT, especially when support of NAT eliminates the > only true need for v6. Tony, You said a mouthful in that last sentence. Too bad IPv6 couldn't have been simply an application of (perhaps) NSAP Addresses to IPv4. I'm still not clear why a well-defined private address space is considered useless with IPv6. If I use the global address space in a private network, or worse in many private networks that I configured identically, and somehow one or more of these gets inadvertently connected to the Internet, wouldn't it be easier to have a well-defined address space that all routers would by default NOT route? The argument that 128-bit addresses are enough for everyone does not preclude the point that these addresses must still be unique. Perhaps I'm missing the whole story, since I wasn't at the meeting. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 13:48:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28645 for ; Mon, 24 Mar 2003 13:48:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OItZO23243; Mon, 24 Mar 2003 13:55:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OIqHO23099 for ; Mon, 24 Mar 2003 13:52:17 -0500 Received: from ms-smtp-03.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28231 for ; Mon, 24 Mar 2003 13:31:51 -0500 (EST) Received: from mail3.nc.rr.com (fe3 [24.93.67.50]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2OIX0m0016591 for ; Mon, 24 Mar 2003 13:33:00 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 24 Mar 2003 13:31:52 -0500 Message-ID: <3E7F4FA0.3060107@nc.rr.com> From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 13:34:08 -0500 Content-Transfer-Encoding: 7bit Manfredi, Albert E wrote: > Tony Li wrote: > > >> Yes, obviously the architecture SHOULD be able to support NAT, and >> it clearly does. However, we do NOT have to actively support NAT, >> especially when support of NAT eliminates the only true need for >> v6. > > > Tony, > > You said a mouthful in that last sentence. Too bad IPv6 couldn't have > been simply an application of (perhaps) NSAP Addresses to IPv4. > > I'm still not clear why a well-defined private address space is > considered useless with IPv6. If I use the global address space in a > private network, or worse in many private networks that I configured > identically, and somehow one or more of these gets inadvertently > connected to the Internet, wouldn't it be easier to have a > well-defined address space that all routers would by default NOT > route? > > The argument that 128-bit addresses are enough for everyone does not > preclude the point that these addresses must still be unique. Perhaps > I'm missing the whole story, since I wasn't at the meeting. I think we have jumped the gun here a little bit. The tentative consensus in the IPv6 WG meeting was to "deprecate" site local addresses. First, that consensus needs to be verified on the mailing list. Second, there was no agreement on what deprecation would entail. The FEC0:: address range could still be retained for completely disconnected networks. I think we will have a better understanding once the addressing architecture doc is updated and a site-local Informational/BCP draft is written. Regards, Brian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 13:49:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28686 for ; Mon, 24 Mar 2003 13:49:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OJ9Sr24482 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 14:09:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OItZO23243; Mon, 24 Mar 2003 13:55:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OIqHO23099 for ; Mon, 24 Mar 2003 13:52:17 -0500 Received: from ms-smtp-03.southeast.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28231 for ; Mon, 24 Mar 2003 13:31:51 -0500 (EST) Received: from mail3.nc.rr.com (fe3 [24.93.67.50]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2OIX0m0016591 for ; Mon, 24 Mar 2003 13:33:00 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 24 Mar 2003 13:31:52 -0500 Message-ID: <3E7F4FA0.3060107@nc.rr.com> From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 13:34:08 -0500 Content-Transfer-Encoding: 7bit Manfredi, Albert E wrote: > Tony Li wrote: > > >> Yes, obviously the architecture SHOULD be able to support NAT, and >> it clearly does. However, we do NOT have to actively support NAT, >> especially when support of NAT eliminates the only true need for >> v6. > > > Tony, > > You said a mouthful in that last sentence. Too bad IPv6 couldn't have > been simply an application of (perhaps) NSAP Addresses to IPv4. > > I'm still not clear why a well-defined private address space is > considered useless with IPv6. If I use the global address space in a > private network, or worse in many private networks that I configured > identically, and somehow one or more of these gets inadvertently > connected to the Internet, wouldn't it be easier to have a > well-defined address space that all routers would by default NOT > route? > > The argument that 128-bit addresses are enough for everyone does not > preclude the point that these addresses must still be unique. Perhaps > I'm missing the whole story, since I wasn't at the meeting. I think we have jumped the gun here a little bit. The tentative consensus in the IPv6 WG meeting was to "deprecate" site local addresses. First, that consensus needs to be verified on the mailing list. Second, there was no agreement on what deprecation would entail. The FEC0:: address range could still be retained for completely disconnected networks. I think we will have a better understanding once the addressing architecture doc is updated and a site-local Informational/BCP draft is written. Regards, Brian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 17:19:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05912 for ; Mon, 24 Mar 2003 17:19:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMUAO05286; Mon, 24 Mar 2003 17:30:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMQmO05165 for ; Mon, 24 Mar 2003 17:26:48 -0500 Received: from slb-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05556 for ; Mon, 24 Mar 2003 17:06:16 -0500 (EST) Received: from blv-av-02.boeing.com ([192.42.227.217]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA17245 for ; Mon, 24 Mar 2003 14:08:17 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id OAA26635 for ; Mon, 24 Mar 2003 14:08:33 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2OM8SH28504 for ; Mon, 24 Mar 2003 14:08:28 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 17:08:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLyNIzkRrQtHDfLQHS7asfcHj+VewAGe5kg From: "Manfredi, Albert E" To: X-OriginalArrivalTime: 24 Mar 2003 22:08:27.0667 (UTC) FILETIME=[E5838630:01C2F251] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OMQmO05166 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:08:27 -0500 Content-Transfer-Encoding: 8bit About RFC 1627 ... The reasons for using a private address space, as in RFC 1597/1918, is not JUST to economize on address space. Similarly, the use of NATs is not JUST to extend the life of a 32-bit address space. Here's the telling quote from RFC 1627: ----------- The IP version 4 (IPv4) address space will be exhausted. The question is simply: when? If we assert that all IP addresses must be unique globally, connected or not, then we will run out of IP address space soon. If we assert that only IP addresses used on the world-wide Internet need to be globally unique, then we will run out of IP address space later. It is absolutely key to keep the Internet community's attention focused on the efforts toward IP next generation (IPng), so that we may transcend the limitations of IPv4. RFC 1597 produces apparent relief from IPv4 address space exhaustion by masking those networks that are not connecting to the Internet, today. ----------- RFC 1918 and NATs can also be used to configure small networks the same, then avoid renumbering these networks when/if they are connected to the Internet. A 1:1 relationship between IP addresses on either side of the NAT can be implemented. (That is, you're not using the Port ID field as a kludgey extension of the IP address field.) The arguments of RFC 1627 really emphasize the economizing of address space as motivation for using the private address space. Not always germaine, IMO. But anyway, as long as the FECO:: continues to exist, all should work out. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 17:20:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05950 for ; Mon, 24 Mar 2003 17:20:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OMeK706570 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 17:40:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMUAO05286; Mon, 24 Mar 2003 17:30:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMQmO05165 for ; Mon, 24 Mar 2003 17:26:48 -0500 Received: from slb-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05556 for ; Mon, 24 Mar 2003 17:06:16 -0500 (EST) Received: from blv-av-02.boeing.com ([192.42.227.217]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA17245 for ; Mon, 24 Mar 2003 14:08:17 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id OAA26635 for ; Mon, 24 Mar 2003 14:08:33 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2OM8SH28504 for ; Mon, 24 Mar 2003 14:08:28 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 17:08:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLyNIzkRrQtHDfLQHS7asfcHj+VewAGe5kg From: "Manfredi, Albert E" To: X-OriginalArrivalTime: 24 Mar 2003 22:08:27.0667 (UTC) FILETIME=[E5838630:01C2F251] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OMQmO05166 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:08:27 -0500 Content-Transfer-Encoding: 8bit About RFC 1627 ... The reasons for using a private address space, as in RFC 1597/1918, is not JUST to economize on address space. Similarly, the use of NATs is not JUST to extend the life of a 32-bit address space. Here's the telling quote from RFC 1627: ----------- The IP version 4 (IPv4) address space will be exhausted. The question is simply: when? If we assert that all IP addresses must be unique globally, connected or not, then we will run out of IP address space soon. If we assert that only IP addresses used on the world-wide Internet need to be globally unique, then we will run out of IP address space later. It is absolutely key to keep the Internet community's attention focused on the efforts toward IP next generation (IPng), so that we may transcend the limitations of IPv4. RFC 1597 produces apparent relief from IPv4 address space exhaustion by masking those networks that are not connecting to the Internet, today. ----------- RFC 1918 and NATs can also be used to configure small networks the same, then avoid renumbering these networks when/if they are connected to the Internet. A 1:1 relationship between IP addresses on either side of the NAT can be implemented. (That is, you're not using the Port ID field as a kludgey extension of the IP address field.) The arguments of RFC 1627 really emphasize the economizing of address space as motivation for using the private address space. Not always germaine, IMO. But anyway, as long as the FECO:: continues to exist, all should work out. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 17:37:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06493 for ; Mon, 24 Mar 2003 17:37:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMmpO06866; Mon, 24 Mar 2003 17:48:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMjsO06773 for ; Mon, 24 Mar 2003 17:45:54 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06071 for ; Mon, 24 Mar 2003 17:25:22 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id B6D4734437; Mon, 24 Mar 2003 13:40:52 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2OMRfYB011120; Mon, 24 Mar 2003 14:27:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLx7mEOEwwlFejSTAqrOHM/TpeUrwAP0mYwAAB60NAACPX94A== From: "Tony Li" To: "Manfredi, Albert E" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OMjsO06774 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 14:27:41 -0800 Content-Transfer-Encoding: 8bit The argument for why they're not necessary is quite simple: 1) If the site is not connected, then use any number space to begin with. When the site connects, renumber. Note that if you had a defined address space, you would STILL be renumbering, so the special address didn't do anything for you. 2) If the site is connected, then the real benefit out of site local addressing is to support NAT. NAT is not necessary so you don't need an address space to support it. Tony | -----Original Message----- | From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] | Sent: Monday, March 24, 2003 10:13 AM | To: Tony Li | Cc: routing-discussion@ietf.org | Subject: RE: IPv6 site-locals... end of story... | | | Tony Li wrote: | | > Yes, obviously the architecture SHOULD be able to support NAT, | > and it clearly does. However, we do NOT have to actively | > support NAT, especially when support of NAT eliminates the | > only true need for v6. | | Tony, | | You said a mouthful in that last sentence. Too bad IPv6 | couldn't have been simply an application of (perhaps) NSAP | Addresses to IPv4. | | I'm still not clear why a well-defined private address | space is considered useless with IPv6. If I use the global | address space in a private network, or worse in many | private networks that I configured identically, and | somehow one or more of these gets inadvertently connected | to the Internet, wouldn't it be easier to have a | well-defined address space that all routers would by | default NOT route? | | The argument that 128-bit addresses are enough for | everyone does not preclude the point that these addresses | must still be unique. Perhaps I'm missing the whole story, | since I wasn't at the meeting. | | Bert | _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 17:38:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06528 for ; Mon, 24 Mar 2003 17:38:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OMwKI07379 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 17:58:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMmpO06866; Mon, 24 Mar 2003 17:48:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMjsO06773 for ; Mon, 24 Mar 2003 17:45:54 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06071 for ; Mon, 24 Mar 2003 17:25:22 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id B6D4734437; Mon, 24 Mar 2003 13:40:52 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2OMRfYB011120; Mon, 24 Mar 2003 14:27:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLx7mEOEwwlFejSTAqrOHM/TpeUrwAP0mYwAAB60NAACPX94A== From: "Tony Li" To: "Manfredi, Albert E" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OMjsO06774 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 14:27:41 -0800 Content-Transfer-Encoding: 8bit The argument for why they're not necessary is quite simple: 1) If the site is not connected, then use any number space to begin with. When the site connects, renumber. Note that if you had a defined address space, you would STILL be renumbering, so the special address didn't do anything for you. 2) If the site is connected, then the real benefit out of site local addressing is to support NAT. NAT is not necessary so you don't need an address space to support it. Tony | -----Original Message----- | From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] | Sent: Monday, March 24, 2003 10:13 AM | To: Tony Li | Cc: routing-discussion@ietf.org | Subject: RE: IPv6 site-locals... end of story... | | | Tony Li wrote: | | > Yes, obviously the architecture SHOULD be able to support NAT, | > and it clearly does. However, we do NOT have to actively | > support NAT, especially when support of NAT eliminates the | > only true need for v6. | | Tony, | | You said a mouthful in that last sentence. Too bad IPv6 | couldn't have been simply an application of (perhaps) NSAP | Addresses to IPv4. | | I'm still not clear why a well-defined private address | space is considered useless with IPv6. If I use the global | address space in a private network, or worse in many | private networks that I configured identically, and | somehow one or more of these gets inadvertently connected | to the Internet, wouldn't it be easier to have a | well-defined address space that all routers would by | default NOT route? | | The argument that 128-bit addresses are enough for | everyone does not preclude the point that these addresses | must still be unique. Perhaps I'm missing the whole story, | since I wasn't at the meeting. | | Bert | _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 17:48:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06739 for ; Mon, 24 Mar 2003 17:48:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMxHO07425; Mon, 24 Mar 2003 17:59:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMuVO07328 for ; Mon, 24 Mar 2003 17:56:31 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06457 for ; Mon, 24 Mar 2003 17:35:59 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 9871334437; Mon, 24 Mar 2003 13:51:31 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2OMcJYB011609; Mon, 24 Mar 2003 14:38:19 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLyNIzkRrQtHDfLQHS7asfcHj+VewAGe5kgAAHiXfA= From: "Tony Li" To: "Manfredi, Albert E" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OMuWO07329 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 14:38:19 -0800 Content-Transfer-Encoding: 8bit If we need to economize on v6 address space, then it isn't big enough. Tony | -----Original Message----- | From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] | Sent: Monday, March 24, 2003 2:08 PM | To: routing-discussion@ietf.org | Subject: RE: IPv6 site-locals... end of story... | | | About RFC 1627 ... | | The reasons for using a private address space, as in RFC | 1597/1918, is not JUST to economize on address space. | Similarly, the use of NATs is not JUST to extend the life | of a 32-bit address space. | | Here's the telling quote from RFC 1627: | | ----------- | The IP version 4 (IPv4) address space will be exhausted. The | question is simply: when? | | If we assert that all IP addresses must be unique | globally, connected | or not, then we will run out of IP address space soon. | | If we assert that only IP addresses used on the | world-wide Internet | need to be globally unique, then we will run out of IP | address space | later. | | It is absolutely key to keep the Internet community's attention | focused on the efforts toward IP next generation | (IPng), so that we | may transcend the limitations of IPv4. RFC 1597 | produces apparent | relief from IPv4 address space exhaustion by masking | those networks | that are not connecting to the Internet, today. | ----------- | | RFC 1918 and NATs can also be used to configure small | networks the same, then avoid renumbering these networks | when/if they are connected to the Internet. A 1:1 | relationship between IP addresses on either side of the | NAT can be implemented. (That is, you're not using the | Port ID field as a kludgey extension of the IP address field.) | | The arguments of RFC 1627 really emphasize the economizing | of address space as motivation for using the private | address space. Not always germaine, IMO. But anyway, as | long as the FECO:: continues to exist, all should work out. | | Bert | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 17:49:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06804 for ; Mon, 24 Mar 2003 17:49:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ON9O208716 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 18:09:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMxHO07425; Mon, 24 Mar 2003 17:59:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMuVO07328 for ; Mon, 24 Mar 2003 17:56:31 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06457 for ; Mon, 24 Mar 2003 17:35:59 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 9871334437; Mon, 24 Mar 2003 13:51:31 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2OMcJYB011609; Mon, 24 Mar 2003 14:38:19 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLyNIzkRrQtHDfLQHS7asfcHj+VewAGe5kgAAHiXfA= From: "Tony Li" To: "Manfredi, Albert E" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2OMuWO07329 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 14:38:19 -0800 Content-Transfer-Encoding: 8bit If we need to economize on v6 address space, then it isn't big enough. Tony | -----Original Message----- | From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] | Sent: Monday, March 24, 2003 2:08 PM | To: routing-discussion@ietf.org | Subject: RE: IPv6 site-locals... end of story... | | | About RFC 1627 ... | | The reasons for using a private address space, as in RFC | 1597/1918, is not JUST to economize on address space. | Similarly, the use of NATs is not JUST to extend the life | of a 32-bit address space. | | Here's the telling quote from RFC 1627: | | ----------- | The IP version 4 (IPv4) address space will be exhausted. The | question is simply: when? | | If we assert that all IP addresses must be unique | globally, connected | or not, then we will run out of IP address space soon. | | If we assert that only IP addresses used on the | world-wide Internet | need to be globally unique, then we will run out of IP | address space | later. | | It is absolutely key to keep the Internet community's attention | focused on the efforts toward IP next generation | (IPng), so that we | may transcend the limitations of IPv4. RFC 1597 | produces apparent | relief from IPv4 address space exhaustion by masking | those networks | that are not connecting to the Internet, today. | ----------- | | RFC 1918 and NATs can also be used to configure small | networks the same, then avoid renumbering these networks | when/if they are connected to the Internet. A 1:1 | relationship between IP addresses on either side of the | NAT can be implemented. (That is, you're not using the | Port ID field as a kludgey extension of the IP address field.) | | The arguments of RFC 1627 really emphasize the economizing | of address space as motivation for using the private | address space. Not always germaine, IMO. But anyway, as | long as the FECO:: continues to exist, all should work out. | | Bert | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 17:58:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07286 for ; Mon, 24 Mar 2003 17:58:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONBJO08784; Mon, 24 Mar 2003 18:11:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N7DAO13602 for ; Sun, 23 Mar 2003 02:13:10 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14779 for ; Sun, 23 Mar 2003 01:53:27 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id BD7D7137F02; Sat, 22 Mar 2003 22:55:44 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: routing-discussion@ietf.org To: Daniel Senie From: David Conrad In-Reply-To: <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> Message-Id: <7714DDD4-5CFC-11D7-ADB1-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Mar 2003 22:55:43 -0800 Content-Transfer-Encoding: 7bit Daniel, On Saturday, March 22, 2003, at 06:47 PM, Daniel Senie wrote: >> Do what we did before private addresses were declared - use public >> ones and not announce them to the routing system was a common >> solution in the late 80's. It appeared to work at the time. > And resulted in a major mess for many folk when networks were linked > to the public network. The people who used _registered_ public address space, of course, did not run into a mess. Of course, these were the bogs that became the IPv4 swamp, but there was plenty of address space at the time... Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 17:59:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07371 for ; Mon, 24 Mar 2003 17:59:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ONJlX09420 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 18:19:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONBJO08784; Mon, 24 Mar 2003 18:11:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N7DAO13602 for ; Sun, 23 Mar 2003 02:13:10 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14779 for ; Sun, 23 Mar 2003 01:53:27 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id BD7D7137F02; Sat, 22 Mar 2003 22:55:44 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: routing-discussion@ietf.org To: Daniel Senie From: David Conrad In-Reply-To: <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> Message-Id: <7714DDD4-5CFC-11D7-ADB1-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Mar 2003 22:55:43 -0800 Content-Transfer-Encoding: 7bit Daniel, On Saturday, March 22, 2003, at 06:47 PM, Daniel Senie wrote: >> Do what we did before private addresses were declared - use public >> ones and not announce them to the routing system was a common >> solution in the late 80's. It appeared to work at the time. > And resulted in a major mess for many folk when networks were linked > to the public network. The people who used _registered_ public address space, of course, did not run into a mess. Of course, these were the bogs that became the IPv4 swamp, but there was plenty of address space at the time... Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 18:01:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07435 for ; Mon, 24 Mar 2003 18:01:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON9CO08655; Mon, 24 Mar 2003 18:09:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON1aO07562 for ; Mon, 24 Mar 2003 18:01:36 -0500 Received: from blv-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06577 for ; Mon, 24 Mar 2003 17:41:03 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA02812; Mon, 24 Mar 2003 14:43:22 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id QAA00354; Mon, 24 Mar 2003 16:43:21 -0600 (CST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2OMhJH12303; Mon, 24 Mar 2003 14:43:19 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 17:43:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLx7mEOEwwlFejSTAqrOHM/TpeUrwAP0mYwAAB60NAACPX94AAAYK0A From: "Manfredi, Albert E" To: "Tony Li" Cc: X-OriginalArrivalTime: 24 Mar 2003 22:43:18.0689 (UTC) FILETIME=[C3DC2910:01C2F256] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2ON1aO07563 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:43:18 -0500 Content-Transfer-Encoding: 8bit Tony Li wrote: > 1) If the site is not connected, then use any number space to begin > with. When the site connects, renumber. Sure enough. However, it is far safer to provide an *obviously* private address to something that must be renumbered, instead of configuring this device (or network) with addresses that appear globally unique already. (Has this thing already been renumbered?) > 2) If the site is connected, then the real benefit out of site > local addressing is to support NAT. NAT is not necessary so you > don't need an address space to support it. Sure it is. Take the case of IP being used in specific control systems. In factory control systems, for example, or in individual platforms. Often, these would be peer-peer networks, where DHCP might not be the answer. The systems are preconfigured, at the factory, pre-tested, and all look alike. They are pumped out by the hundreds. When they are installed, wherever that might be, they can then be connected to the Internet or local intranet. The most trouble-free way of doing this could very well be to install edge routers that provide the NAT function. This is *not* to economize on address space. It is to facilitate the manufacture and installation, and maintenance (customer support), of entire IP-based systems. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 18:02:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07453 for ; Mon, 24 Mar 2003 18:02:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ONMUp09730 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 18:22:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON9CO08655; Mon, 24 Mar 2003 18:09:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON1aO07562 for ; Mon, 24 Mar 2003 18:01:36 -0500 Received: from blv-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06577 for ; Mon, 24 Mar 2003 17:41:03 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA02812; Mon, 24 Mar 2003 14:43:22 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id QAA00354; Mon, 24 Mar 2003 16:43:21 -0600 (CST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2OMhJH12303; Mon, 24 Mar 2003 14:43:19 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 17:43:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLx7mEOEwwlFejSTAqrOHM/TpeUrwAP0mYwAAB60NAACPX94AAAYK0A From: "Manfredi, Albert E" To: "Tony Li" Cc: X-OriginalArrivalTime: 24 Mar 2003 22:43:18.0689 (UTC) FILETIME=[C3DC2910:01C2F256] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2ON1aO07563 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:43:18 -0500 Content-Transfer-Encoding: 8bit Tony Li wrote: > 1) If the site is not connected, then use any number space to begin > with. When the site connects, renumber. Sure enough. However, it is far safer to provide an *obviously* private address to something that must be renumbered, instead of configuring this device (or network) with addresses that appear globally unique already. (Has this thing already been renumbered?) > 2) If the site is connected, then the real benefit out of site > local addressing is to support NAT. NAT is not necessary so you > don't need an address space to support it. Sure it is. Take the case of IP being used in specific control systems. In factory control systems, for example, or in individual platforms. Often, these would be peer-peer networks, where DHCP might not be the answer. The systems are preconfigured, at the factory, pre-tested, and all look alike. They are pumped out by the hundreds. When they are installed, wherever that might be, they can then be connected to the Internet or local intranet. The most trouble-free way of doing this could very well be to install edge routers that provide the NAT function. This is *not* to economize on address space. It is to facilitate the manufacture and installation, and maintenance (customer support), of entire IP-based systems. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 18:05:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07871 for ; Mon, 24 Mar 2003 18:05:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONDNO08876; Mon, 24 Mar 2003 18:13:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NK6WO23865 for ; Sun, 23 Mar 2003 15:06:32 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08034 for ; Sun, 23 Mar 2003 14:46:33 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 34579137F04; Sun, 23 Mar 2003 11:48:51 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Daniel Senie , routing-discussion@ietf.org To: Eliot Lear From: David Conrad In-Reply-To: <3E7DFC47.9090800@cisco.com> Message-Id: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 11:48:50 -0800 Content-Transfer-Encoding: 7bit Elliot, On Sunday, March 23, 2003, at 10:26 AM, Eliot Lear wrote: > This belies the notion of an engineering trade-off. There is no > reason to create an architectural mess by saving an address here or > there. Who cares about individual addresses? It is the prefixes entering (and exiting) the routing system that matter. > We have 2^128 of them to use. This is equivalent to saying IPv4 has 2^32 addresses to use. While arguably true, it is irrelevant From a routing perspective, we have at best 2^64 individually routable objects. In reality, we have less as we have been eating from both sides of the routing prefix space (e.g., format specifier, local site routing goop, etc). > Registries should see that this is the case. Last I heard, using the current allocation approach we theoretically have 281,474,976,710,656 potential routing prefixes. Given we have so many, there are some who believe we should go back to the "get a public prefix from the registries even if you don't plan on connecting that prefix to the Internet" approach used back in the early days. Solves the private address space problem of merging companies nicely. Unfortunately, of course, without a revolutionary advance in renumbering or routing, this approach _guarantees_ IPv6 NAT when ISPs start worrying about their IPv6 routing tables. From a routing perspective, folks should get their v6 prefix from their upstream service provider(s). However, again without a revolutionary advance in renumbering or routing, this approach also guarantees IPv6 NAT as very few companies like to be held hostage by their address space. Seems to me the choice is whether or not we want to consume some of the 281,474,976,710,656 prefixes for networks that will, in the end, be NAT'ed. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 18:06:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08085 for ; Mon, 24 Mar 2003 18:06:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ONQqD09896 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 18:26:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONDNO08876; Mon, 24 Mar 2003 18:13:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2NK6WO23865 for ; Sun, 23 Mar 2003 15:06:32 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08034 for ; Sun, 23 Mar 2003 14:46:33 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 34579137F04; Sun, 23 Mar 2003 11:48:51 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Daniel Senie , routing-discussion@ietf.org To: Eliot Lear From: David Conrad In-Reply-To: <3E7DFC47.9090800@cisco.com> Message-Id: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 23 Mar 2003 11:48:50 -0800 Content-Transfer-Encoding: 7bit Elliot, On Sunday, March 23, 2003, at 10:26 AM, Eliot Lear wrote: > This belies the notion of an engineering trade-off. There is no > reason to create an architectural mess by saving an address here or > there. Who cares about individual addresses? It is the prefixes entering (and exiting) the routing system that matter. > We have 2^128 of them to use. This is equivalent to saying IPv4 has 2^32 addresses to use. While arguably true, it is irrelevant From a routing perspective, we have at best 2^64 individually routable objects. In reality, we have less as we have been eating from both sides of the routing prefix space (e.g., format specifier, local site routing goop, etc). > Registries should see that this is the case. Last I heard, using the current allocation approach we theoretically have 281,474,976,710,656 potential routing prefixes. Given we have so many, there are some who believe we should go back to the "get a public prefix from the registries even if you don't plan on connecting that prefix to the Internet" approach used back in the early days. Solves the private address space problem of merging companies nicely. Unfortunately, of course, without a revolutionary advance in renumbering or routing, this approach _guarantees_ IPv6 NAT when ISPs start worrying about their IPv6 routing tables. From a routing perspective, folks should get their v6 prefix from their upstream service provider(s). However, again without a revolutionary advance in renumbering or routing, this approach also guarantees IPv6 NAT as very few companies like to be held hostage by their address space. Seems to me the choice is whether or not we want to consume some of the 281,474,976,710,656 prefixes for networks that will, in the end, be NAT'ed. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 18:12:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08823 for ; Mon, 24 Mar 2003 18:12:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONJGO09364; Mon, 24 Mar 2003 18:19:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONEdO08966 for ; Mon, 24 Mar 2003 18:14:39 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07020 for ; Mon, 24 Mar 2003 17:54:07 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id C328923C5F; Mon, 24 Mar 2003 14:46:31 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2OMuQYB012152; Mon, 24 Mar 2003 14:56:26 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLx7mEOEwwlFejSTAqrOHM/TpeUrwAP0mYwAAB60NAACPX94AAAYK0AAADhQUA= From: "Tony Li" To: "Manfredi, Albert E" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2ONEeO08967 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 14:56:26 -0800 Content-Transfer-Encoding: 8bit | Sure enough. However, it is far safer to provide an | *obviously* private address to something that must be | renumbered, instead of configuring this device (or | network) with addresses that appear globally unique | already. (Has this thing already been renumbered?) Unless someone is accepting routing advertisements from them and not filtering, this is not dangerous. The packet should be simply dropped at the provider edge. | > 2) If the site is connected, then the real benefit out of site | > local addressing is to support NAT. NAT is not necessary so you | > don't need an address space to support it. | | Sure it is. | | Take the case of IP being used in specific control | systems. In factory control systems, for example, or in | individual platforms. Often, these would be peer-peer | networks, where DHCP might not be the answer. | | The systems are preconfigured, at the factory, pre-tested, | and all look alike. They are pumped out by the hundreds. | | When they are installed, wherever that might be, they can | then be connected to the Internet or local intranet. The | most trouble-free way of doing this could very well be to | install edge routers that provide the NAT function. This | is *not* to economize on address space. It is to | facilitate the manufacture and installation, and | maintenance (customer support), of entire IP-based systems. IPv6 autoconfiguration. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 18:13:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08941 for ; Mon, 24 Mar 2003 18:13:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ONX5k10176 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 18:33:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONJGO09364; Mon, 24 Mar 2003 18:19:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONEdO08966 for ; Mon, 24 Mar 2003 18:14:39 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07020 for ; Mon, 24 Mar 2003 17:54:07 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id C328923C5F; Mon, 24 Mar 2003 14:46:31 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2OMuQYB012152; Mon, 24 Mar 2003 14:56:26 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLx7mEOEwwlFejSTAqrOHM/TpeUrwAP0mYwAAB60NAACPX94AAAYK0AAADhQUA= From: "Tony Li" To: "Manfredi, Albert E" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2ONEeO08967 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 14:56:26 -0800 Content-Transfer-Encoding: 8bit | Sure enough. However, it is far safer to provide an | *obviously* private address to something that must be | renumbered, instead of configuring this device (or | network) with addresses that appear globally unique | already. (Has this thing already been renumbered?) Unless someone is accepting routing advertisements from them and not filtering, this is not dangerous. The packet should be simply dropped at the provider edge. | > 2) If the site is connected, then the real benefit out of site | > local addressing is to support NAT. NAT is not necessary so you | > don't need an address space to support it. | | Sure it is. | | Take the case of IP being used in specific control | systems. In factory control systems, for example, or in | individual platforms. Often, these would be peer-peer | networks, where DHCP might not be the answer. | | The systems are preconfigured, at the factory, pre-tested, | and all look alike. They are pumped out by the hundreds. | | When they are installed, wherever that might be, they can | then be connected to the Internet or local intranet. The | most trouble-free way of doing this could very well be to | install edge routers that provide the NAT function. This | is *not* to economize on address space. It is to | facilitate the manufacture and installation, and | maintenance (customer support), of entire IP-based systems. IPv6 autoconfiguration. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 19:06:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10550 for ; Mon, 24 Mar 2003 19:06:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0DAO12847; Mon, 24 Mar 2003 19:13:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P098O12748 for ; Mon, 24 Mar 2003 19:09:08 -0500 Received: from garlic.amaranth.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10039 for ; Mon, 24 Mar 2003 18:48:34 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id h2ONor932090 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 24 Mar 2003 18:50:53 -0500 Message-Id: <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: From: Daniel Senie Subject: RE: IPv6 site-locals... end of story... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 18:48:55 -0500 At 05:27 PM 3/24/2003, Tony Li wrote: >The argument for why they're not necessary is quite simple: > >1) If the site is not connected, then use any number space to begin >with. When the site connects, renumber. Note that if you had a >defined address space, you would STILL be renumbering, so the special >address didn't do anything for you. > >2) If the site is connected, then the real benefit out of site >local addressing is to support NAT. NAT is not necessary so you >don't need an address space to support it. Tony, I disagree that these two are it. Example: I run a colo with two interfaces per server. Public interface of each server has a public address. Second interface has an RFC1918 address. The second interface is used for backups, inter-server database connectivity, NFS, etc. Tell me why I should waste public space on that? Explain how I justify that space when asking for a subnet from an upstream, when that space isn't going to EVER be connected to the public network. There's no NAT here. There's no public connection. HOWEVER, it is CRITICALLY important that the address space used for the private network not conflict with any public address space. Maybe I just do really odd things with my server configurations, but I somehow doubt I'm the only one who does such things. Tying private address space to NAT does not tell the whole story. Dan _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 19:07:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10581 for ; Mon, 24 Mar 2003 19:07:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0RQq13571 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 19:27:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0DAO12847; Mon, 24 Mar 2003 19:13:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P098O12748 for ; Mon, 24 Mar 2003 19:09:08 -0500 Received: from garlic.amaranth.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10039 for ; Mon, 24 Mar 2003 18:48:34 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id h2ONor932090 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 24 Mar 2003 18:50:53 -0500 Message-Id: <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: From: Daniel Senie Subject: RE: IPv6 site-locals... end of story... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 18:48:55 -0500 At 05:27 PM 3/24/2003, Tony Li wrote: >The argument for why they're not necessary is quite simple: > >1) If the site is not connected, then use any number space to begin >with. When the site connects, renumber. Note that if you had a >defined address space, you would STILL be renumbering, so the special >address didn't do anything for you. > >2) If the site is connected, then the real benefit out of site >local addressing is to support NAT. NAT is not necessary so you >don't need an address space to support it. Tony, I disagree that these two are it. Example: I run a colo with two interfaces per server. Public interface of each server has a public address. Second interface has an RFC1918 address. The second interface is used for backups, inter-server database connectivity, NFS, etc. Tell me why I should waste public space on that? Explain how I justify that space when asking for a subnet from an upstream, when that space isn't going to EVER be connected to the public network. There's no NAT here. There's no public connection. HOWEVER, it is CRITICALLY important that the address space used for the private network not conflict with any public address space. Maybe I just do really odd things with my server configurations, but I somehow doubt I'm the only one who does such things. Tying private address space to NAT does not tell the whole story. Dan _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 19:14:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10714 for ; Mon, 24 Mar 2003 19:14:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0MAO13256; Mon, 24 Mar 2003 19:22:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0J1O13116 for ; Mon, 24 Mar 2003 19:19:01 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10229 for ; Mon, 24 Mar 2003 18:58:27 -0500 (EST) Received: from cisco.com (sjc-vpn2-127.cisco.com [10.21.112.127]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA08626; Mon, 24 Mar 2003 16:00:45 -0800 (PST) Message-ID: <3E7F9C2C.2010700@cisco.com> From: Eliot Lear 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: Daniel Senie CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net> In-Reply-To: <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 16:00:44 -0800 Content-Transfer-Encoding: 7bit Daniel Senie wrote: > Example: I run a colo with two interfaces per server. Public interface > of each server has a public address. Second interface has an RFC1918 > address. The second interface is used for backups, inter-server database > connectivity, NFS, etc. Tell me why I should waste public space on that? > Explain how I justify that space when asking for a subnet from an > upstream, when that space isn't going to EVER be connected to the public > network. Because this is like wasting sand in the desert. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 19:15:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10747 for ; Mon, 24 Mar 2003 19:15:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0Zfg13887 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 19:35:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0MAO13256; Mon, 24 Mar 2003 19:22:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0J1O13116 for ; Mon, 24 Mar 2003 19:19:01 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10229 for ; Mon, 24 Mar 2003 18:58:27 -0500 (EST) Received: from cisco.com (sjc-vpn2-127.cisco.com [10.21.112.127]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA08626; Mon, 24 Mar 2003 16:00:45 -0800 (PST) Message-ID: <3E7F9C2C.2010700@cisco.com> From: Eliot Lear 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: Daniel Senie CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net> In-Reply-To: <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 16:00:44 -0800 Content-Transfer-Encoding: 7bit Daniel Senie wrote: > Example: I run a colo with two interfaces per server. Public interface > of each server has a public address. Second interface has an RFC1918 > address. The second interface is used for backups, inter-server database > connectivity, NFS, etc. Tell me why I should waste public space on that? > Explain how I justify that space when asking for a subnet from an > upstream, when that space isn't going to EVER be connected to the public > network. Because this is like wasting sand in the desert. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 19:30:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11099 for ; Mon, 24 Mar 2003 19:30:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0bIO14386; Mon, 24 Mar 2003 19:37:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0Y1O13833 for ; Mon, 24 Mar 2003 19:34:02 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10699 for ; Mon, 24 Mar 2003 19:13:29 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id BFC1C23C49; Mon, 24 Mar 2003 16:05:51 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2P0FlYB014864; Mon, 24 Mar 2003 16:15:47 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLyYsl2BhGhEwjpQjS6cYtjeiUbUgAALdIQ From: "Tony Li" To: "Daniel Senie" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2P0Y2O13838 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 16:15:47 -0800 Content-Transfer-Encoding: 8bit Sounds like a fine justification for a /48 or /64 to me. The waste should not be an issue as long as the address space that you are allocated is something that you use efficiently. Tony | -----Original Message----- | From: Daniel Senie [mailto:dts@senie.com] | Sent: Monday, March 24, 2003 3:49 PM | To: routing-discussion@ietf.org | Subject: RE: IPv6 site-locals... end of story... | | | At 05:27 PM 3/24/2003, Tony Li wrote: | | | | >The argument for why they're not necessary is quite simple: | > | >1) If the site is not connected, then use any number | space to begin | >with. When the site connects, renumber. Note that if you had a | >defined address space, you would STILL be renumbering, so | the special | >address didn't do anything for you. | > | >2) If the site is connected, then the real benefit out of site | >local addressing is to support NAT. NAT is not necessary so you | >don't need an address space to support it. | | Tony, I disagree that these two are it. | | Example: I run a colo with two interfaces per server. | Public interface of | each server has a public address. Second interface has an | RFC1918 address. | The second interface is used for backups, inter-server database | connectivity, NFS, etc. Tell me why I should waste public | space on that? | Explain how I justify that space when asking for a subnet | from an upstream, | when that space isn't going to EVER be connected to the | public network. | | There's no NAT here. There's no public connection. HOWEVER, it is | CRITICALLY important that the address space used for the | private network | not conflict with any public address space. | | Maybe I just do really odd things with my server | configurations, but I | somehow doubt I'm the only one who does such things. Tying | private address | space to NAT does not tell the whole story. | | Dan | | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 19:31:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11135 for ; Mon, 24 Mar 2003 19:31:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P0put15305 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 19:51:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0bIO14386; Mon, 24 Mar 2003 19:37:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P0Y1O13833 for ; Mon, 24 Mar 2003 19:34:02 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10699 for ; Mon, 24 Mar 2003 19:13:29 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id BFC1C23C49; Mon, 24 Mar 2003 16:05:51 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2P0FlYB014864; Mon, 24 Mar 2003 16:15:47 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLyYsl2BhGhEwjpQjS6cYtjeiUbUgAALdIQ From: "Tony Li" To: "Daniel Senie" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2P0Y2O13838 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 16:15:47 -0800 Content-Transfer-Encoding: 8bit Sounds like a fine justification for a /48 or /64 to me. The waste should not be an issue as long as the address space that you are allocated is something that you use efficiently. Tony | -----Original Message----- | From: Daniel Senie [mailto:dts@senie.com] | Sent: Monday, March 24, 2003 3:49 PM | To: routing-discussion@ietf.org | Subject: RE: IPv6 site-locals... end of story... | | | At 05:27 PM 3/24/2003, Tony Li wrote: | | | | >The argument for why they're not necessary is quite simple: | > | >1) If the site is not connected, then use any number | space to begin | >with. When the site connects, renumber. Note that if you had a | >defined address space, you would STILL be renumbering, so | the special | >address didn't do anything for you. | > | >2) If the site is connected, then the real benefit out of site | >local addressing is to support NAT. NAT is not necessary so you | >don't need an address space to support it. | | Tony, I disagree that these two are it. | | Example: I run a colo with two interfaces per server. | Public interface of | each server has a public address. Second interface has an | RFC1918 address. | The second interface is used for backups, inter-server database | connectivity, NFS, etc. Tell me why I should waste public | space on that? | Explain how I justify that space when asking for a subnet | from an upstream, | when that space isn't going to EVER be connected to the | public network. | | There's no NAT here. There's no public connection. HOWEVER, it is | CRITICALLY important that the address space used for the | private network | not conflict with any public address space. | | Maybe I just do really odd things with my server | configurations, but I | somehow doubt I'm the only one who does such things. Tying | private address | space to NAT does not tell the whole story. | | Dan | | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 20:54:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13234 for ; Mon, 24 Mar 2003 20:54:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P21jO19460; Mon, 24 Mar 2003 21:01:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P1wqO19293 for ; Mon, 24 Mar 2003 20:58:52 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12840 for ; Mon, 24 Mar 2003 20:38:17 -0500 (EST) Received: by mail-blue.research.att.com (Postfix, from userid 612) id 4EDEAB7CFC; Mon, 24 Mar 2003 20:42:33 -0500 (EST) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mail-blue.research.att.com (Postfix) with ESMTP id F3FCFB7CC7; Mon, 24 Mar 2003 20:42:32 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h2P1e3Vq008083; Mon, 24 Mar 2003 20:40:03 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h2P1eYj26786; Mon, 24 Mar 2003 17:40:34 -0800 (PST) Message-Id: <200303250140.h2P1eYj26786@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: curtis@fictitious.org Subject: Re: Correct URL for Liasion statement Cc: routing-discussion@ietf.org Versions: dmail (solaris) 2.5a/makemail 2.9d X-Spam-Status: No, hits=-106.6 required=5.0 tests=BAYES_01,USER_IN_WHITELIST version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:40:34 -0800 Curtis, Sorry for the delay, I was kinda swamped during the meeting. I think all of the links are fixed. There was a typo on the IETF web site, and a bad PDF file on the ITU server, which were fixed as I discovered them. I'm able to read the statements and the documents starting at www.ietf.org and just clicking; the meat is at ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_routing.html (Although this link is past a page that wants me to promise that I won't disseminate this information outside of my organization, for this purpose I consider my organization to be the IETF.) The two PDF documents at the bottom are both readable in either adobe acrobat or GNU ghostscript. The upshot is that Q.14/15 is defining routing protocols for ASON networks, and they want the IETF's help to understand if they can re-use existing protocols e.g. ISIS or OSPF. There is an invitation to the Q.14/15 meeting in Chicago in June for those who are interested. Although the tendency is usually for the IETF to say "we're not interested in that work, go away", I'd like instead for us to at least understand what they want and provide IETF feedback on their plans. If we work together during the whole process it's much less likely that the end result will be something we want to kill. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 20:55:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13357 for ; Mon, 24 Mar 2003 20:55:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P2FT120985 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 21:15:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P21jO19460; Mon, 24 Mar 2003 21:01:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P1wqO19293 for ; Mon, 24 Mar 2003 20:58:52 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12840 for ; Mon, 24 Mar 2003 20:38:17 -0500 (EST) Received: by mail-blue.research.att.com (Postfix, from userid 612) id 4EDEAB7CFC; Mon, 24 Mar 2003 20:42:33 -0500 (EST) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mail-blue.research.att.com (Postfix) with ESMTP id F3FCFB7CC7; Mon, 24 Mar 2003 20:42:32 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h2P1e3Vq008083; Mon, 24 Mar 2003 20:40:03 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h2P1eYj26786; Mon, 24 Mar 2003 17:40:34 -0800 (PST) Message-Id: <200303250140.h2P1eYj26786@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: curtis@fictitious.org Subject: Re: Correct URL for Liasion statement Cc: routing-discussion@ietf.org Versions: dmail (solaris) 2.5a/makemail 2.9d X-Spam-Status: No, hits=-106.6 required=5.0 tests=BAYES_01,USER_IN_WHITELIST version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:40:34 -0800 Curtis, Sorry for the delay, I was kinda swamped during the meeting. I think all of the links are fixed. There was a typo on the IETF web site, and a bad PDF file on the ITU server, which were fixed as I discovered them. I'm able to read the statements and the documents starting at www.ietf.org and just clicking; the meat is at ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/ccamp/IETF_ccamp_routing.html (Although this link is past a page that wants me to promise that I won't disseminate this information outside of my organization, for this purpose I consider my organization to be the IETF.) The two PDF documents at the bottom are both readable in either adobe acrobat or GNU ghostscript. The upshot is that Q.14/15 is defining routing protocols for ASON networks, and they want the IETF's help to understand if they can re-use existing protocols e.g. ISIS or OSPF. There is an invitation to the Q.14/15 meeting in Chicago in June for those who are interested. Although the tendency is usually for the IETF to say "we're not interested in that work, go away", I'd like instead for us to at least understand what they want and provide IETF feedback on their plans. If we work together during the whole process it's much less likely that the end result will be something we want to kill. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 21:04:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13730 for ; Mon, 24 Mar 2003 21:04:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2C5O20588; Mon, 24 Mar 2003 21:12:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P29GO20501 for ; Mon, 24 Mar 2003 21:09:16 -0500 Received: from lakecmmtao01.coxmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13071 for ; Mon, 24 Mar 2003 20:48:41 -0500 (EST) Received: from acm.org ([68.15.42.104]) by lakecmmtao01.coxmail.com (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030325015059.LBJT25316.lakecmmtao01.coxmail.com@acm.org> for ; Mon, 24 Mar 2003 20:50:59 -0500 Message-ID: <3E7FB528.90608@acm.org> From: Avri Doria User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:47:20 -0800 Content-Transfer-Encoding: 7bit While it may not be necessary to economize with IP space in IPv6, there is nothing to prevent a local service provider from creating an artificial shortage that then allows them to charge me for every address I use in my home. Local addressing gives the user, i.e.. our silent majority, some means of fighting those who would make them pay for every address used. I believe that as long as this address monopoly exists, there will be users who will buy any device that gives them address freedom. So, it isn't the end of the story, just the end of a chapter. a. Tony Li wrote: > > > If we need to economize on v6 address space, then it isn't big enough. > > Tony > > > | -----Original Message----- > | From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > | Sent: Monday, March 24, 2003 2:08 PM > | To: routing-discussion@ietf.org > | Subject: RE: IPv6 site-locals... end of story... > | > | > | About RFC 1627 ... > | > | The reasons for using a private address space, as in RFC > | 1597/1918, is not JUST to economize on address space. > | Similarly, the use of NATs is not JUST to extend the life > | of a 32-bit address space. > | > | Here's the telling quote from RFC 1627: > | > | ----------- > | The IP version 4 (IPv4) address space will be exhausted. The > | question is simply: when? > | > | If we assert that all IP addresses must be unique > | globally, connected > | or not, then we will run out of IP address space soon. > | > | If we assert that only IP addresses used on the > | world-wide Internet > | need to be globally unique, then we will run out of IP > | address space > | later. > | > | It is absolutely key to keep the Internet community's attention > | focused on the efforts toward IP next generation > | (IPng), so that we > | may transcend the limitations of IPv4. RFC 1597 > | produces apparent > | relief from IPv4 address space exhaustion by masking > | those networks > | that are not connecting to the Internet, today. > | ----------- > | > | RFC 1918 and NATs can also be used to configure small > | networks the same, then avoid renumbering these networks > | when/if they are connected to the Internet. A 1:1 > | relationship between IP addresses on either side of the > | NAT can be implemented. (That is, you're not using the > | Port ID field as a kludgey extension of the IP address field.) > | > | The arguments of RFC 1627 really emphasize the economizing > | of address space as motivation for using the private > | address space. Not always germaine, IMO. But anyway, as > | long as the FECO:: continues to exist, all should work out. > | > | Bert > | _______________________________________________ > | routing-discussion mailing list > | routing-discussion@ietf.org > | https://www1.ietf.org/mailman/listinfo/routing-discussion > | > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 21:05:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13776 for ; Mon, 24 Mar 2003 21:05:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P2Pgr21583 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 21:25:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2C5O20588; Mon, 24 Mar 2003 21:12:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P29GO20501 for ; Mon, 24 Mar 2003 21:09:16 -0500 Received: from lakecmmtao01.coxmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13071 for ; Mon, 24 Mar 2003 20:48:41 -0500 (EST) Received: from acm.org ([68.15.42.104]) by lakecmmtao01.coxmail.com (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030325015059.LBJT25316.lakecmmtao01.coxmail.com@acm.org> for ; Mon, 24 Mar 2003 20:50:59 -0500 Message-ID: <3E7FB528.90608@acm.org> From: Avri Doria User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 17:47:20 -0800 Content-Transfer-Encoding: 7bit While it may not be necessary to economize with IP space in IPv6, there is nothing to prevent a local service provider from creating an artificial shortage that then allows them to charge me for every address I use in my home. Local addressing gives the user, i.e.. our silent majority, some means of fighting those who would make them pay for every address used. I believe that as long as this address monopoly exists, there will be users who will buy any device that gives them address freedom. So, it isn't the end of the story, just the end of a chapter. a. Tony Li wrote: > > > If we need to economize on v6 address space, then it isn't big enough. > > Tony > > > | -----Original Message----- > | From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > | Sent: Monday, March 24, 2003 2:08 PM > | To: routing-discussion@ietf.org > | Subject: RE: IPv6 site-locals... end of story... > | > | > | About RFC 1627 ... > | > | The reasons for using a private address space, as in RFC > | 1597/1918, is not JUST to economize on address space. > | Similarly, the use of NATs is not JUST to extend the life > | of a 32-bit address space. > | > | Here's the telling quote from RFC 1627: > | > | ----------- > | The IP version 4 (IPv4) address space will be exhausted. The > | question is simply: when? > | > | If we assert that all IP addresses must be unique > | globally, connected > | or not, then we will run out of IP address space soon. > | > | If we assert that only IP addresses used on the > | world-wide Internet > | need to be globally unique, then we will run out of IP > | address space > | later. > | > | It is absolutely key to keep the Internet community's attention > | focused on the efforts toward IP next generation > | (IPng), so that we > | may transcend the limitations of IPv4. RFC 1597 > | produces apparent > | relief from IPv4 address space exhaustion by masking > | those networks > | that are not connecting to the Internet, today. > | ----------- > | > | RFC 1918 and NATs can also be used to configure small > | networks the same, then avoid renumbering these networks > | when/if they are connected to the Internet. A 1:1 > | relationship between IP addresses on either side of the > | NAT can be implemented. (That is, you're not using the > | Port ID field as a kludgey extension of the IP address field.) > | > | The arguments of RFC 1627 really emphasize the economizing > | of address space as motivation for using the private > | address space. Not always germaine, IMO. But anyway, as > | long as the FECO:: continues to exist, all should work out. > | > | Bert > | _______________________________________________ > | routing-discussion mailing list > | routing-discussion@ietf.org > | https://www1.ietf.org/mailman/listinfo/routing-discussion > | > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 21:39:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14620 for ; Mon, 24 Mar 2003 21:39:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2kWO23371; Mon, 24 Mar 2003 21:46:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2h2O23252 for ; Mon, 24 Mar 2003 21:43:02 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14134 for ; Mon, 24 Mar 2003 21:22:25 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA08591; Mon, 24 Mar 2003 21:25:44 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250225.VAA08591@workhorse.fictitious.org> To: "Manfredi, Albert E" cc: "Tony Li" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Mon, 24 Mar 2003 17:43:18 EST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 21:25:44 -0500 In message , "Manfredi, Albert E" writes: > Tony Li wrote: > > > 1) If the site is not connected, then use any number space to begin > > with. When the site connects, renumber. > > Sure enough. However, it is far safer to provide an *obviously* private addre > ss to something that must be renumbered, instead of configuring this device ( > or network) with addresses that appear globally unique already. (Has this thi > ng already been renumbered?) > > > 2) If the site is connected, then the real benefit out of site > > local addressing is to support NAT. NAT is not necessary so you > > don't need an address space to support it. > > Sure it is. > > Take the case of IP being used in specific control systems. In factory contro > l systems, for example, or in individual platforms. Often, these would be pee > r-peer networks, where DHCP might not be the answer. > > The systems are preconfigured, at the factory, pre-tested, and all look alike > . They are pumped out by the hundreds. Kinda like small routers and it takes all of about a minute to initially configure them when they arive in the field, most of which is unpacking the box and the boot up time. So what's your point. We installed a thousand or so when I was at an ISP and we had machine generated configs. The boxes got shipped to us, a tech hand entered about 3 lines of config, enough for the box to be identified (and secure), and the full config was loaded, then the box got shipped to the field and installed by even less skilled techs. > When they are installed, wherever that might be, they can then be connected t > o the Internet or local intranet. The most trouble-free way of doing this cou > ld very well be to install edge routers that provide the NAT function. This i > s *not* to economize on address space. It is to facilitate the manufacture an > d installation, and maintenance (customer support), of entire IP-based system > s. NATs very much get in the way of peer-to-peer in case you weren't aware of that. Try running any kind of server behind a NAT and accessing it from outside the NAT. If two factory widgets are behind the same NAT they need unique addresses and you're back to DHCP or configured addresses. At any time during this process do SNMP communities and default passwords or any sort of encryption keys get changed or do they all stay at the factory settings too? > Bert Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 21:40:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14662 for ; Mon, 24 Mar 2003 21:40:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P30Vw24197 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 22:00:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2kWO23371; Mon, 24 Mar 2003 21:46:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2h2O23252 for ; Mon, 24 Mar 2003 21:43:02 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14134 for ; Mon, 24 Mar 2003 21:22:25 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA08591; Mon, 24 Mar 2003 21:25:44 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250225.VAA08591@workhorse.fictitious.org> To: "Manfredi, Albert E" cc: "Tony Li" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Mon, 24 Mar 2003 17:43:18 EST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 21:25:44 -0500 In message , "Manfredi, Albert E" writes: > Tony Li wrote: > > > 1) If the site is not connected, then use any number space to begin > > with. When the site connects, renumber. > > Sure enough. However, it is far safer to provide an *obviously* private addre > ss to something that must be renumbered, instead of configuring this device ( > or network) with addresses that appear globally unique already. (Has this thi > ng already been renumbered?) > > > 2) If the site is connected, then the real benefit out of site > > local addressing is to support NAT. NAT is not necessary so you > > don't need an address space to support it. > > Sure it is. > > Take the case of IP being used in specific control systems. In factory contro > l systems, for example, or in individual platforms. Often, these would be pee > r-peer networks, where DHCP might not be the answer. > > The systems are preconfigured, at the factory, pre-tested, and all look alike > . They are pumped out by the hundreds. Kinda like small routers and it takes all of about a minute to initially configure them when they arive in the field, most of which is unpacking the box and the boot up time. So what's your point. We installed a thousand or so when I was at an ISP and we had machine generated configs. The boxes got shipped to us, a tech hand entered about 3 lines of config, enough for the box to be identified (and secure), and the full config was loaded, then the box got shipped to the field and installed by even less skilled techs. > When they are installed, wherever that might be, they can then be connected t > o the Internet or local intranet. The most trouble-free way of doing this cou > ld very well be to install edge routers that provide the NAT function. This i > s *not* to economize on address space. It is to facilitate the manufacture an > d installation, and maintenance (customer support), of entire IP-based system > s. NATs very much get in the way of peer-to-peer in case you weren't aware of that. Try running any kind of server behind a NAT and accessing it from outside the NAT. If two factory widgets are behind the same NAT they need unique addresses and you're back to DHCP or configured addresses. At any time during this process do SNMP communities and default passwords or any sort of encryption keys get changed or do they all stay at the factory settings too? > Bert Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 21:52:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14931 for ; Mon, 24 Mar 2003 21:52:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P34cO24348; Mon, 24 Mar 2003 22:04:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P31gO24250 for ; Mon, 24 Mar 2003 22:01:42 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14680 for ; Mon, 24 Mar 2003 21:41:05 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA08652; Mon, 24 Mar 2003 21:44:27 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250244.VAA08652@workhorse.fictitious.org> To: Daniel Senie cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Mon, 24 Mar 2003 18:48:55 EST." <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 21:44:27 -0500 In message <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net>, Daniel Senie writes: > At 05:27 PM 3/24/2003, Tony Li wrote: > > > > >The argument for why they're not necessary is quite simple: > > > >1) If the site is not connected, then use any number space to begin > >with. When the site connects, renumber. Note that if you had a > >defined address space, you would STILL be renumbering, so the special > >address didn't do anything for you. > > > >2) If the site is connected, then the real benefit out of site > >local addressing is to support NAT. NAT is not necessary so you > >don't need an address space to support it. > > Tony, I disagree that these two are it. > > Example: I run a colo with two interfaces per server. Public interface of > each server has a public address. Second interface has an RFC1918 address. > The second interface is used for backups, inter-server database > connectivity, NFS, etc. Tell me why I should waste public space on that? > Explain how I justify that space when asking for a subnet from an upstream, > when that space isn't going to EVER be connected to the public network. You ask for it. I've asked for IPv4 addresses in order to dual home machines for redundancy and got it (actually I thing Jessica Yu asked, so it was a while ago, ya'll remember Jessica). As long as you have a good reason and can account for tight packing of the allocated space you get it. You can even ask for one address per interface plus one for the loopback and modify code to bind to the loopback for redundancy (no interface loss results in a broken TCP connection). If you ask for address space to support what appears to be expansion fantacies or are unwilling to provide supporting evidence that you have actually used the addresses (account for the machines in detail) will you be denied. (Yes, plenty of requests are denied). > There's no NAT here. There's no public connection. HOWEVER, it is > CRITICALLY important that the address space used for the private network > not conflict with any public address space. If your security is based on obsurity, better not be backing up and PCs on that LAN because your security has just been shot by the first luser to open a poisoned mail attachment. They'll get that through their public side interface assuming they have any access at all. Private addresses also neither hurts or helps maintain security of completely disconnected networks. In IPv6 there is enough to go around so might as well be public addressed. Absent those reasons, why should it be private space? > Maybe I just do really odd things with my server configurations, but I > somehow doubt I'm the only one who does such things. Tying private address > space to NAT does not tell the whole story. > > Dan Sorry Dan. Not a very convincing argument. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 21:53:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14950 for ; Mon, 24 Mar 2003 21:53:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P3E0125569 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 22:14:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P34cO24348; Mon, 24 Mar 2003 22:04:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P31gO24250 for ; Mon, 24 Mar 2003 22:01:42 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14680 for ; Mon, 24 Mar 2003 21:41:05 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA08652; Mon, 24 Mar 2003 21:44:27 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250244.VAA08652@workhorse.fictitious.org> To: Daniel Senie cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Mon, 24 Mar 2003 18:48:55 EST." <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 21:44:27 -0500 In message <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net>, Daniel Senie writes: > At 05:27 PM 3/24/2003, Tony Li wrote: > > > > >The argument for why they're not necessary is quite simple: > > > >1) If the site is not connected, then use any number space to begin > >with. When the site connects, renumber. Note that if you had a > >defined address space, you would STILL be renumbering, so the special > >address didn't do anything for you. > > > >2) If the site is connected, then the real benefit out of site > >local addressing is to support NAT. NAT is not necessary so you > >don't need an address space to support it. > > Tony, I disagree that these two are it. > > Example: I run a colo with two interfaces per server. Public interface of > each server has a public address. Second interface has an RFC1918 address. > The second interface is used for backups, inter-server database > connectivity, NFS, etc. Tell me why I should waste public space on that? > Explain how I justify that space when asking for a subnet from an upstream, > when that space isn't going to EVER be connected to the public network. You ask for it. I've asked for IPv4 addresses in order to dual home machines for redundancy and got it (actually I thing Jessica Yu asked, so it was a while ago, ya'll remember Jessica). As long as you have a good reason and can account for tight packing of the allocated space you get it. You can even ask for one address per interface plus one for the loopback and modify code to bind to the loopback for redundancy (no interface loss results in a broken TCP connection). If you ask for address space to support what appears to be expansion fantacies or are unwilling to provide supporting evidence that you have actually used the addresses (account for the machines in detail) will you be denied. (Yes, plenty of requests are denied). > There's no NAT here. There's no public connection. HOWEVER, it is > CRITICALLY important that the address space used for the private network > not conflict with any public address space. If your security is based on obsurity, better not be backing up and PCs on that LAN because your security has just been shot by the first luser to open a poisoned mail attachment. They'll get that through their public side interface assuming they have any access at all. Private addresses also neither hurts or helps maintain security of completely disconnected networks. In IPv6 there is enough to go around so might as well be public addressed. Absent those reasons, why should it be private space? > Maybe I just do really odd things with my server configurations, but I > somehow doubt I'm the only one who does such things. Tying private address > space to NAT does not tell the whole story. > > Dan Sorry Dan. Not a very convincing argument. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 22:00:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15123 for ; Mon, 24 Mar 2003 22:00:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P372O24528; Mon, 24 Mar 2003 22:07:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P34bO24338 for ; Mon, 24 Mar 2003 22:04:37 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14731 for ; Mon, 24 Mar 2003 21:44:01 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA08673; Mon, 24 Mar 2003 21:47:11 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250247.VAA08673@workhorse.fictitious.org> To: Eliot Lear cc: Daniel Senie , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Mon, 24 Mar 2003 16:00:44 PST." <3E7F9C2C.2010700@cisco.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 21:47:11 -0500 In message <3E7F9C2C.2010700@cisco.com>, Eliot Lear writes: > Daniel Senie wrote: > > Example: I run a colo with two interfaces per server. Public interface > > of each server has a public address. Second interface has an RFC1918 > > address. The second interface is used for backups, inter-server database > > connectivity, NFS, etc. Tell me why I should waste public space on that? > > Explain how I justify that space when asking for a subnet from an > > upstream, when that space isn't going to EVER be connected to the public > > network. > > Because this is like wasting sand in the desert. > > Eliot Good analogy. Does that mean the address registries are selling sand in the desert and somehow getting a good price for it? :-) Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 22:00:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15173 for ; Mon, 24 Mar 2003 22:00:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P3L4F25907 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 22:21:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P372O24528; Mon, 24 Mar 2003 22:07:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P34bO24338 for ; Mon, 24 Mar 2003 22:04:37 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14731 for ; Mon, 24 Mar 2003 21:44:01 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id VAA08673; Mon, 24 Mar 2003 21:47:11 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250247.VAA08673@workhorse.fictitious.org> To: Eliot Lear cc: Daniel Senie , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Mon, 24 Mar 2003 16:00:44 PST." <3E7F9C2C.2010700@cisco.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 21:47:11 -0500 In message <3E7F9C2C.2010700@cisco.com>, Eliot Lear writes: > Daniel Senie wrote: > > Example: I run a colo with two interfaces per server. Public interface > > of each server has a public address. Second interface has an RFC1918 > > address. The second interface is used for backups, inter-server database > > connectivity, NFS, etc. Tell me why I should waste public space on that? > > Explain how I justify that space when asking for a subnet from an > > upstream, when that space isn't going to EVER be connected to the public > > network. > > Because this is like wasting sand in the desert. > > Eliot Good analogy. Does that mean the address registries are selling sand in the desert and somehow getting a good price for it? :-) Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 22:01:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15208 for ; Mon, 24 Mar 2003 22:01:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3D6O25512; Mon, 24 Mar 2003 22:13:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3AdO25423 for ; Mon, 24 Mar 2003 22:10:39 -0500 Received: from garlic.amaranth.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14882 for ; Mon, 24 Mar 2003 21:50:02 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id h2P2qL907514 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 24 Mar 2003 21:52:22 -0500 Message-Id: <5.2.0.9.2.20030324213656.01aa8d50@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: From: Daniel Senie Subject: RE: IPv6 site-locals... end of story... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 21:39:25 -0500 At 07:15 PM 3/24/2003, Tony Li wrote: >Sounds like a fine justification for a /48 or /64 to me. > >The waste should not be an issue as long as the address space >that you are allocated is something that you use efficiently. I'm glad you'll be making the rules for upstreams' determining "efficient use." What I see today is upstreams insisting on being able to ping addresses to prove they're in use. I'll tell 'em Tony said it was OK to use the addresses in disconnected networks. Yes, I'm being facetious, but it's the argument today when being asked to justify IPv4 addresses. I do indeed hope I'm wrong, and expect I'm not. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 22:01:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15252 for ; Mon, 24 Mar 2003 22:01:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P3M2R25969 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 22:22:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3D6O25512; Mon, 24 Mar 2003 22:13:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3AdO25423 for ; Mon, 24 Mar 2003 22:10:39 -0500 Received: from garlic.amaranth.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14882 for ; Mon, 24 Mar 2003 21:50:02 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id h2P2qL907514 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 24 Mar 2003 21:52:22 -0500 Message-Id: <5.2.0.9.2.20030324213656.01aa8d50@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: From: Daniel Senie Subject: RE: IPv6 site-locals... end of story... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 21:39:25 -0500 At 07:15 PM 3/24/2003, Tony Li wrote: >Sounds like a fine justification for a /48 or /64 to me. > >The waste should not be an issue as long as the address space >that you are allocated is something that you use efficiently. I'm glad you'll be making the rules for upstreams' determining "efficient use." What I see today is upstreams insisting on being able to ping addresses to prove they're in use. I'll tell 'em Tony said it was OK to use the addresses in disconnected networks. Yes, I'm being facetious, but it's the argument today when being asked to justify IPv4 addresses. I do indeed hope I'm wrong, and expect I'm not. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 22:13:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15734 for ; Mon, 24 Mar 2003 22:13:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3L3O25900; Mon, 24 Mar 2003 22:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3IwO25810 for ; Mon, 24 Mar 2003 22:18:58 -0500 Received: from mail.cad.zju.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15103 for ; Mon, 24 Mar 2003 21:58:20 -0500 (EST) Received: (qmail 28448 invoked from network); 25 Mar 2003 03:08:04 -0000 Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97) by 210.32.131.2 with SMTP; 25 Mar 2003 03:08:04 -0000 Message-ID: <3E7FC6A2.75DE9B1D@cad.zju.edu.cn> From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Eliot Lear CC: Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <20030321175503.G10329@nexthop.com> <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> <3E7DFC47.9090800@cisco.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:01:54 +0800 Content-Transfer-Encoding: 7bit Hi, > > The only potential legitimate use of site locals is a completely > disconnected network and those networks tend to be quite small. > I do not agree with this at all. As an example, our university use 10.0.0.0/8 as campus network address spac. The network convers four campus located in 6 places in HangZhou city. We have more than 40,000 students, and every student domitory room has been or is being connected to the campus network; there are also hundreds of labs and public service computers ( our lab is not a big one, but we have more than 150 computers) ; besides this, in order to enable resource sharing, this campus network also covers some residential areas where staffs of the university live. The network connects to CERNET and ChinaNet by proxy servers and NAT. > > > > In the zeal to deploy IPv6 and its "boundless" address space let us not > > presume to dictate the implementation strategies for private network > > segments. > > Let's not engineer for corner cases, please. > > Eliot > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 22:14:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15775 for ; Mon, 24 Mar 2003 22:14:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P3Z5p26635 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 22:35:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3L3O25900; Mon, 24 Mar 2003 22:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3IwO25810 for ; Mon, 24 Mar 2003 22:18:58 -0500 Received: from mail.cad.zju.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15103 for ; Mon, 24 Mar 2003 21:58:20 -0500 (EST) Received: (qmail 28448 invoked from network); 25 Mar 2003 03:08:04 -0000 Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97) by 210.32.131.2 with SMTP; 25 Mar 2003 03:08:04 -0000 Message-ID: <3E7FC6A2.75DE9B1D@cad.zju.edu.cn> From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Eliot Lear CC: Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <20030321175503.G10329@nexthop.com> <5.2.0.9.2.20030322213846.01b46070@mail.amaranth.net> <3E7DFC47.9090800@cisco.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:01:54 +0800 Content-Transfer-Encoding: 7bit Hi, > > The only potential legitimate use of site locals is a completely > disconnected network and those networks tend to be quite small. > I do not agree with this at all. As an example, our university use 10.0.0.0/8 as campus network address spac. The network convers four campus located in 6 places in HangZhou city. We have more than 40,000 students, and every student domitory room has been or is being connected to the campus network; there are also hundreds of labs and public service computers ( our lab is not a big one, but we have more than 150 computers) ; besides this, in order to enable resource sharing, this campus network also covers some residential areas where staffs of the university live. The network connects to CERNET and ChinaNet by proxy servers and NAT. > > > > In the zeal to deploy IPv6 and its "boundless" address space let us not > > presume to dictate the implementation strategies for private network > > segments. > > Let's not engineer for corner cases, please. > > Eliot > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion -- Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, Z.J. 310027 P.R.China ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 22:17:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15804 for ; Mon, 24 Mar 2003 22:17:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3QdO26148; Mon, 24 Mar 2003 22:26:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3NrO26030 for ; Mon, 24 Mar 2003 22:23:53 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15284 for ; Mon, 24 Mar 2003 22:03:16 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA08763; Mon, 24 Mar 2003 22:06:33 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250306.WAA08763@workhorse.fictitious.org> To: David Conrad cc: Eliot Lear , Daniel Senie , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Sun, 23 Mar 2003 11:48:50 PST." <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 22:06:33 -0500 In message <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com>, David Conrad wri tes: > > Unfortunately, of course, without a revolutionary advance in > renumbering or routing, this approach _guarantees_ IPv6 NAT when ISPs > start worrying about their IPv6 routing tables. I remember renumbering 140.222, a fairly well known prefix in its day into a subnet of a /13 (I think it was 204.148/13). 140.222 had an enterprise with 3 main locations, two network operation centers, and a national backbone. This was entirely voluntary since the same organization had the old class B and the /13. Another way of thinking of this is IPv6 renumbering has to be at least as good as 1996 technology where you didn't do anything incredibly stupid when you set up the network in the first place (like security based on IP addresses or numeric addresses in various configuration files, except machine generated router configuration files). It helps if all your host support address aliasing on their interfaces for smooth transition with two sets of numbers on all of the interfaces at some point. I understand some IPv4 devices still don't support this and therefore are below 1996 standards of competence. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 22:18:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15879 for ; Mon, 24 Mar 2003 22:18:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P3cDs27516 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 22:38:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3QdO26148; Mon, 24 Mar 2003 22:26:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3NrO26030 for ; Mon, 24 Mar 2003 22:23:53 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15284 for ; Mon, 24 Mar 2003 22:03:16 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA08763; Mon, 24 Mar 2003 22:06:33 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250306.WAA08763@workhorse.fictitious.org> To: David Conrad cc: Eliot Lear , Daniel Senie , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Sun, 23 Mar 2003 11:48:50 PST." <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 22:06:33 -0500 In message <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com>, David Conrad wri tes: > > Unfortunately, of course, without a revolutionary advance in > renumbering or routing, this approach _guarantees_ IPv6 NAT when ISPs > start worrying about their IPv6 routing tables. I remember renumbering 140.222, a fairly well known prefix in its day into a subnet of a /13 (I think it was 204.148/13). 140.222 had an enterprise with 3 main locations, two network operation centers, and a national backbone. This was entirely voluntary since the same organization had the old class B and the /13. Another way of thinking of this is IPv6 renumbering has to be at least as good as 1996 technology where you didn't do anything incredibly stupid when you set up the network in the first place (like security based on IP addresses or numeric addresses in various configuration files, except machine generated router configuration files). It helps if all your host support address aliasing on their interfaces for smooth transition with two sets of numbers on all of the interfaces at some point. I understand some IPv4 devices still don't support this and therefore are below 1996 standards of competence. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 22:20:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16011 for ; Mon, 24 Mar 2003 22:20:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3XCO26497; Mon, 24 Mar 2003 22:33:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3UNO26383 for ; Mon, 24 Mar 2003 22:30:23 -0500 Received: from garlic.amaranth.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15502 for ; Mon, 24 Mar 2003 22:09:46 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id h2P3Bw908812 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Mon, 24 Mar 2003 22:11:59 -0500 Message-Id: <5.2.0.9.2.20030324220332.01a56070@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: curtis@fictitious.org From: Daniel Senie Subject: Re: IPv6 site-locals... end of story... Cc: routing-discussion@ietf.org In-Reply-To: <200303250244.VAA08652@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 22:10:54 -0500 At 09:44 PM 3/24/2003, Curtis Villamizar wrote: >In message <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net>, Daniel >Senie >writes: > > At 05:27 PM 3/24/2003, Tony Li wrote: > > > > > > > > >The argument for why they're not necessary is quite simple: > > > > > >1) If the site is not connected, then use any number space to begin > > >with. When the site connects, renumber. Note that if you had a > > >defined address space, you would STILL be renumbering, so the special > > >address didn't do anything for you. > > > > > >2) If the site is connected, then the real benefit out of site > > >local addressing is to support NAT. NAT is not necessary so you > > >don't need an address space to support it. > > > > Tony, I disagree that these two are it. > > > > Example: I run a colo with two interfaces per server. Public interface of > > each server has a public address. Second interface has an RFC1918 address. > > The second interface is used for backups, inter-server database > > connectivity, NFS, etc. Tell me why I should waste public space on that? > > Explain how I justify that space when asking for a subnet from an > upstream, > > when that space isn't going to EVER be connected to the public network. > >You ask for it. I ask for plenty of space for the public interfaces to these servers. You're suggesting I waste a block of space for the private network, which has no direct (or indirect) connectivity? > I've asked for IPv4 addresses in order to dual home >machines for redundancy and got it (actually I thing Jessica Yu asked, >so it was a while ago, ya'll remember Jessica). As long as you have a >good reason and can account for tight packing of the allocated space >you get it. Yes, I get all the space I justify. I do not need or want to justify the space used for a private segment. > You can even ask for one address per interface plus one >for the loopback and modify code to bind to the loopback for >redundancy (no interface loss results in a broken TCP connection). If >you ask for address space to support what appears to be expansion >fantacies or are unwilling to provide supporting evidence that you >have actually used the addresses (account for the machines in detail) >will you be denied. (Yes, plenty of requests are denied). > > > There's no NAT here. There's no public connection. HOWEVER, it is > > CRITICALLY important that the address space used for the private network > > not conflict with any public address space. > >If your security is based on obsurity, Good. You're making some severe assumptions. > better not be backing up and >PCs on that LAN Colo. Servers. No users. Get it? > because your security has just been shot by the first >luser to open a poisoned mail attachment. what users? > They'll get that through >their public side interface assuming they have any access at all. Yep. You confirmed you didn't read my original note. >Private addresses also neither hurts or helps maintain security of >completely disconnected networks. Did I say I did it for security reasons? Please go reread my original note and point out where I said that. I said I had no need for the traffic there to go to or from the public Internet. Why do folks instantly assume a security motive? I dual-home the servers so that backup and database traffic does not interfere with traffic to/from the rest of the world. Works quite effectively in building server farms. > In IPv6 there is enough to go >around so might as well be public addressed. So let's waste it all. I understand your position. >Absent those reasons, why should it be private space? Well, it comes down to this: when you replace my reasons with yours, and then raise questions, you get YOUR reasons for shooting down my particular issue. That's very nice for you, but doesn't address what I was raising. > > Maybe I just do really odd things with my server configurations, but I > > somehow doubt I'm the only one who does such things. Tying private address > > space to NAT does not tell the whole story. > > > > Dan > >Sorry Dan. Not a very convincing argument. Sorry, Curtis, I'm disappointed you didn't read my argument as I wrote it, but instead interpreted it. I've sent this privately. I'm about ready to give up on this matter. All I really wanted was for some RFC1918-like space to be left around. I don't really give a damn if routers know what the IPv6 private space is and attempt to do something useful with it. I just want some block to be reserved. Since that CLEARLY is a major problem for everyone but me, I guess I should stop arguing. Sheesh. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 22:21:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16026 for ; Mon, 24 Mar 2003 22:21:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P3fdh27715 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 22:41:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3XCO26497; Mon, 24 Mar 2003 22:33:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3UNO26383 for ; Mon, 24 Mar 2003 22:30:23 -0500 Received: from garlic.amaranth.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15502 for ; Mon, 24 Mar 2003 22:09:46 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id h2P3Bw908812 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Mon, 24 Mar 2003 22:11:59 -0500 Message-Id: <5.2.0.9.2.20030324220332.01a56070@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: curtis@fictitious.org From: Daniel Senie Subject: Re: IPv6 site-locals... end of story... Cc: routing-discussion@ietf.org In-Reply-To: <200303250244.VAA08652@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 22:10:54 -0500 At 09:44 PM 3/24/2003, Curtis Villamizar wrote: >In message <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net>, Daniel >Senie >writes: > > At 05:27 PM 3/24/2003, Tony Li wrote: > > > > > > > > >The argument for why they're not necessary is quite simple: > > > > > >1) If the site is not connected, then use any number space to begin > > >with. When the site connects, renumber. Note that if you had a > > >defined address space, you would STILL be renumbering, so the special > > >address didn't do anything for you. > > > > > >2) If the site is connected, then the real benefit out of site > > >local addressing is to support NAT. NAT is not necessary so you > > >don't need an address space to support it. > > > > Tony, I disagree that these two are it. > > > > Example: I run a colo with two interfaces per server. Public interface of > > each server has a public address. Second interface has an RFC1918 address. > > The second interface is used for backups, inter-server database > > connectivity, NFS, etc. Tell me why I should waste public space on that? > > Explain how I justify that space when asking for a subnet from an > upstream, > > when that space isn't going to EVER be connected to the public network. > >You ask for it. I ask for plenty of space for the public interfaces to these servers. You're suggesting I waste a block of space for the private network, which has no direct (or indirect) connectivity? > I've asked for IPv4 addresses in order to dual home >machines for redundancy and got it (actually I thing Jessica Yu asked, >so it was a while ago, ya'll remember Jessica). As long as you have a >good reason and can account for tight packing of the allocated space >you get it. Yes, I get all the space I justify. I do not need or want to justify the space used for a private segment. > You can even ask for one address per interface plus one >for the loopback and modify code to bind to the loopback for >redundancy (no interface loss results in a broken TCP connection). If >you ask for address space to support what appears to be expansion >fantacies or are unwilling to provide supporting evidence that you >have actually used the addresses (account for the machines in detail) >will you be denied. (Yes, plenty of requests are denied). > > > There's no NAT here. There's no public connection. HOWEVER, it is > > CRITICALLY important that the address space used for the private network > > not conflict with any public address space. > >If your security is based on obsurity, Good. You're making some severe assumptions. > better not be backing up and >PCs on that LAN Colo. Servers. No users. Get it? > because your security has just been shot by the first >luser to open a poisoned mail attachment. what users? > They'll get that through >their public side interface assuming they have any access at all. Yep. You confirmed you didn't read my original note. >Private addresses also neither hurts or helps maintain security of >completely disconnected networks. Did I say I did it for security reasons? Please go reread my original note and point out where I said that. I said I had no need for the traffic there to go to or from the public Internet. Why do folks instantly assume a security motive? I dual-home the servers so that backup and database traffic does not interfere with traffic to/from the rest of the world. Works quite effectively in building server farms. > In IPv6 there is enough to go >around so might as well be public addressed. So let's waste it all. I understand your position. >Absent those reasons, why should it be private space? Well, it comes down to this: when you replace my reasons with yours, and then raise questions, you get YOUR reasons for shooting down my particular issue. That's very nice for you, but doesn't address what I was raising. > > Maybe I just do really odd things with my server configurations, but I > > somehow doubt I'm the only one who does such things. Tying private address > > space to NAT does not tell the whole story. > > > > Dan > >Sorry Dan. Not a very convincing argument. Sorry, Curtis, I'm disappointed you didn't read my argument as I wrote it, but instead interpreted it. I've sent this privately. I'm about ready to give up on this matter. All I really wanted was for some RFC1918-like space to be left around. I don't really give a damn if routers know what the IPv6 private space is and attempt to do something useful with it. I just want some block to be reserved. Since that CLEARLY is a major problem for everyone but me, I guess I should stop arguing. Sheesh. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 22:44:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16476 for ; Mon, 24 Mar 2003 22:44:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3pFO28022; Mon, 24 Mar 2003 22:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3mHO27929 for ; Mon, 24 Mar 2003 22:48:17 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16135 for ; Mon, 24 Mar 2003 22:27:40 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA09046; Mon, 24 Mar 2003 22:29:34 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250329.WAA09046@workhorse.fictitious.org> To: jshen@cad.zju.edu.cn cc: Eliot Lear , Daniel Senie , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 11:01:54 +0800." <3E7FC6A2.75DE9B1D@cad.zju.edu.cn> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 22:29:34 -0500 In message <3E7FC6A2.75DE9B1D@cad.zju.edu.cn>, Jing Shen writes: > Hi, > > > > > The only potential legitimate use of site locals is a completely > > disconnected network and those networks tend to be quite small. > > > > I do not agree with this at all. As an example, our university use > 10.0.0.0/8 as campus network address spac. The network convers four > campus located in 6 places in HangZhou city. We have more than > 40,000 students, and every student domitory room has been or is being > connected to the campus network; there are also hundreds of labs and > public > service computers ( our lab is not a big one, but we have more than 150 > computers) > ; besides this, in order to enable resource sharing, this campus network > also covers some residential areas where staffs of the university live. > > The network connects to CERNET and ChinaNet by proxy servers and NAT. I think University of Michigan in Ann Arbor was larger in terms of campus size and network size and geographic dispersion a decade ago and if you count all of Michnet, was much larger in terms of geographic dispersion. They didn't need NAT (NAT hadn't even been invented yet). The fact that you have a large network and used a NAT does not prove that you needed a NAT. If you have a NAT you are not a completely disconnected network, you are connected to the rest of the world via the NAT (just in case that was the point you were trying to make). Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 22:45:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16523 for ; Mon, 24 Mar 2003 22:45:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P45ZC28663 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 23:05:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3pFO28022; Mon, 24 Mar 2003 22:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3mHO27929 for ; Mon, 24 Mar 2003 22:48:17 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16135 for ; Mon, 24 Mar 2003 22:27:40 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA09046; Mon, 24 Mar 2003 22:29:34 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250329.WAA09046@workhorse.fictitious.org> To: jshen@cad.zju.edu.cn cc: Eliot Lear , Daniel Senie , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 11:01:54 +0800." <3E7FC6A2.75DE9B1D@cad.zju.edu.cn> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 22:29:34 -0500 In message <3E7FC6A2.75DE9B1D@cad.zju.edu.cn>, Jing Shen writes: > Hi, > > > > > The only potential legitimate use of site locals is a completely > > disconnected network and those networks tend to be quite small. > > > > I do not agree with this at all. As an example, our university use > 10.0.0.0/8 as campus network address spac. The network convers four > campus located in 6 places in HangZhou city. We have more than > 40,000 students, and every student domitory room has been or is being > connected to the campus network; there are also hundreds of labs and > public > service computers ( our lab is not a big one, but we have more than 150 > computers) > ; besides this, in order to enable resource sharing, this campus network > also covers some residential areas where staffs of the university live. > > The network connects to CERNET and ChinaNet by proxy servers and NAT. I think University of Michigan in Ann Arbor was larger in terms of campus size and network size and geographic dispersion a decade ago and if you count all of Michnet, was much larger in terms of geographic dispersion. They didn't need NAT (NAT hadn't even been invented yet). The fact that you have a large network and used a NAT does not prove that you needed a NAT. If you have a NAT you are not a completely disconnected network, you are connected to the rest of the world via the NAT (just in case that was the point you were trying to make). Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 22:55:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16776 for ; Mon, 24 Mar 2003 22:55:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P42GO28473; Mon, 24 Mar 2003 23:02:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3xAO28372 for ; Mon, 24 Mar 2003 22:59:10 -0500 Received: from india-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16321 for ; Mon, 24 Mar 2003 22:38:31 -0500 (EST) Received: from cbin2-mira-01.cisco.com (localhost [127.0.0.1]) by india-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2P99CiA026464; Tue, 25 Mar 2003 09:09:13 GMT Received: from cisco.com (dhcp-128-107-166-29.cisco.com [128.107.166.29]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AAX00022 (AUTH raraghun); Tue, 25 Mar 2003 09:01:10 +0530 (IST) Message-ID: <3E7FCFB9.4AC129E@cisco.com> From: Rajiv Raghunarayan Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Eliot Lear CC: David Conrad , Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> <3E7E3041.4050006@cisco.com> <3E7E6B6E.F8460767@cisco.com> <3E7EAA7B.7000505@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 19:40:41 -0800 Content-Transfer-Encoding: 7bit Hi Eliot, Eliot Lear wrote: > > Rajiv, > > Maybe some guidance is deserved. What do you think of RFC 1627? Hmmm... you're about 10 yrs ahead in time ;-) Anyway, I did go thru the document, and two main comments I had are: 1. The document might need to be updated to address current issues. For e.g. while it opposes the RFC 1597 request for private address space, we do know that RFC 1918 did in fact make private addresses a reality, we mention problems in the interconnection of two organizations with identical private address space, while NAT (with it's known issues) seems to have been the answer to that question. 2. Much as we may dislike the use of private addresses (and a lot of debate has focussed on this topic in the last few days, maybe even hours), there is nothing in the IP(v6) architecture that disallows this. And people may/will continue to use it, for various reasons - maybe monetary, maybe (pseudo) security whatever. Or maybe a few years down the line we discover that the IPv6 address space isn't sufficient!! IMHO, the best we can do (other than mandating otherwise) is to recommend that private addresses not be used, and if they are used (for whatever reasons), the associated issues (which might need to be elucidated) be kept in mind. -Rajiv. > > ;-) > > Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 22:56:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16799 for ; Mon, 24 Mar 2003 22:56:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P4GBX29989 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 23:16:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P42GO28473; Mon, 24 Mar 2003 23:02:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P3xAO28372 for ; Mon, 24 Mar 2003 22:59:10 -0500 Received: from india-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16321 for ; Mon, 24 Mar 2003 22:38:31 -0500 (EST) Received: from cbin2-mira-01.cisco.com (localhost [127.0.0.1]) by india-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2P99CiA026464; Tue, 25 Mar 2003 09:09:13 GMT Received: from cisco.com (dhcp-128-107-166-29.cisco.com [128.107.166.29]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AAX00022 (AUTH raraghun); Tue, 25 Mar 2003 09:01:10 +0530 (IST) Message-ID: <3E7FCFB9.4AC129E@cisco.com> From: Rajiv Raghunarayan Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Eliot Lear CC: David Conrad , Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> <3E7E3041.4050006@cisco.com> <3E7E6B6E.F8460767@cisco.com> <3E7EAA7B.7000505@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 19:40:41 -0800 Content-Transfer-Encoding: 7bit Hi Eliot, Eliot Lear wrote: > > Rajiv, > > Maybe some guidance is deserved. What do you think of RFC 1627? Hmmm... you're about 10 yrs ahead in time ;-) Anyway, I did go thru the document, and two main comments I had are: 1. The document might need to be updated to address current issues. For e.g. while it opposes the RFC 1597 request for private address space, we do know that RFC 1918 did in fact make private addresses a reality, we mention problems in the interconnection of two organizations with identical private address space, while NAT (with it's known issues) seems to have been the answer to that question. 2. Much as we may dislike the use of private addresses (and a lot of debate has focussed on this topic in the last few days, maybe even hours), there is nothing in the IP(v6) architecture that disallows this. And people may/will continue to use it, for various reasons - maybe monetary, maybe (pseudo) security whatever. Or maybe a few years down the line we discover that the IPv6 address space isn't sufficient!! IMHO, the best we can do (other than mandating otherwise) is to recommend that private addresses not be used, and if they are used (for whatever reasons), the associated issues (which might need to be elucidated) be kept in mind. -Rajiv. > > ;-) > > Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 23:06:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16999 for ; Mon, 24 Mar 2003 23:06:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P4CrO29889; Mon, 24 Mar 2003 23:12:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P49aO29731 for ; Mon, 24 Mar 2003 23:09:36 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16626 for ; Mon, 24 Mar 2003 22:48:56 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA09230; Mon, 24 Mar 2003 22:52:16 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250352.WAA09230@workhorse.fictitious.org> To: Daniel Senie cc: curtis@fictitious.org, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Mon, 24 Mar 2003 22:10:54 EST." <5.2.0.9.2.20030324220332.01a56070@mail.amaranth.net> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 22:52:16 -0500 In message <5.2.0.9.2.20030324220332.01a56070@mail.amaranth.net>, Daniel Senie writes: > At 09:44 PM 3/24/2003, Curtis Villamizar wrote: > > >In message <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net>, Daniel > >Senie > >writes: > > > At 05:27 PM 3/24/2003, Tony Li wrote: > > > > > > > > > > > > >The argument for why they're not necessary is quite simple: > > > > > > > >1) If the site is not connected, then use any number space to begin > > > >with. When the site connects, renumber. Note that if you had a > > > >defined address space, you would STILL be renumbering, so the special > > > >address didn't do anything for you. > > > > > > > >2) If the site is connected, then the real benefit out of site > > > >local addressing is to support NAT. NAT is not necessary so you > > > >don't need an address space to support it. > > > > > > Tony, I disagree that these two are it. > > > > > > Example: I run a colo with two interfaces per server. Public interface of > > > each server has a public address. Second interface has an RFC1918 address > . > > > The second interface is used for backups, inter-server database > > > connectivity, NFS, etc. Tell me why I should waste public space on that? > > > Explain how I justify that space when asking for a subnet from an > > upstream, > > > when that space isn't going to EVER be connected to the public network. > > > >You ask for it. > > I ask for plenty of space for the public interfaces to these servers. > You're suggesting I waste a block of space for the private network, which > has no direct (or indirect) connectivity? For IPv4, if it is never reachable from the outside world "no" because addresses are not plentiful. For IPv6, "yes", since there are plenty of addresses. If the addresses are reachable from the Internet and there was a legitimate reason for two interfaces per host, then for either IPv4 or IPv6 you would be justified in asking for addresses. Where IPv4 allocation should obviously be denied is when the company with 10 PCs, very little clue, and a grandious business plan comes to a routing registry asking for their own /19. > > I've asked for IPv4 addresses in order to dual home > >machines for redundancy and got it (actually I thing Jessica Yu asked, > >so it was a while ago, ya'll remember Jessica). As long as you have a > >good reason and can account for tight packing of the allocated space > >you get it. > > Yes, I get all the space I justify. I do not need or want to justify the > space used for a private segment. Then don't. In our case all interface addresses were reachable and we needed an additional (loopback) address that would never go down. We had a good reason. We had no problem. > > You can even ask for one address per interface plus one > >for the loopback and modify code to bind to the loopback for > >redundancy (no interface loss results in a broken TCP connection). If > >you ask for address space to support what appears to be expansion > >fantacies or are unwilling to provide supporting evidence that you > >have actually used the addresses (account for the machines in detail) > >will you be denied. (Yes, plenty of requests are denied). > > > > > There's no NAT here. There's no public connection. HOWEVER, it is > > > CRITICALLY important that the address space used for the private network > > > not conflict with any public address space. > > > >If your security is based on obsurity, > > Good. You're making some severe assumptions. > > > better not be backing up and > >PCs on that LAN > > Colo. Servers. No users. Get it? Depends on what services you run. If they are all secure, then fine. No MIS types running windoze, that's good. > > because your security has just been shot by the first > >luser to open a poisoned mail attachment. > > what users? > > > They'll get that through > >their public side interface assuming they have any access at all. > > Yep. You confirmed you didn't read my original note. Fine colo only, no other systems are backed up. I did read your note and I get your point. Servers only, no lusers. > >Private addresses also neither hurts or helps maintain security of > >completely disconnected networks. > > Did I say I did it for security reasons? Please go reread my original note > and point out where I said that. I said I had no need for the traffic there > to go to or from the public Internet. Why do folks instantly assume a > security motive? I dual-home the servers so that backup and database > traffic does not interfere with traffic to/from the rest of the world. > Works quite effectively in building server farms. In that case it would be a performance reason. > > In IPv6 there is enough to go > >around so might as well be public addressed. > > So let's waste it all. I understand your position. The desert won't run out of sand. > >Absent those reasons, why should it be private space? > > Well, it comes down to this: when you replace my reasons with yours, and > then raise questions, you get YOUR reasons for shooting down my particular > issue. That's very nice for you, but doesn't address what I was raising. Since security missed the mark and it appears that performance is the reason to have a second interface, then that's fine too. If performance doesn't adequately summarize, then you tell me the reason. In either case, performance or security, it doesn't make sense in IPv6 not to just allocate from routeable addresses. > > > Maybe I just do really odd things with my server configurations, but I > > > somehow doubt I'm the only one who does such things. Tying private addres > s > > > space to NAT does not tell the whole story. > > > > > > Dan > > > >Sorry Dan. Not a very convincing argument. > > Sorry, Curtis, I'm disappointed you didn't read my argument as I wrote it, > but instead interpreted it. > > I've sent this privately. I'm about ready to give up on this matter. All I > really wanted was for some RFC1918-like space to be left around. I don't > really give a damn if routers know what the IPv6 private space is and > attempt to do something useful with it. I just want some block to be > reserved. Since that CLEARLY is a major problem for everyone but me, I > guess I should stop arguing. > > Sheesh. Sorry to have misinterpreted your message. I still think its an incredibly weak argument in favor of RFC1918-like space, whether the reaon for the extra interface is performance, security, or as in our case redundancy. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 23:07:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17033 for ; Mon, 24 Mar 2003 23:07:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P4Rmf30422 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 23:27:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P4CrO29889; Mon, 24 Mar 2003 23:12:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P49aO29731 for ; Mon, 24 Mar 2003 23:09:36 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16626 for ; Mon, 24 Mar 2003 22:48:56 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA09230; Mon, 24 Mar 2003 22:52:16 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303250352.WAA09230@workhorse.fictitious.org> To: Daniel Senie cc: curtis@fictitious.org, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Mon, 24 Mar 2003 22:10:54 EST." <5.2.0.9.2.20030324220332.01a56070@mail.amaranth.net> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 22:52:16 -0500 In message <5.2.0.9.2.20030324220332.01a56070@mail.amaranth.net>, Daniel Senie writes: > At 09:44 PM 3/24/2003, Curtis Villamizar wrote: > > >In message <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net>, Daniel > >Senie > >writes: > > > At 05:27 PM 3/24/2003, Tony Li wrote: > > > > > > > > > > > > >The argument for why they're not necessary is quite simple: > > > > > > > >1) If the site is not connected, then use any number space to begin > > > >with. When the site connects, renumber. Note that if you had a > > > >defined address space, you would STILL be renumbering, so the special > > > >address didn't do anything for you. > > > > > > > >2) If the site is connected, then the real benefit out of site > > > >local addressing is to support NAT. NAT is not necessary so you > > > >don't need an address space to support it. > > > > > > Tony, I disagree that these two are it. > > > > > > Example: I run a colo with two interfaces per server. Public interface of > > > each server has a public address. Second interface has an RFC1918 address > . > > > The second interface is used for backups, inter-server database > > > connectivity, NFS, etc. Tell me why I should waste public space on that? > > > Explain how I justify that space when asking for a subnet from an > > upstream, > > > when that space isn't going to EVER be connected to the public network. > > > >You ask for it. > > I ask for plenty of space for the public interfaces to these servers. > You're suggesting I waste a block of space for the private network, which > has no direct (or indirect) connectivity? For IPv4, if it is never reachable from the outside world "no" because addresses are not plentiful. For IPv6, "yes", since there are plenty of addresses. If the addresses are reachable from the Internet and there was a legitimate reason for two interfaces per host, then for either IPv4 or IPv6 you would be justified in asking for addresses. Where IPv4 allocation should obviously be denied is when the company with 10 PCs, very little clue, and a grandious business plan comes to a routing registry asking for their own /19. > > I've asked for IPv4 addresses in order to dual home > >machines for redundancy and got it (actually I thing Jessica Yu asked, > >so it was a while ago, ya'll remember Jessica). As long as you have a > >good reason and can account for tight packing of the allocated space > >you get it. > > Yes, I get all the space I justify. I do not need or want to justify the > space used for a private segment. Then don't. In our case all interface addresses were reachable and we needed an additional (loopback) address that would never go down. We had a good reason. We had no problem. > > You can even ask for one address per interface plus one > >for the loopback and modify code to bind to the loopback for > >redundancy (no interface loss results in a broken TCP connection). If > >you ask for address space to support what appears to be expansion > >fantacies or are unwilling to provide supporting evidence that you > >have actually used the addresses (account for the machines in detail) > >will you be denied. (Yes, plenty of requests are denied). > > > > > There's no NAT here. There's no public connection. HOWEVER, it is > > > CRITICALLY important that the address space used for the private network > > > not conflict with any public address space. > > > >If your security is based on obsurity, > > Good. You're making some severe assumptions. > > > better not be backing up and > >PCs on that LAN > > Colo. Servers. No users. Get it? Depends on what services you run. If they are all secure, then fine. No MIS types running windoze, that's good. > > because your security has just been shot by the first > >luser to open a poisoned mail attachment. > > what users? > > > They'll get that through > >their public side interface assuming they have any access at all. > > Yep. You confirmed you didn't read my original note. Fine colo only, no other systems are backed up. I did read your note and I get your point. Servers only, no lusers. > >Private addresses also neither hurts or helps maintain security of > >completely disconnected networks. > > Did I say I did it for security reasons? Please go reread my original note > and point out where I said that. I said I had no need for the traffic there > to go to or from the public Internet. Why do folks instantly assume a > security motive? I dual-home the servers so that backup and database > traffic does not interfere with traffic to/from the rest of the world. > Works quite effectively in building server farms. In that case it would be a performance reason. > > In IPv6 there is enough to go > >around so might as well be public addressed. > > So let's waste it all. I understand your position. The desert won't run out of sand. > >Absent those reasons, why should it be private space? > > Well, it comes down to this: when you replace my reasons with yours, and > then raise questions, you get YOUR reasons for shooting down my particular > issue. That's very nice for you, but doesn't address what I was raising. Since security missed the mark and it appears that performance is the reason to have a second interface, then that's fine too. If performance doesn't adequately summarize, then you tell me the reason. In either case, performance or security, it doesn't make sense in IPv6 not to just allocate from routeable addresses. > > > Maybe I just do really odd things with my server configurations, but I > > > somehow doubt I'm the only one who does such things. Tying private addres > s > > > space to NAT does not tell the whole story. > > > > > > Dan > > > >Sorry Dan. Not a very convincing argument. > > Sorry, Curtis, I'm disappointed you didn't read my argument as I wrote it, > but instead interpreted it. > > I've sent this privately. I'm about ready to give up on this matter. All I > really wanted was for some RFC1918-like space to be left around. I don't > really give a damn if routers know what the IPv6 private space is and > attempt to do something useful with it. I just want some block to be > reserved. Since that CLEARLY is a major problem for everyone but me, I > guess I should stop arguing. > > Sheesh. Sorry to have misinterpreted your message. I still think its an incredibly weak argument in favor of RFC1918-like space, whether the reaon for the extra interface is performance, security, or as in our case redundancy. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Mar 24 23:09:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17066 for ; Mon, 24 Mar 2003 23:09:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P4MAO30274; Mon, 24 Mar 2003 23:22:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P4JTO30143 for ; Mon, 24 Mar 2003 23:19:29 -0500 Received: from mailout2.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16866 for ; Mon, 24 Mar 2003 22:58:50 -0500 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HCA00G07DTXQL@mailout2.samsung.com> for routing-discussion@ietf.org; Tue, 25 Mar 2003 13:01:09 +0900 (KST) Received: from ms.samsung.com (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HCA00BXLDTW8X@mailout2.samsung.com> for routing-discussion@ietf.org; Tue, 25 Mar 2003 13:01:09 +0900 (KST) Received: from custom-daemon.ms.samsung.com by ms.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HCA00G01DLUCS@ms.samsung.com> for routing-discussion@ietf.org; Tue, 25 Mar 2003 12:56:18 +0900 (KST) Received: from samsung.com (localhost [127.0.0.1]) by ms.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HCA00DS3DLUWV@ms.samsung.com> for routing-discussion@ietf.org; Tue, 25 Mar 2003 12:56:18 +0900 (KST) Received: from [107.108.3.177] by ms.samsung.com (mshttpd); Tue, 25 Mar 2003 03:56:18 +0000 (GMT) From: Karthikeyan Subject: Regarding OSPFv3 free test suite To: routing-discussion@ietf.org Message-id: <20ac62328e.2328e20ac6@samsung.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.05 (built Nov 6 2002) Content-type: text/html; charset=EUC-KR Content-language: ko Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: ko Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 03:56:18 +0000 (GMT) Content-Transfer-Encoding: quoted-printable = =3Chtml=3E=3Cnobr=3E=3Cimg src=3Dhttp=3A//maildb=2Esamsung=2Ecom=3A8001/o= penconfirm=3Fparm=3Dundefined=5F=5Fundefined20030325092913018 width=3D=22= 1=22 height=3D=221=22=3E=3C/nobr=3E =3Cfont size=3D3 face=3D=22=B1=BC=B8=B2=C3=BC=22=3E =3Cpre=3EHello to all= =2C Can anybody suggest me link for getting free downloadable OSPFv3 test= suite=2E Thanks in advance=2E With regards=2C S=2EKarthikeyan=2E=3C/font=3E=3C/pre=3E=3C/html=3E _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Mon Mar 24 23:10:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17080 for ; Mon, 24 Mar 2003 23:10:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P4UXN30517 for routing-discussion-archive@odin.ietf.org; Mon, 24 Mar 2003 23:30:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P4MAO30274; Mon, 24 Mar 2003 23:22:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P4JTO30143 for ; Mon, 24 Mar 2003 23:19:29 -0500 Received: from mailout2.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16866 for ; Mon, 24 Mar 2003 22:58:50 -0500 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HCA00G07DTXQL@mailout2.samsung.com> for routing-discussion@ietf.org; Tue, 25 Mar 2003 13:01:09 +0900 (KST) Received: from ms.samsung.com (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HCA00BXLDTW8X@mailout2.samsung.com> for routing-discussion@ietf.org; Tue, 25 Mar 2003 13:01:09 +0900 (KST) Received: from custom-daemon.ms.samsung.com by ms.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HCA00G01DLUCS@ms.samsung.com> for routing-discussion@ietf.org; Tue, 25 Mar 2003 12:56:18 +0900 (KST) Received: from samsung.com (localhost [127.0.0.1]) by ms.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HCA00DS3DLUWV@ms.samsung.com> for routing-discussion@ietf.org; Tue, 25 Mar 2003 12:56:18 +0900 (KST) Received: from [107.108.3.177] by ms.samsung.com (mshttpd); Tue, 25 Mar 2003 03:56:18 +0000 (GMT) From: Karthikeyan Subject: Regarding OSPFv3 free test suite To: routing-discussion@ietf.org Message-id: <20ac62328e.2328e20ac6@samsung.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.05 (built Nov 6 2002) Content-type: text/html; charset=EUC-KR Content-language: ko Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: ko Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 03:56:18 +0000 (GMT) Content-Transfer-Encoding: quoted-printable = =3Chtml=3E=3Cnobr=3E=3Cimg src=3Dhttp=3A//maildb=2Esamsung=2Ecom=3A8001/o= penconfirm=3Fparm=3Dundefined=5F=5Fundefined20030325092913018 width=3D=22= 1=22 height=3D=221=22=3E=3C/nobr=3E =3Cfont size=3D3 face=3D=22=B1=BC=B8=B2=C3=BC=22=3E =3Cpre=3EHello to all= =2C Can anybody suggest me link for getting free downloadable OSPFv3 test= suite=2E Thanks in advance=2E With regards=2C S=2EKarthikeyan=2E=3C/font=3E=3C/pre=3E=3C/html=3E _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 00:11:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18496 for ; Tue, 25 Mar 2003 00:11:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P5KYO01932; Tue, 25 Mar 2003 00:20:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P5GMO01775 for ; Tue, 25 Mar 2003 00:16:22 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18116 for ; Mon, 24 Mar 2003 23:55:41 -0500 (EST) Received: from cisco.com (sjc-vpn2-127.cisco.com [10.21.112.127]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id UAA01626; Mon, 24 Mar 2003 20:57:50 -0800 (PST) Message-ID: <3E7FE1CD.5010700@cisco.com> From: Eliot Lear 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: Rajiv Raghunarayan CC: David Conrad , Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> <3E7E3041.4050006@cisco.com> <3E7E6B6E.F8460767@cisco.com> <3E7EAA7B.7000505@cisco.com> <3E7FCFB9.4AC129E@cisco.com> In-Reply-To: <3E7FCFB9.4AC129E@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 20:57:49 -0800 Content-Transfer-Encoding: 7bit Rajiv, I think what I was saying is that this argument is really old. Even back when we wrote 1627 we said then that DHCP was coming down the line, although we didn't fully understand IPv6 autoconfig. Perhaps we would do well to delve into this from the directions of prefix delegation and identifier/locater split (see recent multi6 discussion). That would *really* put the nail in ANY -- ANY -- argument for site locals... Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 00:12:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18518 for ; Tue, 25 Mar 2003 00:12:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P5WuA02552 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 00:32:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P5KYO01932; Tue, 25 Mar 2003 00:20:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P5GMO01775 for ; Tue, 25 Mar 2003 00:16:22 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18116 for ; Mon, 24 Mar 2003 23:55:41 -0500 (EST) Received: from cisco.com (sjc-vpn2-127.cisco.com [10.21.112.127]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id UAA01626; Mon, 24 Mar 2003 20:57:50 -0800 (PST) Message-ID: <3E7FE1CD.5010700@cisco.com> From: Eliot Lear 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: Rajiv Raghunarayan CC: David Conrad , Daniel Senie , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <780A8514-5D68-11D7-9564-000393DB42B2@nominum.com> <3E7E3041.4050006@cisco.com> <3E7E6B6E.F8460767@cisco.com> <3E7EAA7B.7000505@cisco.com> <3E7FCFB9.4AC129E@cisco.com> In-Reply-To: <3E7FCFB9.4AC129E@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 20:57:49 -0800 Content-Transfer-Encoding: 7bit Rajiv, I think what I was saying is that this argument is really old. Even back when we wrote 1627 we said then that DHCP was coming down the line, although we didn't fully understand IPv6 autoconfig. Perhaps we would do well to delve into this from the directions of prefix delegation and identifier/locater split (see recent multi6 discussion). That would *really* put the nail in ANY -- ANY -- argument for site locals... Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 04:21:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04474 for ; Tue, 25 Mar 2003 04:21:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P9UVO27859; Tue, 25 Mar 2003 04:30:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P9RUO27726 for ; Tue, 25 Mar 2003 04:27:30 -0500 Received: from web15106.mail.bjs.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04153 for ; Tue, 25 Mar 2003 04:06:45 -0500 (EST) Message-ID: <20030325090903.57289.qmail@web15106.mail.bjs.yahoo.com> Received: from [218.0.195.236] by web15106.mail.bjs.yahoo.com via HTTP; Tue, 25 Mar 2003 17:09:03 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: IPv6 site-locals... end of story... To: curtis@fictitious.org, jshen@cad.zju.edu.cn Cc: Eliot Lear , Daniel Senie , routing-discussion@ietf.org In-Reply-To: <200303250329.WAA09046@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-431782645-1048583343=:55672" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 17:09:03 +0800 (CST) --0-431782645-1048583343=:55672 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit >The fact that you have a large network and used a NAT does not prove >that you needed a NAT. I do not state that as sample on supporting NAT, but to the fact that private addresses are used in large network, but not small networks. The reason why I think it's reasonable to reserve a private address block is it's easy to be understanded and those information could be easily filtered out when advertising routing information. ( think about such a situation: we use 13.1.1.23 as internal address, while we try to access 13.1.1.23 from 13.1.1.23 ). I think NAT is useful when someone tries to protect its internal network while providing good connection ( although there do exist some problems). regards Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-431782645-1048583343=:55672 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

 

 
>The fact that you have a large network and used a NAT does not prove
>that you needed a NAT.

I do not state that as sample on supporting NAT, but to the fact that private addresses are used in large network, but not small networks.

The reason why I think it's reasonable to reserve a private address block is it's easy to be understanded and those information could be easily filtered out when advertising routing information. ( think about such a situation: we use 13.1.1.23 as internal address, while we try to access 13.1.1.23 from 13.1.1.23 ).

I think NAT is useful when someone tries to protect its internal network while providing good connection ( although there do exist some problems).

regards

 



Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-431782645-1048583343=:55672-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 04:21:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04496 for ; Tue, 25 Mar 2003 04:21:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P9g4j29179 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 04:42:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P9UVO27859; Tue, 25 Mar 2003 04:30:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P9RUO27726 for ; Tue, 25 Mar 2003 04:27:30 -0500 Received: from web15106.mail.bjs.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04153 for ; Tue, 25 Mar 2003 04:06:45 -0500 (EST) Message-ID: <20030325090903.57289.qmail@web15106.mail.bjs.yahoo.com> Received: from [218.0.195.236] by web15106.mail.bjs.yahoo.com via HTTP; Tue, 25 Mar 2003 17:09:03 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: IPv6 site-locals... end of story... To: curtis@fictitious.org, jshen@cad.zju.edu.cn Cc: Eliot Lear , Daniel Senie , routing-discussion@ietf.org In-Reply-To: <200303250329.WAA09046@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-431782645-1048583343=:55672" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 17:09:03 +0800 (CST) --0-431782645-1048583343=:55672 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit >The fact that you have a large network and used a NAT does not prove >that you needed a NAT. I do not state that as sample on supporting NAT, but to the fact that private addresses are used in large network, but not small networks. The reason why I think it's reasonable to reserve a private address block is it's easy to be understanded and those information could be easily filtered out when advertising routing information. ( think about such a situation: we use 13.1.1.23 as internal address, while we try to access 13.1.1.23 from 13.1.1.23 ). I think NAT is useful when someone tries to protect its internal network while providing good connection ( although there do exist some problems). regards Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-431782645-1048583343=:55672 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

 

 
>The fact that you have a large network and used a NAT does not prove
>that you needed a NAT.

I do not state that as sample on supporting NAT, but to the fact that private addresses are used in large network, but not small networks.

The reason why I think it's reasonable to reserve a private address block is it's easy to be understanded and those information could be easily filtered out when advertising routing information. ( think about such a situation: we use 13.1.1.23 as internal address, while we try to access 13.1.1.23 from 13.1.1.23 ).

I think NAT is useful when someone tries to protect its internal network while providing good connection ( although there do exist some problems).

regards

 



Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-431782645-1048583343=:55672-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 05:13:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05476 for ; Tue, 25 Mar 2003 05:13:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PARqO31770; Tue, 25 Mar 2003 05:27:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PANUO31585 for ; Tue, 25 Mar 2003 05:23:30 -0500 Received: from mailhost.packetfront.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05253 for ; Tue, 25 Mar 2003 05:02:44 -0500 (EST) Received: from [192.168.1.11] (helo=Mtw10) by mailhost.packetfront.com with esmtp (Exim 3.35 #1 (Debian)) id 18xlIZ-0000Tw-00; Tue, 25 Mar 2003 11:04:51 +0100 From: "Fredrik Nyman" Organization: PacketFront Sweden AB To: curtis@fictitious.org MIME-Version: 1.0 Subject: Re: IPv6 site-locals... end of story... Reply-to: fredrik@packetfront.com CC: Eliot Lear , Daniel Senie , routing-discussion@ietf.org Message-ID: <3E80354D.21553.60824279@localhost> Priority: normal In-reply-to: <200303250329.WAA09046@workhorse.fictitious.org> References: Your message of "Tue, 25 Mar 2003 11:01:54 +0800." <3E7FC6A2.75DE9B1D@cad.zju.edu.cn> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 10:54:05 +0100 Content-Transfer-Encoding: 7BIT On 24 Mar 2003 at 22:29, Curtis Villamizar wrote: > I think University of Michigan in Ann Arbor was larger in terms of > campus size and network size and geographic dispersion a decade ago > and if you count all of Michnet, was much larger in terms of > geographic dispersion. They didn't need NAT (NAT hadn't even been > invented yet). > > The fact that you have a large network and used a NAT does not prove > that you needed a NAT. Weather people need or do not need NAT is really not the issue. The issue is if people *want* to use NAT. If they do, you'd better accept it. There is clearly needs for private address space (or similar) and possibly also NAT in an IPv6 world. Why? Because people are used to it by now. People have learned to use private address space. It will be many years before people unlearn. I agree that there are many valid arguments how NAT break peer-to-peer, multicast and other functionality and I'd prefer a NAT-free world. But I don't get to decide that. The users do. Since the argument is that there is enough IPv6 address space to go around, what is the harm of allocating a piece of it and call it private address space? In time, people will discontinue the use of NATs and private address space if there are real reasons for it such as "killer applications" that simply do not work with address translation. Perhaps we should focus our efforts on that instead of arguing about a small piece of eternity? -- Fredrik Nyman PacketFront Sweden AB http://www.packetfront.com/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 05:14:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05516 for ; Tue, 25 Mar 2003 05:14:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PAYbL32169 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 05:34:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PARqO31770; Tue, 25 Mar 2003 05:27:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PANUO31585 for ; Tue, 25 Mar 2003 05:23:30 -0500 Received: from mailhost.packetfront.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05253 for ; Tue, 25 Mar 2003 05:02:44 -0500 (EST) Received: from [192.168.1.11] (helo=Mtw10) by mailhost.packetfront.com with esmtp (Exim 3.35 #1 (Debian)) id 18xlIZ-0000Tw-00; Tue, 25 Mar 2003 11:04:51 +0100 From: "Fredrik Nyman" Organization: PacketFront Sweden AB To: curtis@fictitious.org MIME-Version: 1.0 Subject: Re: IPv6 site-locals... end of story... Reply-to: fredrik@packetfront.com CC: Eliot Lear , Daniel Senie , routing-discussion@ietf.org Message-ID: <3E80354D.21553.60824279@localhost> Priority: normal In-reply-to: <200303250329.WAA09046@workhorse.fictitious.org> References: Your message of "Tue, 25 Mar 2003 11:01:54 +0800." <3E7FC6A2.75DE9B1D@cad.zju.edu.cn> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 10:54:05 +0100 Content-Transfer-Encoding: 7BIT On 24 Mar 2003 at 22:29, Curtis Villamizar wrote: > I think University of Michigan in Ann Arbor was larger in terms of > campus size and network size and geographic dispersion a decade ago > and if you count all of Michnet, was much larger in terms of > geographic dispersion. They didn't need NAT (NAT hadn't even been > invented yet). > > The fact that you have a large network and used a NAT does not prove > that you needed a NAT. Weather people need or do not need NAT is really not the issue. The issue is if people *want* to use NAT. If they do, you'd better accept it. There is clearly needs for private address space (or similar) and possibly also NAT in an IPv6 world. Why? Because people are used to it by now. People have learned to use private address space. It will be many years before people unlearn. I agree that there are many valid arguments how NAT break peer-to-peer, multicast and other functionality and I'd prefer a NAT-free world. But I don't get to decide that. The users do. Since the argument is that there is enough IPv6 address space to go around, what is the harm of allocating a piece of it and call it private address space? In time, people will discontinue the use of NATs and private address space if there are real reasons for it such as "killer applications" that simply do not work with address translation. Perhaps we should focus our efforts on that instead of arguing about a small piece of eternity? -- Fredrik Nyman PacketFront Sweden AB http://www.packetfront.com/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 05:16:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05598 for ; Tue, 25 Mar 2003 05:16:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PAPQO31650; Tue, 25 Mar 2003 05:25:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PAMDO31453 for ; Tue, 25 Mar 2003 05:22:13 -0500 Received: from iramx2.ira.uni-karlsruhe.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05232 for ; Tue, 25 Mar 2003 05:01:27 -0500 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 18xlHO-0005aE-00; Tue, 25 Mar 2003 11:03:38 +0100 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.70.77] helo=vorta.ipv6.tm.uni-karlsruhe.de ident=mail) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 18xlHM-0001pC-00; Tue, 25 Mar 2003 11:03:36 +0100 Received: from localhost ([127.0.0.1] helo=vorta.ipv6.tm.uni-karlsruhe.de.tm.uka.de ident=bless) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.05) id 18xlHO-0003Hh-00; Tue, 25 Mar 2003 11:03:38 +0100 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: =?gb2312?q?Jing=20Shen?= cc: jshen@cad.zju.edu.cn, routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... In-Reply-To: Message from =?gb2312?q?Jing=20Shen?= of "Tue, 25 Mar 2003 17:09:03 +0800." <20030325090903.57289.qmail@web15106.mail.bjs.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Roland Bless Message-Id: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:03:38 +0100 Hi, jshen_cad@yahoo.com.cn said: > The reason why I think it's reasonable to reserve a private address > block is it's easy to be understanded and those information could be > easily filtered out when advertising routing information. ( think > about such a situation: we use 13.1.1.23 as internal address, while we > try to access 13.1.1.23 from 13.1.1.23 ). > I think NAT is useful when someone tries to protect its internal > network while providing good connection ( although there do exist some > problems). Private adressing does not add any protection or security!! The ONLY reason to use NAT was the lack of enough addresses. This reason is thus not applicable for IPv6. You can achieve the same security with appropriate filter settings for "normal" addresses. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de WWW: http://www.tm.uka.de/~bless Institute of Telematics, University of Karlsruhe, Germany _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 05:17:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05632 for ; Tue, 25 Mar 2003 05:17:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PAbQ400360 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 05:37:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PAPQO31650; Tue, 25 Mar 2003 05:25:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PAMDO31453 for ; Tue, 25 Mar 2003 05:22:13 -0500 Received: from iramx2.ira.uni-karlsruhe.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05232 for ; Tue, 25 Mar 2003 05:01:27 -0500 (EST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 18xlHO-0005aE-00; Tue, 25 Mar 2003 11:03:38 +0100 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.70.77] helo=vorta.ipv6.tm.uni-karlsruhe.de ident=mail) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 18xlHM-0001pC-00; Tue, 25 Mar 2003 11:03:36 +0100 Received: from localhost ([127.0.0.1] helo=vorta.ipv6.tm.uni-karlsruhe.de.tm.uka.de ident=bless) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.05) id 18xlHO-0003Hh-00; Tue, 25 Mar 2003 11:03:38 +0100 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: =?gb2312?q?Jing=20Shen?= cc: jshen@cad.zju.edu.cn, routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... In-Reply-To: Message from =?gb2312?q?Jing=20Shen?= of "Tue, 25 Mar 2003 17:09:03 +0800." <20030325090903.57289.qmail@web15106.mail.bjs.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Roland Bless Message-Id: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:03:38 +0100 Hi, jshen_cad@yahoo.com.cn said: > The reason why I think it's reasonable to reserve a private address > block is it's easy to be understanded and those information could be > easily filtered out when advertising routing information. ( think > about such a situation: we use 13.1.1.23 as internal address, while we > try to access 13.1.1.23 from 13.1.1.23 ). > I think NAT is useful when someone tries to protect its internal > network while providing good connection ( although there do exist some > problems). Private adressing does not add any protection or security!! The ONLY reason to use NAT was the lack of enough addresses. This reason is thus not applicable for IPv6. You can achieve the same security with appropriate filter settings for "normal" addresses. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de WWW: http://www.tm.uka.de/~bless Institute of Telematics, University of Karlsruhe, Germany _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 09:17:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12709 for ; Tue, 25 Mar 2003 09:17:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PERxO13826; Tue, 25 Mar 2003 09:27:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PEOiO13744 for ; Tue, 25 Mar 2003 09:24:44 -0500 Received: from web15103.mail.bjs.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12077 for ; Tue, 25 Mar 2003 09:03:53 -0500 (EST) Message-ID: <20030325140609.92361.qmail@web15103.mail.bjs.yahoo.com> Received: from [218.0.195.236] by web15103.mail.bjs.yahoo.com via HTTP; Tue, 25 Mar 2003 22:06:09 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: IPv6 site-locals... end of story... To: Roland Bless Cc: jshen@cad.zju.edu.cn, routing-discussion@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-539720083-1048601169=:92214" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 22:06:09 +0800 (CST) --0-539720083-1048601169=:92214 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Hi, > The reason why I think it's reasonable to reserve a private address > block is it's easy to be understanded and those information could be > easily filtered out when advertising routing information. ( think > about such a situation: we use 13.1.1.23 as internal address, while we > try to access 13.1.1.23 from 13.1.1.23 ). > I think NAT is useful when someone tries to protect its internal > network while providing good connection ( although there do exist some > problems). >You can achieve the same security with appropriate filter settings >or "normal" addresses. why? how could we mask private network strucuture from outside? thanks regards Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-539720083-1048601169=:92214 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

Hi,

> The reason why I think it's reasonable to reserve a private address
> block is it's easy to be understanded and those information could be
> easily filtered out when advertising routing information. ( think
> about such a situation: we use 13.1.1.23 as internal address, while we
> try to access 13.1.1.23 from 13.1.1.23 ).

> I think NAT is useful when someone tries to protect its internal
> network while providing good connection ( although there do exist some
> problems).

>You can achieve the same security with appropriate filter settings
>or "normal" addresses.

why? how could we mask private network strucuture from outside? 

thanks

regards


 



Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-539720083-1048601169=:92214-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 09:18:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12844 for ; Tue, 25 Mar 2003 09:18:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PEcZH15028 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 09:38:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PERxO13826; Tue, 25 Mar 2003 09:27:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PEOiO13744 for ; Tue, 25 Mar 2003 09:24:44 -0500 Received: from web15103.mail.bjs.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12077 for ; Tue, 25 Mar 2003 09:03:53 -0500 (EST) Message-ID: <20030325140609.92361.qmail@web15103.mail.bjs.yahoo.com> Received: from [218.0.195.236] by web15103.mail.bjs.yahoo.com via HTTP; Tue, 25 Mar 2003 22:06:09 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: IPv6 site-locals... end of story... To: Roland Bless Cc: jshen@cad.zju.edu.cn, routing-discussion@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-539720083-1048601169=:92214" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 22:06:09 +0800 (CST) --0-539720083-1048601169=:92214 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Hi, > The reason why I think it's reasonable to reserve a private address > block is it's easy to be understanded and those information could be > easily filtered out when advertising routing information. ( think > about such a situation: we use 13.1.1.23 as internal address, while we > try to access 13.1.1.23 from 13.1.1.23 ). > I think NAT is useful when someone tries to protect its internal > network while providing good connection ( although there do exist some > problems). >You can achieve the same security with appropriate filter settings >or "normal" addresses. why? how could we mask private network strucuture from outside? thanks regards Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-539720083-1048601169=:92214 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

Hi,

> The reason why I think it's reasonable to reserve a private address
> block is it's easy to be understanded and those information could be
> easily filtered out when advertising routing information. ( think
> about such a situation: we use 13.1.1.23 as internal address, while we
> try to access 13.1.1.23 from 13.1.1.23 ).

> I think NAT is useful when someone tries to protect its internal
> network while providing good connection ( although there do exist some
> problems).

>You can achieve the same security with appropriate filter settings
>or "normal" addresses.

why? how could we mask private network strucuture from outside? 

thanks

regards


 



Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-539720083-1048601169=:92214-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 09:47:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14551 for ; Tue, 25 Mar 2003 09:47:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PF2HO16434; Tue, 25 Mar 2003 10:02:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PExcO16257 for ; Tue, 25 Mar 2003 09:59:38 -0500 Received: from chuckie.dgms.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14147 for ; Tue, 25 Mar 2003 09:38:47 -0500 (EST) Received: from pcprice (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id JAA01522; Tue, 25 Mar 2003 09:41:03 -0500 (EST) From: "Tim Price" To: "'Daniel Senie'" Cc: Subject: RE: IPv6 site-locals... end of story... Message-ID: <026801c2f2dc$b4fece80$502119ac@pcprice> 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <5.2.0.9.2.20030324220332.01a56070@mail.amaranth.net> Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 09:42:05 -0500 Content-Transfer-Encoding: 7bit Hi Daniel, Actually, you are not even close to being wrong, and I hope you don't give up the ship. I have not been involved in the discussions other than the recent flurry of emails, but my suspicion is that your opponents have a completely skewed view of reality. I guarantee you there are hundreds of thousands of small networks (connected or not) out there that are being maintained by administrators with limited experience or training. They are likely to be unfamiliar with the procedure for getting a network address, nor are they likely to bother with the procedure. Additionally, these networks are almost guaranteed to be connected by primitive means to the Internet (but not necessarily at the same time as the initial configuration of the network)- leading to a natural NAT situation. I submit that as a standards body you must address your entire intended audience, which means that the least-common-denominator approach should be considered. If the argument is that address space in IPv6 is boundless, then retaining a block of addresses for private use costs you absolutely nothing as a standards body. That doesn't necessarily mean that these addresses not be routed across gateways, but at the very least guaranteeing the addresses won't be registered helps. However, the logic needed in a router is minimal, which also costs virtually nothing. If it costs nothing AND accommodates the needs of a large segment of your audience then I submit you have a win-win scenario. I also suggest that you recognize the (sometimes unfortunate) need to maintain backward compatibility. In this case, I would ask that you retain the philosophy of reserved private addresses. Removing functionality always leads to a grass roots rebellion, regardless of whether or not you "have their best interests in mind". No, it does not necessarily follow the symmetry and beauty of the v6 design- but we live in the real world and you frankly have to consider what the user may want. ******************************************************** Tim Price tim.price@ulticom.com (856) 787-2704 -----Original Message----- From: routing-discussion-admin@ietf.org [mailto:routing-discussion-admin@ietf.org] On Behalf Of Daniel Senie Sent: Monday, March 24, 2003 10:11 PM To: curtis@fictitious.org Cc: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... At 09:44 PM 3/24/2003, Curtis Villamizar wrote: >In message <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net>, Daniel >Senie >writes: > > At 05:27 PM 3/24/2003, Tony Li wrote: > > > > > > > > >The argument for why they're not necessary is quite simple: > > > > > >1) If the site is not connected, then use any number space to begin > > >with. When the site connects, renumber. Note that if you had a > > >defined address space, you would STILL be renumbering, so the special > > >address didn't do anything for you. > > > > > >2) If the site is connected, then the real benefit out of site > > >local addressing is to support NAT. NAT is not necessary so you > > >don't need an address space to support it. > > > > Tony, I disagree that these two are it. > > > > Example: I run a colo with two interfaces per server. Public interface of > > each server has a public address. Second interface has an RFC1918 address. > > The second interface is used for backups, inter-server database > > connectivity, NFS, etc. Tell me why I should waste public space on that? > > Explain how I justify that space when asking for a subnet from an > upstream, > > when that space isn't going to EVER be connected to the public network. > >You ask for it. I ask for plenty of space for the public interfaces to these servers. You're suggesting I waste a block of space for the private network, which has no direct (or indirect) connectivity? > I've asked for IPv4 addresses in order to dual home >machines for redundancy and got it (actually I thing Jessica Yu asked, >so it was a while ago, ya'll remember Jessica). As long as you have a >good reason and can account for tight packing of the allocated space >you get it. Yes, I get all the space I justify. I do not need or want to justify the space used for a private segment. > You can even ask for one address per interface plus one >for the loopback and modify code to bind to the loopback for >redundancy (no interface loss results in a broken TCP connection). If >you ask for address space to support what appears to be expansion >fantacies or are unwilling to provide supporting evidence that you >have actually used the addresses (account for the machines in detail) >will you be denied. (Yes, plenty of requests are denied). > > > There's no NAT here. There's no public connection. HOWEVER, it is > > CRITICALLY important that the address space used for the private network > > not conflict with any public address space. > >If your security is based on obsurity, Good. You're making some severe assumptions. > better not be backing up and >PCs on that LAN Colo. Servers. No users. Get it? > because your security has just been shot by the first >luser to open a poisoned mail attachment. what users? > They'll get that through >their public side interface assuming they have any access at all. Yep. You confirmed you didn't read my original note. >Private addresses also neither hurts or helps maintain security of >completely disconnected networks. Did I say I did it for security reasons? Please go reread my original note and point out where I said that. I said I had no need for the traffic there to go to or from the public Internet. Why do folks instantly assume a security motive? I dual-home the servers so that backup and database traffic does not interfere with traffic to/from the rest of the world. Works quite effectively in building server farms. > In IPv6 there is enough to go >around so might as well be public addressed. So let's waste it all. I understand your position. >Absent those reasons, why should it be private space? Well, it comes down to this: when you replace my reasons with yours, and then raise questions, you get YOUR reasons for shooting down my particular issue. That's very nice for you, but doesn't address what I was raising. > > Maybe I just do really odd things with my server configurations, but I > > somehow doubt I'm the only one who does such things. Tying private address > > space to NAT does not tell the whole story. > > > > Dan > >Sorry Dan. Not a very convincing argument. Sorry, Curtis, I'm disappointed you didn't read my argument as I wrote it, but instead interpreted it. I've sent this privately. I'm about ready to give up on this matter. All I really wanted was for some RFC1918-like space to be left around. I don't really give a damn if routers know what the IPv6 private space is and attempt to do something useful with it. I just want some block to be reserved. Since that CLEARLY is a major problem for everyone but me, I guess I should stop arguing. Sheesh. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 09:50:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14650 for ; Tue, 25 Mar 2003 09:50:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PFAwu17823 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 10:10:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PF2HO16434; Tue, 25 Mar 2003 10:02:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PExcO16257 for ; Tue, 25 Mar 2003 09:59:38 -0500 Received: from chuckie.dgms.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14147 for ; Tue, 25 Mar 2003 09:38:47 -0500 (EST) Received: from pcprice (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id JAA01522; Tue, 25 Mar 2003 09:41:03 -0500 (EST) From: "Tim Price" To: "'Daniel Senie'" Cc: Subject: RE: IPv6 site-locals... end of story... Message-ID: <026801c2f2dc$b4fece80$502119ac@pcprice> 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <5.2.0.9.2.20030324220332.01a56070@mail.amaranth.net> Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 09:42:05 -0500 Content-Transfer-Encoding: 7bit Hi Daniel, Actually, you are not even close to being wrong, and I hope you don't give up the ship. I have not been involved in the discussions other than the recent flurry of emails, but my suspicion is that your opponents have a completely skewed view of reality. I guarantee you there are hundreds of thousands of small networks (connected or not) out there that are being maintained by administrators with limited experience or training. They are likely to be unfamiliar with the procedure for getting a network address, nor are they likely to bother with the procedure. Additionally, these networks are almost guaranteed to be connected by primitive means to the Internet (but not necessarily at the same time as the initial configuration of the network)- leading to a natural NAT situation. I submit that as a standards body you must address your entire intended audience, which means that the least-common-denominator approach should be considered. If the argument is that address space in IPv6 is boundless, then retaining a block of addresses for private use costs you absolutely nothing as a standards body. That doesn't necessarily mean that these addresses not be routed across gateways, but at the very least guaranteeing the addresses won't be registered helps. However, the logic needed in a router is minimal, which also costs virtually nothing. If it costs nothing AND accommodates the needs of a large segment of your audience then I submit you have a win-win scenario. I also suggest that you recognize the (sometimes unfortunate) need to maintain backward compatibility. In this case, I would ask that you retain the philosophy of reserved private addresses. Removing functionality always leads to a grass roots rebellion, regardless of whether or not you "have their best interests in mind". No, it does not necessarily follow the symmetry and beauty of the v6 design- but we live in the real world and you frankly have to consider what the user may want. ******************************************************** Tim Price tim.price@ulticom.com (856) 787-2704 -----Original Message----- From: routing-discussion-admin@ietf.org [mailto:routing-discussion-admin@ietf.org] On Behalf Of Daniel Senie Sent: Monday, March 24, 2003 10:11 PM To: curtis@fictitious.org Cc: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... At 09:44 PM 3/24/2003, Curtis Villamizar wrote: >In message <5.2.0.9.2.20030324184450.01ba3770@mail.amaranth.net>, Daniel >Senie >writes: > > At 05:27 PM 3/24/2003, Tony Li wrote: > > > > > > > > >The argument for why they're not necessary is quite simple: > > > > > >1) If the site is not connected, then use any number space to begin > > >with. When the site connects, renumber. Note that if you had a > > >defined address space, you would STILL be renumbering, so the special > > >address didn't do anything for you. > > > > > >2) If the site is connected, then the real benefit out of site > > >local addressing is to support NAT. NAT is not necessary so you > > >don't need an address space to support it. > > > > Tony, I disagree that these two are it. > > > > Example: I run a colo with two interfaces per server. Public interface of > > each server has a public address. Second interface has an RFC1918 address. > > The second interface is used for backups, inter-server database > > connectivity, NFS, etc. Tell me why I should waste public space on that? > > Explain how I justify that space when asking for a subnet from an > upstream, > > when that space isn't going to EVER be connected to the public network. > >You ask for it. I ask for plenty of space for the public interfaces to these servers. You're suggesting I waste a block of space for the private network, which has no direct (or indirect) connectivity? > I've asked for IPv4 addresses in order to dual home >machines for redundancy and got it (actually I thing Jessica Yu asked, >so it was a while ago, ya'll remember Jessica). As long as you have a >good reason and can account for tight packing of the allocated space >you get it. Yes, I get all the space I justify. I do not need or want to justify the space used for a private segment. > You can even ask for one address per interface plus one >for the loopback and modify code to bind to the loopback for >redundancy (no interface loss results in a broken TCP connection). If >you ask for address space to support what appears to be expansion >fantacies or are unwilling to provide supporting evidence that you >have actually used the addresses (account for the machines in detail) >will you be denied. (Yes, plenty of requests are denied). > > > There's no NAT here. There's no public connection. HOWEVER, it is > > CRITICALLY important that the address space used for the private network > > not conflict with any public address space. > >If your security is based on obsurity, Good. You're making some severe assumptions. > better not be backing up and >PCs on that LAN Colo. Servers. No users. Get it? > because your security has just been shot by the first >luser to open a poisoned mail attachment. what users? > They'll get that through >their public side interface assuming they have any access at all. Yep. You confirmed you didn't read my original note. >Private addresses also neither hurts or helps maintain security of >completely disconnected networks. Did I say I did it for security reasons? Please go reread my original note and point out where I said that. I said I had no need for the traffic there to go to or from the public Internet. Why do folks instantly assume a security motive? I dual-home the servers so that backup and database traffic does not interfere with traffic to/from the rest of the world. Works quite effectively in building server farms. > In IPv6 there is enough to go >around so might as well be public addressed. So let's waste it all. I understand your position. >Absent those reasons, why should it be private space? Well, it comes down to this: when you replace my reasons with yours, and then raise questions, you get YOUR reasons for shooting down my particular issue. That's very nice for you, but doesn't address what I was raising. > > Maybe I just do really odd things with my server configurations, but I > > somehow doubt I'm the only one who does such things. Tying private address > > space to NAT does not tell the whole story. > > > > Dan > >Sorry Dan. Not a very convincing argument. Sorry, Curtis, I'm disappointed you didn't read my argument as I wrote it, but instead interpreted it. I've sent this privately. I'm about ready to give up on this matter. All I really wanted was for some RFC1918-like space to be left around. I don't really give a damn if routers know what the IPv6 private space is and attempt to do something useful with it. I just want some block to be reserved. Since that CLEARLY is a major problem for everyone but me, I guess I should stop arguing. Sheesh. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 11:04:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19434 for ; Tue, 25 Mar 2003 11:04:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGIdO22561; Tue, 25 Mar 2003 11:18:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGFUO22441 for ; Tue, 25 Mar 2003 11:15:30 -0500 Received: from blv-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19186 for ; Tue, 25 Mar 2003 10:54:38 -0500 (EST) Received: from blv-av-02.boeing.com ([192.42.227.217]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA07626; Tue, 25 Mar 2003 07:56:57 -0800 (PST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id HAA17675; Tue, 25 Mar 2003 07:56:56 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2PFutP29722; Tue, 25 Mar 2003 09:56:55 -0600 (CST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Mar 2003 10:56:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLydcMwj5Ggg0eGRpifIszSx6lFegAa5TQg From: "Manfredi, Albert E" To: Cc: "Tony Li" , X-OriginalArrivalTime: 25 Mar 2003 15:56:55.0300 (UTC) FILETIME=[28A40440:01C2F2E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PGFVO22442 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 10:56:54 -0500 Content-Transfer-Encoding: 8bit > From: Curtis Villamizar [mailto:curtis@fictitious.org] > NATs very much get in the way of peer-to-peer in case you weren't > aware of that. Try running any kind of server behind a NAT and > accessing it from outside the NAT. If two factory widgets are behind > the same NAT they need unique addresses and you're back to DHCP or > configured addresses. If the entire peer-peer network is behind the NAT, the NAT won't bother it in the slightest. That was the scenario I was describing. Multiple such systems, installed in many different sites, all of them internally identical. If there is a server outside the NAT, once again, the peer-peer network can remain identical in all instances and the NAT will take care of making the server appear identical to all hosts inside the NAT. Comms outside the NAT may be expected to be infrequent, e.g. primarily for occasional remote system monitoring or remote troubleshooting. And these sessions may always be initiated outside the NAT, leaving the peer-peer network unchangerd in every case. My problem with all the arguments against a private address space in IPv6, and all the arguments in RFC 1627 too for that matter, is that these arguments assume the only motivation is to economize on address space. And yet, plenty of people have indicated otherwise. Yes, it is always possible to create private networks with real but illegal global addresses. That's a nuisance and prone to creating problems. And I don't think that IPv6, by design, should make it mandatory for every private network to obtain globally unique addresses from the IANA. That's sort of obnoxious. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 11:05:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19465 for ; Tue, 25 Mar 2003 11:05:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PGPSP22918 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 11:25:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGIdO22561; Tue, 25 Mar 2003 11:18:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGFUO22441 for ; Tue, 25 Mar 2003 11:15:30 -0500 Received: from blv-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19186 for ; Tue, 25 Mar 2003 10:54:38 -0500 (EST) Received: from blv-av-02.boeing.com ([192.42.227.217]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA07626; Tue, 25 Mar 2003 07:56:57 -0800 (PST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id HAA17675; Tue, 25 Mar 2003 07:56:56 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2PFutP29722; Tue, 25 Mar 2003 09:56:55 -0600 (CST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Mar 2003 10:56:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLydcMwj5Ggg0eGRpifIszSx6lFegAa5TQg From: "Manfredi, Albert E" To: Cc: "Tony Li" , X-OriginalArrivalTime: 25 Mar 2003 15:56:55.0300 (UTC) FILETIME=[28A40440:01C2F2E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PGFVO22442 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 10:56:54 -0500 Content-Transfer-Encoding: 8bit > From: Curtis Villamizar [mailto:curtis@fictitious.org] > NATs very much get in the way of peer-to-peer in case you weren't > aware of that. Try running any kind of server behind a NAT and > accessing it from outside the NAT. If two factory widgets are behind > the same NAT they need unique addresses and you're back to DHCP or > configured addresses. If the entire peer-peer network is behind the NAT, the NAT won't bother it in the slightest. That was the scenario I was describing. Multiple such systems, installed in many different sites, all of them internally identical. If there is a server outside the NAT, once again, the peer-peer network can remain identical in all instances and the NAT will take care of making the server appear identical to all hosts inside the NAT. Comms outside the NAT may be expected to be infrequent, e.g. primarily for occasional remote system monitoring or remote troubleshooting. And these sessions may always be initiated outside the NAT, leaving the peer-peer network unchangerd in every case. My problem with all the arguments against a private address space in IPv6, and all the arguments in RFC 1627 too for that matter, is that these arguments assume the only motivation is to economize on address space. And yet, plenty of people have indicated otherwise. Yes, it is always possible to create private networks with real but illegal global addresses. That's a nuisance and prone to creating problems. And I don't think that IPv6, by design, should make it mandatory for every private network to obtain globally unique addresses from the IANA. That's sort of obnoxious. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 11:35:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20717 for ; Tue, 25 Mar 2003 11:35:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGjTO24693; Tue, 25 Mar 2003 11:45:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGgBO24550 for ; Tue, 25 Mar 2003 11:42:11 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20103 for ; Tue, 25 Mar 2003 11:21:17 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA13450; Tue, 25 Mar 2003 11:24:22 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303251624.LAA13450@workhorse.fictitious.org> To: Roland Bless cc: Jing Shen , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 11:03:38 +0100." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:24:22 -0500 In message , Roland Bless wri tes: > Hi, > > jshen_cad@yahoo.com.cn said: > > The reason why I think it's reasonable to reserve a private address > > block is it's easy to be understanded and those information could be > > easily filtered out when advertising routing information. ( think > > about such a situation: we use 13.1.1.23 as internal address, while we > > try to access 13.1.1.23 from 13.1.1.23 ). > > > I think NAT is useful when someone tries to protect its internal > > network while providing good connection ( although there do exist some > > problems). > > Private adressing does not add any protection or security!! > The ONLY reason to use NAT was the lack of enough addresses. > This reason is thus not applicable for IPv6. > You can achieve the same security with appropriate filter settings > for "normal" addresses. > > Regards, > Roland There is clearly widespread ignorance of this fact. In many contexts such as discussion of corporate through K-12 school infrastructures, I've heard NAT mentioned as a security measure. It adds no real security at all. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 11:35:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20738 for ; Tue, 25 Mar 2003 11:35:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PGuIi25290 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 11:56:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGjTO24693; Tue, 25 Mar 2003 11:45:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGgBO24550 for ; Tue, 25 Mar 2003 11:42:11 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20103 for ; Tue, 25 Mar 2003 11:21:17 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA13450; Tue, 25 Mar 2003 11:24:22 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303251624.LAA13450@workhorse.fictitious.org> To: Roland Bless cc: Jing Shen , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 11:03:38 +0100." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:24:22 -0500 In message , Roland Bless wri tes: > Hi, > > jshen_cad@yahoo.com.cn said: > > The reason why I think it's reasonable to reserve a private address > > block is it's easy to be understanded and those information could be > > easily filtered out when advertising routing information. ( think > > about such a situation: we use 13.1.1.23 as internal address, while we > > try to access 13.1.1.23 from 13.1.1.23 ). > > > I think NAT is useful when someone tries to protect its internal > > network while providing good connection ( although there do exist some > > problems). > > Private adressing does not add any protection or security!! > The ONLY reason to use NAT was the lack of enough addresses. > This reason is thus not applicable for IPv6. > You can achieve the same security with appropriate filter settings > for "normal" addresses. > > Regards, > Roland There is clearly widespread ignorance of this fact. In many contexts such as discussion of corporate through K-12 school infrastructures, I've heard NAT mentioned as a security measure. It adds no real security at all. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 11:51:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21236 for ; Tue, 25 Mar 2003 11:51:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGvRO25344; Tue, 25 Mar 2003 11:57:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGskO25169 for ; Tue, 25 Mar 2003 11:54:46 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20658 for ; Tue, 25 Mar 2003 11:33:52 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA13520; Tue, 25 Mar 2003 11:36:58 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303251636.LAA13520@workhorse.fictitious.org> To: "Tim Price" cc: "'Daniel Senie'" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 09:42:05 EST." <026801c2f2dc$b4fece80$502119ac@pcprice> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:36:58 -0500 In message <026801c2f2dc$b4fece80$502119ac@pcprice>, "Tim Price" writes: > Hi Daniel, > > Actually, you are not even close to being wrong, and I hope you don't give > up the ship. I have not been involved in the discussions other than the > recent flurry of emails, but my suspicion is that your opponents have a > completely skewed view of reality. I guarantee you there are hundreds of > thousands of small networks (connected or not) out there that are being > maintained by administrators with limited experience or training. They are > likely to be unfamiliar with the procedure for getting a network address, > nor are they likely to bother with the procedure. Additionally, these > networks are almost guaranteed to be connected by primitive means to the > Internet (but not necessarily at the same time as the initial configuration > of the network)- leading to a natural NAT situation. I submit that as a > standards body you must address your entire intended audience, which means > that the least-common-denominator approach should be considered. If the > argument is that address space in IPv6 is boundless, then retaining a block > of addresses for private use costs you absolutely nothing as a standards > body. That doesn't necessarily mean that these addresses not be routed > across gateways, but at the very least guaranteeing the addresses won't be > registered helps. However, the logic needed in a router is minimal, which > also costs virtually nothing. If it costs nothing AND accommodates the > needs of a large segment of your audience then I submit you have a win-win > scenario. > > I also suggest that you recognize the (sometimes unfortunate) need to > maintain backward compatibility. In this case, I would ask that you retain > the philosophy of reserved private addresses. Removing functionality always > leads to a grass roots rebellion, regardless of whether or not you "have > their best interests in mind". No, it does not necessarily follow the > symmetry and beauty of the v6 design- but we live in the real world and you > frankly have to consider what the user may want. Your argument seems to be that regardless of more than sufficient address space in IPv6, IPv6 autoconfig is not sufficiently idiot proof for a large segment of the network population, therefore IPv6 NAT is needed. If that is not the case, then you had better restate your argument. Please note that I haven't commented either way on whether IPv6 autoconfig is sufficiently idiot proof or not. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 11:52:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21264 for ; Tue, 25 Mar 2003 11:52:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PHCgb27299 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 12:12:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGvRO25344; Tue, 25 Mar 2003 11:57:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGskO25169 for ; Tue, 25 Mar 2003 11:54:46 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20658 for ; Tue, 25 Mar 2003 11:33:52 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA13520; Tue, 25 Mar 2003 11:36:58 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303251636.LAA13520@workhorse.fictitious.org> To: "Tim Price" cc: "'Daniel Senie'" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 09:42:05 EST." <026801c2f2dc$b4fece80$502119ac@pcprice> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:36:58 -0500 In message <026801c2f2dc$b4fece80$502119ac@pcprice>, "Tim Price" writes: > Hi Daniel, > > Actually, you are not even close to being wrong, and I hope you don't give > up the ship. I have not been involved in the discussions other than the > recent flurry of emails, but my suspicion is that your opponents have a > completely skewed view of reality. I guarantee you there are hundreds of > thousands of small networks (connected or not) out there that are being > maintained by administrators with limited experience or training. They are > likely to be unfamiliar with the procedure for getting a network address, > nor are they likely to bother with the procedure. Additionally, these > networks are almost guaranteed to be connected by primitive means to the > Internet (but not necessarily at the same time as the initial configuration > of the network)- leading to a natural NAT situation. I submit that as a > standards body you must address your entire intended audience, which means > that the least-common-denominator approach should be considered. If the > argument is that address space in IPv6 is boundless, then retaining a block > of addresses for private use costs you absolutely nothing as a standards > body. That doesn't necessarily mean that these addresses not be routed > across gateways, but at the very least guaranteeing the addresses won't be > registered helps. However, the logic needed in a router is minimal, which > also costs virtually nothing. If it costs nothing AND accommodates the > needs of a large segment of your audience then I submit you have a win-win > scenario. > > I also suggest that you recognize the (sometimes unfortunate) need to > maintain backward compatibility. In this case, I would ask that you retain > the philosophy of reserved private addresses. Removing functionality always > leads to a grass roots rebellion, regardless of whether or not you "have > their best interests in mind". No, it does not necessarily follow the > symmetry and beauty of the v6 design- but we live in the real world and you > frankly have to consider what the user may want. Your argument seems to be that regardless of more than sufficient address space in IPv6, IPv6 autoconfig is not sufficiently idiot proof for a large segment of the network population, therefore IPv6 NAT is needed. If that is not the case, then you had better restate your argument. Please note that I haven't commented either way on whether IPv6 autoconfig is sufficiently idiot proof or not. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 12:04:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21617 for ; Tue, 25 Mar 2003 12:04:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHDaO27328; Tue, 25 Mar 2003 12:13:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHAOO27209 for ; Tue, 25 Mar 2003 12:10:24 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21167 for ; Tue, 25 Mar 2003 11:49:30 -0500 (EST) Received: from cisco.com (sjc-vpn1-663.cisco.com [10.21.98.151]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA06349; Tue, 25 Mar 2003 08:51:07 -0800 (PST) Message-ID: <3E8088FA.40404@cisco.com> From: Eliot Lear 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: Tim Price CC: "'Daniel Senie'" , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <026801c2f2dc$b4fece80$502119ac@pcprice> In-Reply-To: <026801c2f2dc$b4fece80$502119ac@pcprice> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 08:51:06 -0800 Content-Transfer-Encoding: 7bit Tim Price wrote: > Actually, you are not even close to being wrong, and I hope you don't give > up the ship. I have not been involved in the discussions other than the > recent flurry of emails, but my suspicion is that your opponents have a > completely skewed view of reality. I guarantee you there are hundreds of > thousands of small networks (connected or not) out there that are being > maintained by administrators with limited experience or training. They are > likely to be unfamiliar with the procedure for getting a network address, > nor are they likely to bother with the procedure. Additionally, these > networks are almost guaranteed to be connected by primitive means to the > Internet (but not necessarily at the same time as the initial configuration > of the network)- leading to a natural NAT situation. To start with, small networks should be well served by mechanisms such as prefix delegation. That delegation occurs in two ways: either automatic such as the way Droms, et. al have gone, and manual through the provisioning process (ie., use these addresses as opposed to others). This is done today in the real world. > I submit that as a > standards body you must address your entire intended audience, which means > that the least-common-denominator approach should be considered. No, this is not how one engineers. One engineers for the largest set of general use cases, not the least common denominator. > If the > argument is that address space in IPv6 is boundless, then retaining a block > of addresses for private use costs you absolutely nothing as a standards > body. It costs the end user peer to peer connectivity. > That doesn't necessarily mean that these addresses not be routed > across gateways, but at the very least guaranteeing the addresses won't be > registered helps. However, the logic needed in a router is minimal, which > also costs virtually nothing. If it costs nothing AND accommodates the > needs of a large segment of your audience then I submit you have a win-win > scenario. You could also provide security via identd. That costs virtually nothing, but offers about the same. > > I also suggest that you recognize the (sometimes unfortunate) need to > maintain backward compatibility. This is not a case of backward compatibility. You are changing protocols. Private network address space was offered due to address space shortage. That engineering requirement has evaporated. So should private address space. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 12:05:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21674 for ; Tue, 25 Mar 2003 12:05:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PHPax27950 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 12:25:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHDaO27328; Tue, 25 Mar 2003 12:13:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHAOO27209 for ; Tue, 25 Mar 2003 12:10:24 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21167 for ; Tue, 25 Mar 2003 11:49:30 -0500 (EST) Received: from cisco.com (sjc-vpn1-663.cisco.com [10.21.98.151]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA06349; Tue, 25 Mar 2003 08:51:07 -0800 (PST) Message-ID: <3E8088FA.40404@cisco.com> From: Eliot Lear 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: Tim Price CC: "'Daniel Senie'" , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <026801c2f2dc$b4fece80$502119ac@pcprice> In-Reply-To: <026801c2f2dc$b4fece80$502119ac@pcprice> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 08:51:06 -0800 Content-Transfer-Encoding: 7bit Tim Price wrote: > Actually, you are not even close to being wrong, and I hope you don't give > up the ship. I have not been involved in the discussions other than the > recent flurry of emails, but my suspicion is that your opponents have a > completely skewed view of reality. I guarantee you there are hundreds of > thousands of small networks (connected or not) out there that are being > maintained by administrators with limited experience or training. They are > likely to be unfamiliar with the procedure for getting a network address, > nor are they likely to bother with the procedure. Additionally, these > networks are almost guaranteed to be connected by primitive means to the > Internet (but not necessarily at the same time as the initial configuration > of the network)- leading to a natural NAT situation. To start with, small networks should be well served by mechanisms such as prefix delegation. That delegation occurs in two ways: either automatic such as the way Droms, et. al have gone, and manual through the provisioning process (ie., use these addresses as opposed to others). This is done today in the real world. > I submit that as a > standards body you must address your entire intended audience, which means > that the least-common-denominator approach should be considered. No, this is not how one engineers. One engineers for the largest set of general use cases, not the least common denominator. > If the > argument is that address space in IPv6 is boundless, then retaining a block > of addresses for private use costs you absolutely nothing as a standards > body. It costs the end user peer to peer connectivity. > That doesn't necessarily mean that these addresses not be routed > across gateways, but at the very least guaranteeing the addresses won't be > registered helps. However, the logic needed in a router is minimal, which > also costs virtually nothing. If it costs nothing AND accommodates the > needs of a large segment of your audience then I submit you have a win-win > scenario. You could also provide security via identd. That costs virtually nothing, but offers about the same. > > I also suggest that you recognize the (sometimes unfortunate) need to > maintain backward compatibility. This is not a case of backward compatibility. You are changing protocols. Private network address space was offered due to address space shortage. That engineering requirement has evaporated. So should private address space. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 12:07:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21776 for ; Tue, 25 Mar 2003 12:07:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHLsO27753; Tue, 25 Mar 2003 12:21:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHIDO27630 for ; Tue, 25 Mar 2003 12:18:13 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21430 for ; Tue, 25 Mar 2003 11:57:19 -0500 (EST) Received: from cisco.com (sjc-vpn1-663.cisco.com [10.21.98.151]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA21884; Tue, 25 Mar 2003 08:58:35 -0800 (PST) Message-ID: <3E808ABA.7080303@cisco.com> From: Eliot Lear 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: "Manfredi, Albert E" CC: curtis@fictitious.org, Tony Li , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 08:58:34 -0800 Content-Transfer-Encoding: 7bit Manfredi, Albert E wrote: > And I don't think that IPv6, by design, should make it mandatory > for every private network to obtain globally unique addresses from > the IANA. That's sort of obnoxious. I would point out that (a) nobody suggested that addresses be gotten from IANA, and (b) globally unique addressses WERE the norm prior to the addressing shortage that precipitated RFC 1597. Also, the methods of peer-to-peer you mentioned involve a server. That's not peer to peer. Think telephones with IP addresses when you think about peer to peer. The fewer NATs you have the more reliable those conversations will be. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 12:08:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21798 for ; Tue, 25 Mar 2003 12:08:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PHSsT28104 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 12:28:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHLsO27753; Tue, 25 Mar 2003 12:21:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHIDO27630 for ; Tue, 25 Mar 2003 12:18:13 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21430 for ; Tue, 25 Mar 2003 11:57:19 -0500 (EST) Received: from cisco.com (sjc-vpn1-663.cisco.com [10.21.98.151]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA21884; Tue, 25 Mar 2003 08:58:35 -0800 (PST) Message-ID: <3E808ABA.7080303@cisco.com> From: Eliot Lear 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: "Manfredi, Albert E" CC: curtis@fictitious.org, Tony Li , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 08:58:34 -0800 Content-Transfer-Encoding: 7bit Manfredi, Albert E wrote: > And I don't think that IPv6, by design, should make it mandatory > for every private network to obtain globally unique addresses from > the IANA. That's sort of obnoxious. I would point out that (a) nobody suggested that addresses be gotten from IANA, and (b) globally unique addressses WERE the norm prior to the addressing shortage that precipitated RFC 1597. Also, the methods of peer-to-peer you mentioned involve a server. That's not peer to peer. Think telephones with IP addresses when you think about peer to peer. The fewer NATs you have the more reliable those conversations will be. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 12:15:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21949 for ; Tue, 25 Mar 2003 12:15:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHTTO28127; Tue, 25 Mar 2003 12:29:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHQiO28013 for ; Tue, 25 Mar 2003 12:26:44 -0500 Received: from blv-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21737 for ; Tue, 25 Mar 2003 12:05:49 -0500 (EST) Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA27114; Tue, 25 Mar 2003 09:08:06 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id JAA23286; Tue, 25 Mar 2003 09:08:05 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2PH84H04641; Tue, 25 Mar 2003 09:08:04 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Mar 2003 12:08:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLy7+je0bUEIWzxRL+iddSqas6j6wAABbfw From: "Manfredi, Albert E" To: "Eliot Lear" Cc: X-OriginalArrivalTime: 25 Mar 2003 17:08:02.0453 (UTC) FILETIME=[180FE450:01C2F2F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PHQiO28014 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 12:08:02 -0500 Content-Transfer-Encoding: 8bit Eliot Lear wrote: > Manfredi, Albert E wrote: > > > And I don't think that IPv6, by design, should make it mandatory > > for every private network to obtain globally unique addresses from > > the IANA. That's sort of obnoxious. > > I would point out that (a) nobody suggested that addresses be gotten > from IANA, and (b) globally unique addressses WERE the norm > prior to the > addressing shortage that precipitated RFC 1597. But, Eliot, things have evolved in the past decade. Internet Protocols are now being used for more than just e-mail and web browsing. So tools provided in IPv4 have been adapted quite nicely to solve problems for which they may not have been intended originally. We shouldn't have to ignore these perfectly legitimate solutions. I think enough people have expressed this general sentiment that perhaps it shouldn't be swept aside. > Also, the methods of peer-to-peer you mentioned involve a server. > That's not peer to peer. Think telephones with IP addresses when you > think about peer to peer. Yes, I'm well aware of what constitutes a peer-peer network. The mention of a server was an aside. I meant only to express that one _can_ easily implement a server with a NAT in the circuit. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 12:15:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21969 for ; Tue, 25 Mar 2003 12:15:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PHaFn28430 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 12:36:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHTTO28127; Tue, 25 Mar 2003 12:29:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHQiO28013 for ; Tue, 25 Mar 2003 12:26:44 -0500 Received: from blv-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21737 for ; Tue, 25 Mar 2003 12:05:49 -0500 (EST) Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA27114; Tue, 25 Mar 2003 09:08:06 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id JAA23286; Tue, 25 Mar 2003 09:08:05 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2PH84H04641; Tue, 25 Mar 2003 09:08:04 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Mar 2003 12:08:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLy7+je0bUEIWzxRL+iddSqas6j6wAABbfw From: "Manfredi, Albert E" To: "Eliot Lear" Cc: X-OriginalArrivalTime: 25 Mar 2003 17:08:02.0453 (UTC) FILETIME=[180FE450:01C2F2F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PHQiO28014 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 12:08:02 -0500 Content-Transfer-Encoding: 8bit Eliot Lear wrote: > Manfredi, Albert E wrote: > > > And I don't think that IPv6, by design, should make it mandatory > > for every private network to obtain globally unique addresses from > > the IANA. That's sort of obnoxious. > > I would point out that (a) nobody suggested that addresses be gotten > from IANA, and (b) globally unique addressses WERE the norm > prior to the > addressing shortage that precipitated RFC 1597. But, Eliot, things have evolved in the past decade. Internet Protocols are now being used for more than just e-mail and web browsing. So tools provided in IPv4 have been adapted quite nicely to solve problems for which they may not have been intended originally. We shouldn't have to ignore these perfectly legitimate solutions. I think enough people have expressed this general sentiment that perhaps it shouldn't be swept aside. > Also, the methods of peer-to-peer you mentioned involve a server. > That's not peer to peer. Think telephones with IP addresses when you > think about peer to peer. Yes, I'm well aware of what constitutes a peer-peer network. The mention of a server was an aside. I meant only to express that one _can_ easily implement a server with a NAT in the circuit. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 12:41:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22757 for ; Tue, 25 Mar 2003 12:41:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHuJO29904; Tue, 25 Mar 2003 12:56:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHrdO29830 for ; Tue, 25 Mar 2003 12:53:39 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22477 for ; Tue, 25 Mar 2003 12:32:44 -0500 (EST) Received: from cisco.com (sjc-vpn1-663.cisco.com [10.21.98.151]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA04126; Tue, 25 Mar 2003 09:35:01 -0800 (PST) Message-ID: <3E809345.7030103@cisco.com> From: Eliot Lear 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: "Manfredi, Albert E" CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 09:35:01 -0800 Content-Transfer-Encoding: 7bit Bert, What you describe as tools I would call coping mechanisms. On the other hand, if you like what you have now, why bother moving to IPv6? Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 12:42:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22782 for ; Tue, 25 Mar 2003 12:42:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PI2jR30243 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 13:02:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHuJO29904; Tue, 25 Mar 2003 12:56:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PHrdO29830 for ; Tue, 25 Mar 2003 12:53:39 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22477 for ; Tue, 25 Mar 2003 12:32:44 -0500 (EST) Received: from cisco.com (sjc-vpn1-663.cisco.com [10.21.98.151]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA04126; Tue, 25 Mar 2003 09:35:01 -0800 (PST) Message-ID: <3E809345.7030103@cisco.com> From: Eliot Lear 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: "Manfredi, Albert E" CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 09:35:01 -0800 Content-Transfer-Encoding: 7bit Bert, What you describe as tools I would call coping mechanisms. On the other hand, if you like what you have now, why bother moving to IPv6? Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 14:12:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26035 for ; Tue, 25 Mar 2003 14:12:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJQVO04075; Tue, 25 Mar 2003 14:26:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJLkO03859 for ; Tue, 25 Mar 2003 14:21:46 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25568 for ; Tue, 25 Mar 2003 14:00:48 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 3D643137F09; Tue, 25 Mar 2003 11:03:09 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Jing Shen , jshen@cad.zju.edu.cn, routing-discussion@ietf.org To: Roland Bless From: David Conrad In-Reply-To: Message-Id: <6B143CDB-5EF4-11D7-BDFE-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:03:09 -0800 Content-Transfer-Encoding: 7bit Roland, On Tuesday, March 25, 2003, at 02:03 AM, Roland Bless wrote: > Private adressing does not add any protection or security!! Not quite true. It isn't something that you can rely on, but it does raise the barrier somewhat. When there are hundreds of sites out there running unpatched old versions of BIND or IIS or whatever on the public Internet, why waste your time breaking through a NAT box? > The ONLY reason to use NAT was the lack of enough addresses. No. Another reason is that companies do not want to be held hostage due to the cost of renumbering which many would feel would be the case should they want to change providers. > This reason is thus not applicable for IPv6. No. IPv6 uses provider based addressing, thus if you want the routing system to scale, you must renumber if you change providers. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 14:13:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26075 for ; Tue, 25 Mar 2003 14:13:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJXST04544 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 14:33:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJQVO04075; Tue, 25 Mar 2003 14:26:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJLkO03859 for ; Tue, 25 Mar 2003 14:21:46 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25568 for ; Tue, 25 Mar 2003 14:00:48 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 3D643137F09; Tue, 25 Mar 2003 11:03:09 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Jing Shen , jshen@cad.zju.edu.cn, routing-discussion@ietf.org To: Roland Bless From: David Conrad In-Reply-To: Message-Id: <6B143CDB-5EF4-11D7-BDFE-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:03:09 -0800 Content-Transfer-Encoding: 7bit Roland, On Tuesday, March 25, 2003, at 02:03 AM, Roland Bless wrote: > Private adressing does not add any protection or security!! Not quite true. It isn't something that you can rely on, but it does raise the barrier somewhat. When there are hundreds of sites out there running unpatched old versions of BIND or IIS or whatever on the public Internet, why waste your time breaking through a NAT box? > The ONLY reason to use NAT was the lack of enough addresses. No. Another reason is that companies do not want to be held hostage due to the cost of renumbering which many would feel would be the case should they want to change providers. > This reason is thus not applicable for IPv6. No. IPv6 uses provider based addressing, thus if you want the routing system to scale, you must renumber if you change providers. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 14:14:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26113 for ; Tue, 25 Mar 2003 14:14:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJSvO04230; Tue, 25 Mar 2003 14:28:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJPAO04041 for ; Tue, 25 Mar 2003 14:25:10 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25701 for ; Tue, 25 Mar 2003 14:04:12 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 8B1C0137F09; Tue, 25 Mar 2003 11:06:32 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: curtis@fictitious.org, Eliot Lear , Daniel Senie , routing-discussion@ietf.org To: fredrik@packetfront.com From: David Conrad In-Reply-To: <3E80354D.21553.60824279@localhost> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:06:32 -0800 Content-Transfer-Encoding: 7bit Fredrik, On Tuesday, March 25, 2003, at 01:54 AM, Fredrik Nyman wrote: > Since the argument is that there is enough IPv6 address space to go > around, what is the > harm of allocating a piece of it and call it private address space? People using the same addresses for private address space (a la 10/8) make companies merging painful. If people aren't concerned about the inefficiencies of allocating address space that will not be routed, it would be much better for folks to get globally unique addresses. The problem is, people make this assumption that if it is globally unique it _will_ (not just _can_) be routed when presented to a service provider. Hence, the swamp. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 14:15:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26135 for ; Tue, 25 Mar 2003 14:15:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJZcI04633 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 14:35:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJSvO04230; Tue, 25 Mar 2003 14:28:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJPAO04041 for ; Tue, 25 Mar 2003 14:25:10 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25701 for ; Tue, 25 Mar 2003 14:04:12 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 8B1C0137F09; Tue, 25 Mar 2003 11:06:32 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: curtis@fictitious.org, Eliot Lear , Daniel Senie , routing-discussion@ietf.org To: fredrik@packetfront.com From: David Conrad In-Reply-To: <3E80354D.21553.60824279@localhost> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:06:32 -0800 Content-Transfer-Encoding: 7bit Fredrik, On Tuesday, March 25, 2003, at 01:54 AM, Fredrik Nyman wrote: > Since the argument is that there is enough IPv6 address space to go > around, what is the > harm of allocating a piece of it and call it private address space? People using the same addresses for private address space (a la 10/8) make companies merging painful. If people aren't concerned about the inefficiencies of allocating address space that will not be routed, it would be much better for folks to get globally unique addresses. The problem is, people make this assumption that if it is globally unique it _will_ (not just _can_) be routed when presented to a service provider. Hence, the swamp. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 14:15:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26166 for ; Tue, 25 Mar 2003 14:15:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJUuO04312; Tue, 25 Mar 2003 14:30:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJPoO04058 for ; Tue, 25 Mar 2003 14:25:50 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25724 for ; Tue, 25 Mar 2003 14:04:51 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA13904; Tue, 25 Mar 2003 14:07:49 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303251907.OAA13904@workhorse.fictitious.org> To: "Manfredi, Albert E" cc: curtis@fictitious.org, "Tony Li" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 10:56:54 EST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 14:07:49 -0500 In message , "Manfredi, Albert E" writes: > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > NATs very much get in the way of peer-to-peer in case you weren't > > aware of that. Try running any kind of server behind a NAT and > > accessing it from outside the NAT. If two factory widgets are behind > > the same NAT they need unique addresses and you're back to DHCP or > > configured addresses. > > If the entire peer-peer network is behind the NAT, the NAT won't bother it in > the slightest. That was the scenario I was describing. Multiple such systems > , installed in many different sites, all of them internally identical. But then you need to assign addresses within the private address block. Identical addresses cannot be assigned at the factory. If some widgets take on server roles their addresses must be well known. > If there is a server outside the NAT, once again, the peer-peer network can r > emain identical in all instances and the NAT will take care of making the ser > ver appear identical to all hosts inside the NAT. > > Comms outside the NAT may be expected to be infrequent, e.g. primarily for oc > casional remote system monitoring or remote troubleshooting. And these sessio > ns may always be initiated outside the NAT, leaving the peer-peer network unc > hangerd in every case. If you are replicating a cluster of processors, in which there are a small number of processors each with a role, an initial address can be assigned from *your address spec* for initialization. With each initialization, each processor can learn its real address. No NAT, just an address learned in the boot process. If the application is making a hew hundred planes, all with the same N processors on them, then only one has to have an address configured on it (just like the NAT would have to have an address configured) and it could provide addresses to the others. The initialization addresses could be arranged to be not routeable outside of the network segment (plane). Each plane has a unique address. Each component within the plane has a unique address. Only N (a small number) of addresses must be reused within the provider address block. The IPv6 autoconfig can be that method of initialization unless security requirements dictate use of something else. > My problem with all the arguments against a private address space in IPv6, an > d all the arguments in RFC 1627 too for that matter, is that these arguments > assume the only motivation is to economize on address space. And yet, plenty > of people have indicated otherwise. > > Yes, it is always possible to create private networks with real but illegal g > lobal addresses. That's a nuisance and prone to creating problems. And I don' > t think that IPv6, by design, should make it mandatory for every private netw > ork to obtain globally unique addresses from the IANA. That's sort of obnoxio > us. > > Bert You can also create private addresses by reusing allocated addresses multiple times if that's all you want to do. That assumes you have some allocated address space and want to reuse a subset of it. Problems with the registries overcharging for IPv6 address space (selling sand in the desert at a very high price being the going analogy) are a separate issue. However since it is a very real issue, it may be worth keeping the existing IPv6 private address space block until such time as that issue is resolved, then depricating it. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 14:16:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26252 for ; Tue, 25 Mar 2003 14:16:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJalo04701 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 14:36:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJUuO04312; Tue, 25 Mar 2003 14:30:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJPoO04058 for ; Tue, 25 Mar 2003 14:25:50 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25724 for ; Tue, 25 Mar 2003 14:04:51 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA13904; Tue, 25 Mar 2003 14:07:49 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303251907.OAA13904@workhorse.fictitious.org> To: "Manfredi, Albert E" cc: curtis@fictitious.org, "Tony Li" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 10:56:54 EST." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 14:07:49 -0500 In message , "Manfredi, Albert E" writes: > > From: Curtis Villamizar [mailto:curtis@fictitious.org] > > > NATs very much get in the way of peer-to-peer in case you weren't > > aware of that. Try running any kind of server behind a NAT and > > accessing it from outside the NAT. If two factory widgets are behind > > the same NAT they need unique addresses and you're back to DHCP or > > configured addresses. > > If the entire peer-peer network is behind the NAT, the NAT won't bother it in > the slightest. That was the scenario I was describing. Multiple such systems > , installed in many different sites, all of them internally identical. But then you need to assign addresses within the private address block. Identical addresses cannot be assigned at the factory. If some widgets take on server roles their addresses must be well known. > If there is a server outside the NAT, once again, the peer-peer network can r > emain identical in all instances and the NAT will take care of making the ser > ver appear identical to all hosts inside the NAT. > > Comms outside the NAT may be expected to be infrequent, e.g. primarily for oc > casional remote system monitoring or remote troubleshooting. And these sessio > ns may always be initiated outside the NAT, leaving the peer-peer network unc > hangerd in every case. If you are replicating a cluster of processors, in which there are a small number of processors each with a role, an initial address can be assigned from *your address spec* for initialization. With each initialization, each processor can learn its real address. No NAT, just an address learned in the boot process. If the application is making a hew hundred planes, all with the same N processors on them, then only one has to have an address configured on it (just like the NAT would have to have an address configured) and it could provide addresses to the others. The initialization addresses could be arranged to be not routeable outside of the network segment (plane). Each plane has a unique address. Each component within the plane has a unique address. Only N (a small number) of addresses must be reused within the provider address block. The IPv6 autoconfig can be that method of initialization unless security requirements dictate use of something else. > My problem with all the arguments against a private address space in IPv6, an > d all the arguments in RFC 1627 too for that matter, is that these arguments > assume the only motivation is to economize on address space. And yet, plenty > of people have indicated otherwise. > > Yes, it is always possible to create private networks with real but illegal g > lobal addresses. That's a nuisance and prone to creating problems. And I don' > t think that IPv6, by design, should make it mandatory for every private netw > ork to obtain globally unique addresses from the IANA. That's sort of obnoxio > us. > > Bert You can also create private addresses by reusing allocated addresses multiple times if that's all you want to do. That assumes you have some allocated address space and want to reuse a subset of it. Problems with the registries overcharging for IPv6 address space (selling sand in the desert at a very high price being the going analogy) are a separate issue. However since it is a very real issue, it may be worth keeping the existing IPv6 private address space block until such time as that issue is resolved, then depricating it. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 14:24:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26790 for ; Tue, 25 Mar 2003 14:24:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJd0O05625; Tue, 25 Mar 2003 14:39:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJaVO04691 for ; Tue, 25 Mar 2003 14:36:31 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26160 for ; Tue, 25 Mar 2003 14:15:35 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 05A35137F09; Tue, 25 Mar 2003 11:17:54 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Manfredi, Albert E" , curtis@fictitious.org, Tony Li , routing-discussion@ietf.org To: Eliot Lear From: David Conrad In-Reply-To: <3E808ABA.7080303@cisco.com> Message-Id: <7A4D1A72-5EF6-11D7-BDFE-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:17:53 -0800 Content-Transfer-Encoding: 7bit Eliot, On Tuesday, March 25, 2003, at 08:58 AM, Eliot Lear wrote: > I would point out that (a) nobody suggested that addresses be gotten > from IANA, and (b) globally unique addressses WERE the norm prior to > the addressing shortage that precipitated RFC 1597. Just to be clear, it wasn't only a perceived address shortage that precipitated 1597, it was also the need for folks to move to provider based addressing. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 14:25:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26837 for ; Tue, 25 Mar 2003 14:25:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJjvo06065 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 14:45:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJd0O05625; Tue, 25 Mar 2003 14:39:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJaVO04691 for ; Tue, 25 Mar 2003 14:36:31 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26160 for ; Tue, 25 Mar 2003 14:15:35 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 05A35137F09; Tue, 25 Mar 2003 11:17:54 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Manfredi, Albert E" , curtis@fictitious.org, Tony Li , routing-discussion@ietf.org To: Eliot Lear From: David Conrad In-Reply-To: <3E808ABA.7080303@cisco.com> Message-Id: <7A4D1A72-5EF6-11D7-BDFE-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:17:53 -0800 Content-Transfer-Encoding: 7bit Eliot, On Tuesday, March 25, 2003, at 08:58 AM, Eliot Lear wrote: > I would point out that (a) nobody suggested that addresses be gotten > from IANA, and (b) globally unique addressses WERE the norm prior to > the addressing shortage that precipitated RFC 1597. Just to be clear, it wasn't only a perceived address shortage that precipitated 1597, it was also the need for folks to move to provider based addressing. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 14:34:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27392 for ; Tue, 25 Mar 2003 14:34:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJmoO06217; Tue, 25 Mar 2003 14:48:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJamO04714 for ; Tue, 25 Mar 2003 14:36:48 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26181 for ; Tue, 25 Mar 2003 14:15:52 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA13983; Tue, 25 Mar 2003 14:18:57 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303251918.OAA13983@workhorse.fictitious.org> To: Jing Shen cc: Roland Bless , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 22:06:09 +0800." <20030325140609.92361.qmail@web15103.mail.bjs.yahoo.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 14:18:57 -0500 In message <20030325140609.92361.qmail@web15103.mail.bjs.yahoo.com>, Jing Shen writes: > --0-539720083-1048601169=:92214 > Content-Type: text/plain; charset=gb2312 > Content-Transfer-Encoding: 8bit > > > Hi, > > The reason why I think it's reasonable to reserve a private address > > block is it's easy to be understanded and those information could be > > easily filtered out when advertising routing information. ( think > > about such a situation: we use 13.1.1.23 as internal address, while we > > try to access 13.1.1.23 from 13.1.1.23 ). > > > I think NAT is useful when someone tries to protect its internal > > network while providing good connection ( although there do exist some > > problems). > > >You can achieve the same security with appropriate filter settings > >or "normal" addresses. > > why? how could we mask private network strucuture from outside? > > thanks > > regards > > Jing Shen You number all of your servers that you want to have access to the outside world in a subnet and filter to the rest. It is more common to allow only certain services to the rest. For example, allowing port 80 but not port 25 if you feel that clients may be using insecure smtp software that could be attacked. This particular usage was common when sendmail still had a high rate of security patches and individually administered workstations may not be updated as often as they should be. Also you could disallow any access to a portion of the internal address space and use application gateways such as POP/IMAP or (restricted) mail relay and ftp and web proxy. Filters can be confitured to allow specific services such as ssh. What this (and NAT) doesn't do is allow filtering based control of internal users. Clever user have put all sorts of services inside port 80 and even over HTTP. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 14:34:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27472 for ; Tue, 25 Mar 2003 14:34:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJtOY06759 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 14:55:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJmoO06217; Tue, 25 Mar 2003 14:48:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJamO04714 for ; Tue, 25 Mar 2003 14:36:48 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26181 for ; Tue, 25 Mar 2003 14:15:52 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA13983; Tue, 25 Mar 2003 14:18:57 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303251918.OAA13983@workhorse.fictitious.org> To: Jing Shen cc: Roland Bless , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 22:06:09 +0800." <20030325140609.92361.qmail@web15103.mail.bjs.yahoo.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 14:18:57 -0500 In message <20030325140609.92361.qmail@web15103.mail.bjs.yahoo.com>, Jing Shen writes: > --0-539720083-1048601169=:92214 > Content-Type: text/plain; charset=gb2312 > Content-Transfer-Encoding: 8bit > > > Hi, > > The reason why I think it's reasonable to reserve a private address > > block is it's easy to be understanded and those information could be > > easily filtered out when advertising routing information. ( think > > about such a situation: we use 13.1.1.23 as internal address, while we > > try to access 13.1.1.23 from 13.1.1.23 ). > > > I think NAT is useful when someone tries to protect its internal > > network while providing good connection ( although there do exist some > > problems). > > >You can achieve the same security with appropriate filter settings > >or "normal" addresses. > > why? how could we mask private network strucuture from outside? > > thanks > > regards > > Jing Shen You number all of your servers that you want to have access to the outside world in a subnet and filter to the rest. It is more common to allow only certain services to the rest. For example, allowing port 80 but not port 25 if you feel that clients may be using insecure smtp software that could be attacked. This particular usage was common when sendmail still had a high rate of security patches and individually administered workstations may not be updated as often as they should be. Also you could disallow any access to a portion of the internal address space and use application gateways such as POP/IMAP or (restricted) mail relay and ftp and web proxy. Filters can be confitured to allow specific services such as ssh. What this (and NAT) doesn't do is allow filtering based control of internal users. Clever user have put all sorts of services inside port 80 and even over HTTP. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 14:36:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27536 for ; Tue, 25 Mar 2003 14:36:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJklO06103; Tue, 25 Mar 2003 14:46:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJXjO04560 for ; Tue, 25 Mar 2003 14:33:45 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26069 for ; Tue, 25 Mar 2003 14:12:49 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id AB523137F09; Tue, 25 Mar 2003 11:15:07 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Tim Price , "'Daniel Senie'" , routing-discussion@ietf.org To: Eliot Lear From: David Conrad In-Reply-To: <3E8088FA.40404@cisco.com> Message-Id: <17525F2D-5EF6-11D7-BDFE-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:15:07 -0800 Content-Transfer-Encoding: 7bit Eliot, On Tuesday, March 25, 2003, at 08:51 AM, Eliot Lear wrote: > To start with, small networks should be well served by mechanisms such > as prefix delegation. Along with the mechanisms to (for example) rewrite the filter lists on the separate firewall box? Can you point me at the protocol spec to do this? > This is not a case of backward compatibility. You are changing > protocols. Private network address space was offered due to address > space shortage. Only partly. It was also offered: - to remove dealing with registries or ISPs and justifying the need for addresses - to enable provider independence by removing the need to renumber > That engineering requirement has evaporated. The _perceived_ IPv4 address shortage has evaporated. The other aspects of what has driven NAT have not and will not unless IPv6 is fixed. > So should private address space. And their should be peace in the world. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 14:37:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27591 for ; Tue, 25 Mar 2003 14:37:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJvnu06911 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 14:57:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJklO06103; Tue, 25 Mar 2003 14:46:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJXjO04560 for ; Tue, 25 Mar 2003 14:33:45 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26069 for ; Tue, 25 Mar 2003 14:12:49 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id AB523137F09; Tue, 25 Mar 2003 11:15:07 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Tim Price , "'Daniel Senie'" , routing-discussion@ietf.org To: Eliot Lear From: David Conrad In-Reply-To: <3E8088FA.40404@cisco.com> Message-Id: <17525F2D-5EF6-11D7-BDFE-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:15:07 -0800 Content-Transfer-Encoding: 7bit Eliot, On Tuesday, March 25, 2003, at 08:51 AM, Eliot Lear wrote: > To start with, small networks should be well served by mechanisms such > as prefix delegation. Along with the mechanisms to (for example) rewrite the filter lists on the separate firewall box? Can you point me at the protocol spec to do this? > This is not a case of backward compatibility. You are changing > protocols. Private network address space was offered due to address > space shortage. Only partly. It was also offered: - to remove dealing with registries or ISPs and justifying the need for addresses - to enable provider independence by removing the need to renumber > That engineering requirement has evaporated. The _perceived_ IPv4 address shortage has evaporated. The other aspects of what has driven NAT have not and will not unless IPv6 is fixed. > So should private address space. And their should be peace in the world. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 14:45:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27879 for ; Tue, 25 Mar 2003 14:45:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJvEO06851; Tue, 25 Mar 2003 14:57:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJorO06468 for ; Tue, 25 Mar 2003 14:50:53 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27065 for ; Tue, 25 Mar 2003 14:29:57 -0500 (EST) Received: from cisco.com (sjc-vpn3-131.cisco.com [10.21.64.131]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA14796; Tue, 25 Mar 2003 11:31:29 -0800 (PST) Message-ID: <3E80AE90.8000506@cisco.com> From: Eliot Lear 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: David Conrad CC: "Manfredi, Albert E" , curtis@fictitious.org, Tony Li , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <7A4D1A72-5EF6-11D7-BDFE-000393DB42B2@nominum.com> In-Reply-To: <7A4D1A72-5EF6-11D7-BDFE-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:31:28 -0800 Content-Transfer-Encoding: 7bit [Working backwards] David Conrad wrote: > Just to be clear, it wasn't only a perceived address shortage that > precipitated 1597, it was also the need for folks to move to provider > based addressing. Only in as much as people began to use NATs to isolate themselves from having to renumber. Fix the renumbering problem and all of this goes away. Don't fix the renumbering problem and IPv6 isn't ready for prime time with or without site-locals. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 14:46:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27944 for ; Tue, 25 Mar 2003 14:46:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PK6ap07633 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 15:06:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJvEO06851; Tue, 25 Mar 2003 14:57:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJorO06468 for ; Tue, 25 Mar 2003 14:50:53 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27065 for ; Tue, 25 Mar 2003 14:29:57 -0500 (EST) Received: from cisco.com (sjc-vpn3-131.cisco.com [10.21.64.131]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA14796; Tue, 25 Mar 2003 11:31:29 -0800 (PST) Message-ID: <3E80AE90.8000506@cisco.com> From: Eliot Lear 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: David Conrad CC: "Manfredi, Albert E" , curtis@fictitious.org, Tony Li , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <7A4D1A72-5EF6-11D7-BDFE-000393DB42B2@nominum.com> In-Reply-To: <7A4D1A72-5EF6-11D7-BDFE-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:31:28 -0800 Content-Transfer-Encoding: 7bit [Working backwards] David Conrad wrote: > Just to be clear, it wasn't only a perceived address shortage that > precipitated 1597, it was also the need for folks to move to provider > based addressing. Only in as much as people began to use NATs to isolate themselves from having to renumber. Fix the renumbering problem and all of this goes away. Don't fix the renumbering problem and IPv6 isn't ready for prime time with or without site-locals. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 14:48:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28072 for ; Tue, 25 Mar 2003 14:48:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PK39O07367; Tue, 25 Mar 2003 15:03:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJxQO07153 for ; Tue, 25 Mar 2003 14:59:26 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27633 for ; Tue, 25 Mar 2003 14:38:30 -0500 (EST) Received: from cisco.com (sjc-vpn3-131.cisco.com [10.21.64.131]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA03533; Tue, 25 Mar 2003 11:40:15 -0800 (PST) Message-ID: <3E80B09E.6050008@cisco.com> From: Eliot Lear 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: David Conrad CC: Tim Price , "'Daniel Senie'" , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <17525F2D-5EF6-11D7-BDFE-000393DB42B2@nominum.com> In-Reply-To: <17525F2D-5EF6-11D7-BDFE-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:40:14 -0800 Content-Transfer-Encoding: 7bit Gosh I feel like I've been here before ;-( >> To start with, small networks should be well served by mechanisms such >> as prefix delegation. > > > Along with the mechanisms to (for example) rewrite the filter lists on > the separate firewall box? Can you point me at the protocol spec to do > this? That's a provisioning function, so that would be scp. To be fair, I think you're right that there could be better tools in this area. It's not clear to me that a *protocol* is the right answer, but certainly tools are. That having been said, we're overstating the relationship of renumbering and site-locals. You have to be able to renumber the public portions of the network. If you can't do that then IPv6 isn't ready for prime time anyway, as I mentioned previously. > >> This is not a case of backward compatibility. You are changing >> protocols. Private network address space was offered due to address >> space shortage. > > > Only partly. It was also offered: > - to remove dealing with registries or ISPs and justifying the need for > addresses That is due to address space exhaustion. > - to enable provider independence by removing the need to renumber You've got to fix this problem *anyway* or there's no point of moving to IPv6. > >> That engineering requirement has evaporated. > > > The _perceived_ IPv4 address shortage has evaporated. The other aspects > of what has driven NAT have not and will not unless IPv6 is fixed. As we wrote in RFC 1627, we already ran out of v4 addresses the moment we had to use private address space. Because of this the network lost functionality. The end to end principle was violated. If we can't fix it with IPv6 let's not bother moving forward and live with what we've got. We could all save a lot of time and effort. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 14:49:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28147 for ; Tue, 25 Mar 2003 14:49:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PK9Yq08648 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 15:09:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PK39O07367; Tue, 25 Mar 2003 15:03:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJxQO07153 for ; Tue, 25 Mar 2003 14:59:26 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27633 for ; Tue, 25 Mar 2003 14:38:30 -0500 (EST) Received: from cisco.com (sjc-vpn3-131.cisco.com [10.21.64.131]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA03533; Tue, 25 Mar 2003 11:40:15 -0800 (PST) Message-ID: <3E80B09E.6050008@cisco.com> From: Eliot Lear 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: David Conrad CC: Tim Price , "'Daniel Senie'" , routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <17525F2D-5EF6-11D7-BDFE-000393DB42B2@nominum.com> In-Reply-To: <17525F2D-5EF6-11D7-BDFE-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 11:40:14 -0800 Content-Transfer-Encoding: 7bit Gosh I feel like I've been here before ;-( >> To start with, small networks should be well served by mechanisms such >> as prefix delegation. > > > Along with the mechanisms to (for example) rewrite the filter lists on > the separate firewall box? Can you point me at the protocol spec to do > this? That's a provisioning function, so that would be scp. To be fair, I think you're right that there could be better tools in this area. It's not clear to me that a *protocol* is the right answer, but certainly tools are. That having been said, we're overstating the relationship of renumbering and site-locals. You have to be able to renumber the public portions of the network. If you can't do that then IPv6 isn't ready for prime time anyway, as I mentioned previously. > >> This is not a case of backward compatibility. You are changing >> protocols. Private network address space was offered due to address >> space shortage. > > > Only partly. It was also offered: > - to remove dealing with registries or ISPs and justifying the need for > addresses That is due to address space exhaustion. > - to enable provider independence by removing the need to renumber You've got to fix this problem *anyway* or there's no point of moving to IPv6. > >> That engineering requirement has evaporated. > > > The _perceived_ IPv4 address shortage has evaporated. The other aspects > of what has driven NAT have not and will not unless IPv6 is fixed. As we wrote in RFC 1627, we already ran out of v4 addresses the moment we had to use private address space. Because of this the network lost functionality. The end to end principle was violated. If we can't fix it with IPv6 let's not bother moving forward and live with what we've got. We could all save a lot of time and effort. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 15:31:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01872 for ; Tue, 25 Mar 2003 15:31:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKjFO12250; Tue, 25 Mar 2003 15:45:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKcuO11743 for ; Tue, 25 Mar 2003 15:38:56 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00988 for ; Tue, 25 Mar 2003 15:17:57 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA14478; Tue, 25 Mar 2003 15:21:00 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303252021.PAA14478@workhorse.fictitious.org> To: David Conrad cc: Roland Bless , Jing Shen , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: NAT and security (was Re: IPv6 site-locals... end of story...) In-reply-to: Your message of "Tue, 25 Mar 2003 11:03:09 PST." <6B143CDB-5EF4-11D7-BDFE-000393DB42B2@nominum.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 15:21:00 -0500 In message <6B143CDB-5EF4-11D7-BDFE-000393DB42B2@nominum.com>, David Conrad wri tes: > Roland, > > On Tuesday, March 25, 2003, at 02:03 AM, Roland Bless wrote: > > Private adressing does not add any protection or security!! > > Not quite true. It isn't something that you can rely on, but it does > raise the barrier somewhat. When there are hundreds of sites out there > running unpatched old versions of BIND or IIS or whatever on the public > Internet, why waste your time breaking through a NAT box? > > > Rgds, > -drc This security subthread is wandering off topic. Surfice to say that if someone just want to break into no place in particular, they go for the easiest targets. If they want to break into somewhere specific, they (try to) find a way around whatever is there. In that latter case, NAT provides a very ineffective barrier relative to the same level of packet filtering without NAT, which is also quite ineffective against many forms of attack. The most secure networks I've used did not use NAT and had minimal packet filtering but rather were directly connected to the Internet and used cryptographic authentication and payload encryption on any service needing to be secure. With those measures packet filtering added little further benefit but was used anyway, mostly to prevent a few common forms of traffic based DoS attack. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 15:31:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01918 for ; Tue, 25 Mar 2003 15:31:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKqFp12980 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 15:52:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKjFO12250; Tue, 25 Mar 2003 15:45:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKcuO11743 for ; Tue, 25 Mar 2003 15:38:56 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00988 for ; Tue, 25 Mar 2003 15:17:57 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA14478; Tue, 25 Mar 2003 15:21:00 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303252021.PAA14478@workhorse.fictitious.org> To: David Conrad cc: Roland Bless , Jing Shen , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: NAT and security (was Re: IPv6 site-locals... end of story...) In-reply-to: Your message of "Tue, 25 Mar 2003 11:03:09 PST." <6B143CDB-5EF4-11D7-BDFE-000393DB42B2@nominum.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 15:21:00 -0500 In message <6B143CDB-5EF4-11D7-BDFE-000393DB42B2@nominum.com>, David Conrad wri tes: > Roland, > > On Tuesday, March 25, 2003, at 02:03 AM, Roland Bless wrote: > > Private adressing does not add any protection or security!! > > Not quite true. It isn't something that you can rely on, but it does > raise the barrier somewhat. When there are hundreds of sites out there > running unpatched old versions of BIND or IIS or whatever on the public > Internet, why waste your time breaking through a NAT box? > > > Rgds, > -drc This security subthread is wandering off topic. Surfice to say that if someone just want to break into no place in particular, they go for the easiest targets. If they want to break into somewhere specific, they (try to) find a way around whatever is there. In that latter case, NAT provides a very ineffective barrier relative to the same level of packet filtering without NAT, which is also quite ineffective against many forms of attack. The most secure networks I've used did not use NAT and had minimal packet filtering but rather were directly connected to the Internet and used cryptographic authentication and payload encryption on any service needing to be secure. With those measures packet filtering added little further benefit but was used anyway, mostly to prevent a few common forms of traffic based DoS attack. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 15:45:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02656 for ; Tue, 25 Mar 2003 15:45:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PL0IO13625; Tue, 25 Mar 2003 16:00:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKv4O13462 for ; Tue, 25 Mar 2003 15:57:04 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02206 for ; Tue, 25 Mar 2003 15:36:06 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA14741; Tue, 25 Mar 2003 15:39:07 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303252039.PAA14741@workhorse.fictitious.org> To: Eliot Lear cc: David Conrad , Tim Price , "'Daniel Senie'" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 11:40:14 PST." <3E80B09E.6050008@cisco.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 15:39:07 -0500 In message <3E80B09E.6050008@cisco.com>, Eliot Lear writes: > > > > The _perceived_ IPv4 address shortage has evaporated. The other aspects > > of what has driven NAT have not and will not unless IPv6 is fixed. > > As we wrote in RFC 1627, we already ran out of v4 addresses the moment > we had to use private address space. Because of this the network lost > functionality. The end to end principle was violated. If we can't fix > it with IPv6 let's not bother moving forward and live with what we've > got. We could all save a lot of time and effort. > > Eliot We never ran out of IPv4 address space and most of it is still unused. We are allocating it more cautiously so that we don't run out in the future due to severely sloppy localized numbering or due to hoarding. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 15:46:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02707 for ; Tue, 25 Mar 2003 15:46:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PL6vg14123 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 16:06:57 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PL0IO13625; Tue, 25 Mar 2003 16:00:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKv4O13462 for ; Tue, 25 Mar 2003 15:57:04 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02206 for ; Tue, 25 Mar 2003 15:36:06 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA14741; Tue, 25 Mar 2003 15:39:07 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303252039.PAA14741@workhorse.fictitious.org> To: Eliot Lear cc: David Conrad , Tim Price , "'Daniel Senie'" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: IPv6 site-locals... end of story... In-reply-to: Your message of "Tue, 25 Mar 2003 11:40:14 PST." <3E80B09E.6050008@cisco.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 15:39:07 -0500 In message <3E80B09E.6050008@cisco.com>, Eliot Lear writes: > > > > The _perceived_ IPv4 address shortage has evaporated. The other aspects > > of what has driven NAT have not and will not unless IPv6 is fixed. > > As we wrote in RFC 1627, we already ran out of v4 addresses the moment > we had to use private address space. Because of this the network lost > functionality. The end to end principle was violated. If we can't fix > it with IPv6 let's not bother moving forward and live with what we've > got. We could all save a lot of time and effort. > > Eliot We never ran out of IPv4 address space and most of it is still unused. We are allocating it more cautiously so that we don't run out in the future due to severely sloppy localized numbering or due to hoarding. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 16:52:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05569 for ; Tue, 25 Mar 2003 16:52:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PM6fO19319; Tue, 25 Mar 2003 17:06:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PM3rO19093 for ; Tue, 25 Mar 2003 17:03:53 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05138 for ; Tue, 25 Mar 2003 16:42:53 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 1B2BB137F09; Tue, 25 Mar 2003 13:45:13 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Tim Price , "'Daniel Senie'" , routing-discussion@ietf.org To: Eliot Lear From: David Conrad In-Reply-To: <3E80B09E.6050008@cisco.com> Message-Id: <0F1F236C-5F0B-11D7-BDFE-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 13:45:13 -0800 Content-Transfer-Encoding: 7bit Eliot, On Tuesday, March 25, 2003, at 11:40 AM, Eliot Lear wrote: > You have to be able to renumber the public portions of the network. > If you can't do that then IPv6 isn't ready for prime time anyway, as I > mentioned previously. I agree. >> - to remove dealing with registries or ISPs and justifying the need >> for addresses > That is due to address space exhaustion. Yes, that is how it started. It would be interesting to see how much of ISP revenues now derive from address space charges (I know I'm paying quite a bit per month for the 8 static IP address I have) and how amused ISPs will be to forgo those charges. But perhaps I'm too cynical. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 16:53:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05592 for ; Tue, 25 Mar 2003 16:53:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PMDVT20428 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 17:13:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PM6fO19319; Tue, 25 Mar 2003 17:06:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PM3rO19093 for ; Tue, 25 Mar 2003 17:03:53 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05138 for ; Tue, 25 Mar 2003 16:42:53 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 1B2BB137F09; Tue, 25 Mar 2003 13:45:13 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Tim Price , "'Daniel Senie'" , routing-discussion@ietf.org To: Eliot Lear From: David Conrad In-Reply-To: <3E80B09E.6050008@cisco.com> Message-Id: <0F1F236C-5F0B-11D7-BDFE-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 13:45:13 -0800 Content-Transfer-Encoding: 7bit Eliot, On Tuesday, March 25, 2003, at 11:40 AM, Eliot Lear wrote: > You have to be able to renumber the public portions of the network. > If you can't do that then IPv6 isn't ready for prime time anyway, as I > mentioned previously. I agree. >> - to remove dealing with registries or ISPs and justifying the need >> for addresses > That is due to address space exhaustion. Yes, that is how it started. It would be interesting to see how much of ISP revenues now derive from address space charges (I know I'm paying quite a bit per month for the 8 static IP address I have) and how amused ISPs will be to forgo those charges. But perhaps I'm too cynical. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 17:00:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05848 for ; Tue, 25 Mar 2003 17:00:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PM92O20194; Tue, 25 Mar 2003 17:09:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PM4BO19142 for ; Tue, 25 Mar 2003 17:04:11 -0500 Received: from stl-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05171 for ; Tue, 25 Mar 2003 16:43:11 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA24916; Tue, 25 Mar 2003 15:45:30 -0600 (CST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id PAA14665; Tue, 25 Mar 2003 15:45:29 -0600 (CST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2PLjRl26584; Tue, 25 Mar 2003 13:45:28 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Mar 2003 16:45:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLzFIpw6U7xVUogQcy3yL0ul/UPQwAAEGww From: "Manfredi, Albert E" To: "Eliot Lear" Cc: X-OriginalArrivalTime: 25 Mar 2003 21:45:26.0961 (UTC) FILETIME=[D8F64210:01C2F317] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PM4BO19143 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 16:45:26 -0500 Content-Transfer-Encoding: 8bit Eliot Lear wrote: > To start with, small networks should be well served by > mechanisms such > as prefix delegation. That delegation occurs in two ways: either > automatic such as the way Droms, et. al have gone, and manual through > the provisioning process (ie., use these addresses as opposed to > others). This is done today in the real world. Indeed this is done, is many times easy enough to do, and is certainly easily transferrable to IPv6! > Tim Price wrote: > > > I submit that as a > > standards body you must address your entire intended > audience, which means > > that the least-common-denominator approach should be considered. > > No, this is not how one engineers. One engineers for the > largest set of > general use cases, not the least common denominator. Oh come now. "One engineers" to create as fool-proof and flexible a design as one can achieve. And even then, expect the worst. > This is not a case of backward compatibility. You are changing > protocols. Private network address space was offered due to address > space shortage. That engineering requirement has evaporated. > So should > private address space. No matter how many times this gets repeated, it's not the whole truth. I certainly agree that there are alternative techniques that may be applied when private addressing was used in the past, although I am not yet convinced these other technqiues (e.g. IPv6 autoconfiguration) are *nearly* as easily applicable. Yes, there are always alternative work-arounds when people take away a useful tool. Any engineer understands work-arounds implicitly. I don't see that it helps to name a single application of private addressing from the past, out of many applications, and claim that having dispensed with that single application there's no need to continue. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 17:01:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05875 for ; Tue, 25 Mar 2003 17:01:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PMLjb20883 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 17:21:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PM92O20194; Tue, 25 Mar 2003 17:09:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PM4BO19142 for ; Tue, 25 Mar 2003 17:04:11 -0500 Received: from stl-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05171 for ; Tue, 25 Mar 2003 16:43:11 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA24916; Tue, 25 Mar 2003 15:45:30 -0600 (CST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id PAA14665; Tue, 25 Mar 2003 15:45:29 -0600 (CST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2PLjRl26584; Tue, 25 Mar 2003 13:45:28 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Mar 2003 16:45:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLzFIpw6U7xVUogQcy3yL0ul/UPQwAAEGww From: "Manfredi, Albert E" To: "Eliot Lear" Cc: X-OriginalArrivalTime: 25 Mar 2003 21:45:26.0961 (UTC) FILETIME=[D8F64210:01C2F317] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PM4BO19143 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 16:45:26 -0500 Content-Transfer-Encoding: 8bit Eliot Lear wrote: > To start with, small networks should be well served by > mechanisms such > as prefix delegation. That delegation occurs in two ways: either > automatic such as the way Droms, et. al have gone, and manual through > the provisioning process (ie., use these addresses as opposed to > others). This is done today in the real world. Indeed this is done, is many times easy enough to do, and is certainly easily transferrable to IPv6! > Tim Price wrote: > > > I submit that as a > > standards body you must address your entire intended > audience, which means > > that the least-common-denominator approach should be considered. > > No, this is not how one engineers. One engineers for the > largest set of > general use cases, not the least common denominator. Oh come now. "One engineers" to create as fool-proof and flexible a design as one can achieve. And even then, expect the worst. > This is not a case of backward compatibility. You are changing > protocols. Private network address space was offered due to address > space shortage. That engineering requirement has evaporated. > So should > private address space. No matter how many times this gets repeated, it's not the whole truth. I certainly agree that there are alternative techniques that may be applied when private addressing was used in the past, although I am not yet convinced these other technqiues (e.g. IPv6 autoconfiguration) are *nearly* as easily applicable. Yes, there are always alternative work-arounds when people take away a useful tool. Any engineer understands work-arounds implicitly. I don't see that it helps to name a single application of private addressing from the past, out of many applications, and claim that having dispensed with that single application there's no need to continue. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 17:06:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06210 for ; Tue, 25 Mar 2003 17:06:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMF7O20496; Tue, 25 Mar 2003 17:15:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMCgO20385 for ; Tue, 25 Mar 2003 17:12:42 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05552 for ; Tue, 25 Mar 2003 16:51:42 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2PLs2L09631 for ; Tue, 25 Mar 2003 15:54:02 -0600 Message-ID: <01fa01c2f319$0c706660$93b58742@ssprunk> From: "Stephen Sprunk" To: Subject: RE: IPv6 site-locals... end of story... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 15:53:53 -0600 Content-Transfer-Encoding: 7bit Thus spake David Conrad > >The ONLY reason to use NAT was the lack of enough addresses. > > No. Another reason is that companies do not want to be held hostage > due to the cost of renumbering which many would feel would be the > case should they want to change providers. This is a point many people seem to be missing. Renumbering a few subnets filled with clients is trivial with IPv6 -- just like it is with IPv4 DHCP. However, renumbering servers and the resultant DNS issues is not trivial, requiring months of planning if you can get management approval at all. Worse, renumbering is manpower-intensive when you consider there are networks out there with 10,000+ sites/subnets, and some being built with the goal of 50,000+ sites/subnets. Without 10/8, these networks wouldn't be administratively possible. Renumbering is not easy. Repeating it over and over doesn't make it so. 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 17:06:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06244 for ; Tue, 25 Mar 2003 17:06:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PMRHn21159 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 17:27:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMF7O20496; Tue, 25 Mar 2003 17:15:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMCgO20385 for ; Tue, 25 Mar 2003 17:12:42 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05552 for ; Tue, 25 Mar 2003 16:51:42 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2PLs2L09631 for ; Tue, 25 Mar 2003 15:54:02 -0600 Message-ID: <01fa01c2f319$0c706660$93b58742@ssprunk> From: "Stephen Sprunk" To: Subject: RE: IPv6 site-locals... end of story... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 15:53:53 -0600 Content-Transfer-Encoding: 7bit Thus spake David Conrad > >The ONLY reason to use NAT was the lack of enough addresses. > > No. Another reason is that companies do not want to be held hostage > due to the cost of renumbering which many would feel would be the > case should they want to change providers. This is a point many people seem to be missing. Renumbering a few subnets filled with clients is trivial with IPv6 -- just like it is with IPv4 DHCP. However, renumbering servers and the resultant DNS issues is not trivial, requiring months of planning if you can get management approval at all. Worse, renumbering is manpower-intensive when you consider there are networks out there with 10,000+ sites/subnets, and some being built with the goal of 50,000+ sites/subnets. Without 10/8, these networks wouldn't be administratively possible. Renumbering is not easy. Repeating it over and over doesn't make it so. 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 17:17:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06803 for ; Tue, 25 Mar 2003 17:17:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMRNO21179; Tue, 25 Mar 2003 17:27:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMOBO21013 for ; Tue, 25 Mar 2003 17:24:11 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06117 for ; Tue, 25 Mar 2003 17:03:11 -0500 (EST) Received: from cisco.com (sjc-vpn3-131.cisco.com [10.21.64.131]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA25704; Tue, 25 Mar 2003 14:05:20 -0800 (PST) Message-ID: <3E80D29C.2060908@cisco.com> From: Eliot Lear 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: Stephen Sprunk CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <01fa01c2f319$0c706660$93b58742@ssprunk> In-Reply-To: <01fa01c2f319$0c706660$93b58742@ssprunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 14:05:16 -0800 Content-Transfer-Encoding: 7bit How many networks exist that have 10,000 sites/subnets? The people who support such networks ARE service providers... Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 17:18:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06826 for ; Tue, 25 Mar 2003 17:18:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PMcnu22531 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 17:38:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMRNO21179; Tue, 25 Mar 2003 17:27:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMOBO21013 for ; Tue, 25 Mar 2003 17:24:11 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06117 for ; Tue, 25 Mar 2003 17:03:11 -0500 (EST) Received: from cisco.com (sjc-vpn3-131.cisco.com [10.21.64.131]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA25704; Tue, 25 Mar 2003 14:05:20 -0800 (PST) Message-ID: <3E80D29C.2060908@cisco.com> From: Eliot Lear 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: Stephen Sprunk CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <01fa01c2f319$0c706660$93b58742@ssprunk> In-Reply-To: <01fa01c2f319$0c706660$93b58742@ssprunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 14:05:16 -0800 Content-Transfer-Encoding: 7bit How many networks exist that have 10,000 sites/subnets? The people who support such networks ARE service providers... Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 17:48:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08072 for ; Tue, 25 Mar 2003 17:48:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PN28O23802; Tue, 25 Mar 2003 18:02:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMlLO23062 for ; Tue, 25 Mar 2003 17:47:21 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07112 for ; Tue, 25 Mar 2003 17:26:21 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2PMScL10174; Tue, 25 Mar 2003 16:28:38 -0600 Message-ID: <023801c2f31d$e1f64710$93b58742@ssprunk> From: "Stephen Sprunk" To: "Eliot Lear" Cc: References: <01fa01c2f319$0c706660$93b58742@ssprunk> <3E80D29C.2060908@cisco.com> Subject: Re: IPv6 site-locals... end of story... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 16:27:45 -0600 Content-Transfer-Encoding: 7bit Thus spake "Eliot Lear" > > How many networks exist that have 10,000 sites/subnets? The > people who support such networks ARE service providers... I can't give names, but let's think about this. There are about 15,000 McDonalds restaurants in the US alone; many retail stores have similar numbers. Bank ATMs typically have a router and local subnet inside them, and there's tens of thousands of those things around too. I don't have exact numbers, but I'd guess the major oil companies have 20,000 gas station each. And let's not forget the US Postal Service with tens of thousands of post offices. While it may be tempting to give these folks their own portable space, they only have a couple dozen machines exposed to the outside world so that's a horrific waste -- not to mention unfair to all the other folks who are stuck with provider addresses and renumbering every year or two. Private addresses solve many different real-world problems, not just a general shortage of addresses. I'm not fond of site-local addresses per se, but we do need a private address block. 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 17:48:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08100 for ; Tue, 25 Mar 2003 17:48:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PN9F524959 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 18:09:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PN28O23802; Tue, 25 Mar 2003 18:02:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMlLO23062 for ; Tue, 25 Mar 2003 17:47:21 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07112 for ; Tue, 25 Mar 2003 17:26:21 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2PMScL10174; Tue, 25 Mar 2003 16:28:38 -0600 Message-ID: <023801c2f31d$e1f64710$93b58742@ssprunk> From: "Stephen Sprunk" To: "Eliot Lear" Cc: References: <01fa01c2f319$0c706660$93b58742@ssprunk> <3E80D29C.2060908@cisco.com> Subject: Re: IPv6 site-locals... end of story... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 16:27:45 -0600 Content-Transfer-Encoding: 7bit Thus spake "Eliot Lear" > > How many networks exist that have 10,000 sites/subnets? The > people who support such networks ARE service providers... I can't give names, but let's think about this. There are about 15,000 McDonalds restaurants in the US alone; many retail stores have similar numbers. Bank ATMs typically have a router and local subnet inside them, and there's tens of thousands of those things around too. I don't have exact numbers, but I'd guess the major oil companies have 20,000 gas station each. And let's not forget the US Postal Service with tens of thousands of post offices. While it may be tempting to give these folks their own portable space, they only have a couple dozen machines exposed to the outside world so that's a horrific waste -- not to mention unfair to all the other folks who are stuck with provider addresses and renumbering every year or two. Private addresses solve many different real-world problems, not just a general shortage of addresses. I'm not fond of site-local addresses per se, but we do need a private address block. 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 18:01:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08645 for ; Tue, 25 Mar 2003 18:01:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PN9uO24984; Tue, 25 Mar 2003 18:09:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMuWO23434 for ; Tue, 25 Mar 2003 17:56:32 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07308 for ; Tue, 25 Mar 2003 17:35:31 -0500 (EST) Received: from cisco.com (sjc-vpn3-284.cisco.com [10.21.65.28]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA03773; Tue, 25 Mar 2003 14:37:45 -0800 (PST) Message-ID: <3E80DA39.1020904@cisco.com> From: Eliot Lear 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: Stephen Sprunk CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <01fa01c2f319$0c706660$93b58742@ssprunk> <3E80D29C.2060908@cisco.com> <023801c2f31d$e1f64710$93b58742@ssprunk> In-Reply-To: <023801c2f31d$e1f64710$93b58742@ssprunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 14:37:45 -0800 Content-Transfer-Encoding: 7bit Stephen Sprunk wrote: > Thus spake "Eliot Lear" > >>How many networks exist that have 10,000 sites/subnets? The >>people who support such networks ARE service providers... > > > I can't give names, but let's think about this. There are about 15,000 > McDonalds restaurants in the US alone; many retail stores have similar > numbers. Bank ATMs typically have a router and local subnet inside them, > and there's tens of thousands of those things around too. I don't have > exact numbers, but I'd guess the major oil companies have 20,000 gas station > each. And let's not forget the US Postal Service with tens of thousands of > post offices. These are the cases where autoconfig/ppp should do the job. If it can't then IPv6 just isn't ready. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 18:01:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08684 for ; Tue, 25 Mar 2003 18:01:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PNMFv25536 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 18:22:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PN9uO24984; Tue, 25 Mar 2003 18:09:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMuWO23434 for ; Tue, 25 Mar 2003 17:56:32 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07308 for ; Tue, 25 Mar 2003 17:35:31 -0500 (EST) Received: from cisco.com (sjc-vpn3-284.cisco.com [10.21.65.28]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA03773; Tue, 25 Mar 2003 14:37:45 -0800 (PST) Message-ID: <3E80DA39.1020904@cisco.com> From: Eliot Lear 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: Stephen Sprunk CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <01fa01c2f319$0c706660$93b58742@ssprunk> <3E80D29C.2060908@cisco.com> <023801c2f31d$e1f64710$93b58742@ssprunk> In-Reply-To: <023801c2f31d$e1f64710$93b58742@ssprunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Mar 2003 14:37:45 -0800 Content-Transfer-Encoding: 7bit Stephen Sprunk wrote: > Thus spake "Eliot Lear" > >>How many networks exist that have 10,000 sites/subnets? The >>people who support such networks ARE service providers... > > > I can't give names, but let's think about this. There are about 15,000 > McDonalds restaurants in the US alone; many retail stores have similar > numbers. Bank ATMs typically have a router and local subnet inside them, > and there's tens of thousands of those things around too. I don't have > exact numbers, but I'd guess the major oil companies have 20,000 gas station > each. And let's not forget the US Postal Service with tens of thousands of > post offices. These are the cases where autoconfig/ppp should do the job. If it can't then IPv6 just isn't ready. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Mar 25 21:58:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16149 for ; Tue, 25 Mar 2003 21:58:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q3BuO09073; Tue, 25 Mar 2003 22:11:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q384O08949 for ; Tue, 25 Mar 2003 22:08:04 -0500 Received: from web15103.mail.bjs.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15911 for ; Tue, 25 Mar 2003 21:46:58 -0500 (EST) Message-ID: <20030326024916.12575.qmail@web15103.mail.bjs.yahoo.com> Received: from [218.0.195.236] by web15103.mail.bjs.yahoo.com via HTTP; Wed, 26 Mar 2003 10:49:16 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: IPv6 site-locals... end of story... To: Eliot Lear , "Manfredi, Albert E" Cc: curtis@fictitious.org, Tony Li , routing-discussion@ietf.org In-Reply-To: <3E808ABA.7080303@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1802215516-1048646956=:12020" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:49:16 +0800 (CST) --0-1802215516-1048646956=:12020 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit >I would point out that (a) nobody suggested that addresses be gotten >from IANA, But if you want to avoid address overlaping between private network and public network, it is required to renumber internal computers even if they do not want to set up servers. So, it is asked to apply address from either ISP or IANA. My question is: Why and how could we add such a mandotary requirement? > and (b) globally unique addressses WERE the norm prior to the >addressing shortage that precipitated RFC 1597. IMHO, any standard should consider backward compatiblity. Many organizations have use IPv4 private address in their internal networks. When these networks are upgraded to IPv6, we should define an upgrading mechanism as smooth as possible. If all those private address of 10.0.0.0/8 are mapped to the same IPv6 block, people may be reluctant to do all those changes but resort to NAT. And, could DHCP be applied to a large network with low cost? To telephone application, why should we use software solution but not use IP-phone service provided by telephone companies? regards Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1802215516-1048646956=:12020 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

>I would point out that (a) nobody suggested that addresses be gotten
>from IANA,

But if you want to avoid address overlaping between private network and public network, it is required to renumber internal computers even if  they do not want to set up servers. So,  it is asked to apply address from either ISP or IANA. My question is:  Why and how could we add such a mandotary requirement?

> and (b) globally unique addressses WERE the norm prior to the
>addressing shortage that precipitated RFC 1597.

IMHO, any standard should consider backward compatiblity. Many organizations have use IPv4 private address in their internal networks. When these networks are upgraded to IPv6,  we should define an upgrading mechanism as smooth as possible. If all those private address of 10.0.0.0/8 are mapped to the same IPv6 block, people may be reluctant to do all those changes but resort to NAT. And, could DHCP be applied to a large network with low cost?

To telephone application, why should we use software solution but not use IP-phone service provided by telephone companies?

regards


 



Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1802215516-1048646956=:12020-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Tue Mar 25 21:59:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16168 for ; Tue, 25 Mar 2003 21:59:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q3Jiv09307 for routing-discussion-archive@odin.ietf.org; Tue, 25 Mar 2003 22:19:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q3BuO09073; Tue, 25 Mar 2003 22:11:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q384O08949 for ; Tue, 25 Mar 2003 22:08:04 -0500 Received: from web15103.mail.bjs.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15911 for ; Tue, 25 Mar 2003 21:46:58 -0500 (EST) Message-ID: <20030326024916.12575.qmail@web15103.mail.bjs.yahoo.com> Received: from [218.0.195.236] by web15103.mail.bjs.yahoo.com via HTTP; Wed, 26 Mar 2003 10:49:16 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: IPv6 site-locals... end of story... To: Eliot Lear , "Manfredi, Albert E" Cc: curtis@fictitious.org, Tony Li , routing-discussion@ietf.org In-Reply-To: <3E808ABA.7080303@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1802215516-1048646956=:12020" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:49:16 +0800 (CST) --0-1802215516-1048646956=:12020 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit >I would point out that (a) nobody suggested that addresses be gotten >from IANA, But if you want to avoid address overlaping between private network and public network, it is required to renumber internal computers even if they do not want to set up servers. So, it is asked to apply address from either ISP or IANA. My question is: Why and how could we add such a mandotary requirement? > and (b) globally unique addressses WERE the norm prior to the >addressing shortage that precipitated RFC 1597. IMHO, any standard should consider backward compatiblity. Many organizations have use IPv4 private address in their internal networks. When these networks are upgraded to IPv6, we should define an upgrading mechanism as smooth as possible. If all those private address of 10.0.0.0/8 are mapped to the same IPv6 block, people may be reluctant to do all those changes but resort to NAT. And, could DHCP be applied to a large network with low cost? To telephone application, why should we use software solution but not use IP-phone service provided by telephone companies? regards Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1802215516-1048646956=:12020 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

>I would point out that (a) nobody suggested that addresses be gotten
>from IANA,

But if you want to avoid address overlaping between private network and public network, it is required to renumber internal computers even if  they do not want to set up servers. So,  it is asked to apply address from either ISP or IANA. My question is:  Why and how could we add such a mandotary requirement?

> and (b) globally unique addressses WERE the norm prior to the
>addressing shortage that precipitated RFC 1597.

IMHO, any standard should consider backward compatiblity. Many organizations have use IPv4 private address in their internal networks. When these networks are upgraded to IPv6,  we should define an upgrading mechanism as smooth as possible. If all those private address of 10.0.0.0/8 are mapped to the same IPv6 block, people may be reluctant to do all those changes but resort to NAT. And, could DHCP be applied to a large network with low cost?

To telephone application, why should we use software solution but not use IP-phone service provided by telephone companies?

regards


 



Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1802215516-1048646956=:12020-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 02:04:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25439 for ; Wed, 26 Mar 2003 02:04:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q7ImO00924; Wed, 26 Mar 2003 02:18:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q7F4O00794 for ; Wed, 26 Mar 2003 02:15:04 -0500 Received: from web15103.mail.bjs.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20059 for ; Wed, 26 Mar 2003 01:53:51 -0500 (EST) Message-ID: <20030326065609.22367.qmail@web15103.mail.bjs.yahoo.com> Received: from [218.0.195.236] by web15103.mail.bjs.yahoo.com via HTTP; Wed, 26 Mar 2003 14:56:09 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: IPv6 site-locals... end of story... To: curtis@fictitious.org Cc: Roland Bless , jshen@cad.zju.edu.cn, routing-discussion@ietf.org In-Reply-To: <200303251918.OAA13983@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1030683707-1048661769=:21377" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 14:56:09 +0800 (CST) --0-1030683707-1048661769=:21377 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Hi, >What this (and NAT) doesn't do is allow filtering based control of >internal users. Clever user have put all sorts of services inside >port 80 and even over HTTP. I have another sample: if we hire some service from ISP to connect our internnal network to internet, we use NAT at access point which dynamically share IP address pool to the whole subnet. If someone outside want to crack my computer, he must firstly locate my computer's real address. This means the hacker must crack the NAT router at first. I think this improve the difficulty of cracking. Also, round-robin load balancing between server farm is achived by mapping single real address to several private address, this also improves the service reliablity. thanks. regards Jing Shen Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1030683707-1048661769=:21377 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

Hi,

>What this (and NAT) doesn't do is allow filtering based control of
>internal users. Clever user have put all sorts of services inside
>port 80 and even over HTTP.

I have another sample:  if we hire some service from ISP to connect our internnal network to internet, we use NAT at access point which dynamically share IP address pool to the whole subnet. If someone outside want to crack my computer, he must firstly locate my computer's real address. This means the hacker must crack the NAT router at first. I think this improve the difficulty of cracking. Also, round-robin load balancing between server farm is achived by mapping single real address to several private address, this also improves the service reliablity.

thanks.

regards

Jing Shen



Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1030683707-1048661769=:21377-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 02:05:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26126 for ; Wed, 26 Mar 2003 02:05:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q7QHV01728 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 02:26:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q7ImO00924; Wed, 26 Mar 2003 02:18:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q7F4O00794 for ; Wed, 26 Mar 2003 02:15:04 -0500 Received: from web15103.mail.bjs.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20059 for ; Wed, 26 Mar 2003 01:53:51 -0500 (EST) Message-ID: <20030326065609.22367.qmail@web15103.mail.bjs.yahoo.com> Received: from [218.0.195.236] by web15103.mail.bjs.yahoo.com via HTTP; Wed, 26 Mar 2003 14:56:09 CST From: =?gb2312?q?Jing=20Shen?= Subject: Re: IPv6 site-locals... end of story... To: curtis@fictitious.org Cc: Roland Bless , jshen@cad.zju.edu.cn, routing-discussion@ietf.org In-Reply-To: <200303251918.OAA13983@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1030683707-1048661769=:21377" Content-Transfer-Encoding: 8bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 14:56:09 +0800 (CST) --0-1030683707-1048661769=:21377 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Hi, >What this (and NAT) doesn't do is allow filtering based control of >internal users. Clever user have put all sorts of services inside >port 80 and even over HTTP. I have another sample: if we hire some service from ISP to connect our internnal network to internet, we use NAT at access point which dynamically share IP address pool to the whole subnet. If someone outside want to crack my computer, he must firstly locate my computer's real address. This means the hacker must crack the NAT router at first. I think this improve the difficulty of cracking. Also, round-robin load balancing between server farm is achived by mapping single real address to several private address, this also improves the service reliablity. thanks. regards Jing Shen Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1030683707-1048661769=:21377 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

Hi,

>What this (and NAT) doesn't do is allow filtering based control of
>internal users. Clever user have put all sorts of services inside
>port 80 and even over HTTP.

I have another sample:  if we hire some service from ISP to connect our internnal network to internet, we use NAT at access point which dynamically share IP address pool to the whole subnet. If someone outside want to crack my computer, he must firstly locate my computer's real address. This means the hacker must crack the NAT router at first. I think this improve the difficulty of cracking. Also, round-robin load balancing between server farm is achived by mapping single real address to several private address, this also improves the service reliablity.

thanks.

regards

Jing Shen



Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1030683707-1048661769=:21377-- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 11:09:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02177 for ; Wed, 26 Mar 2003 11:09:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGInO08675; Wed, 26 Mar 2003 11:18:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGFCO08509 for ; Wed, 26 Mar 2003 11:15:12 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01584 for ; Wed, 26 Mar 2003 10:53:51 -0500 (EST) Message-ID: From: Jeff Parker To: "'David Conrad'" , Roland Bless Cc: Jing Shen , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Subject: RE: IPv6 site-locals... end of story... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:55:53 -0500 > When there are hundreds of sites out there > running unpatched old versions of BIND or IIS > ...why waste your time breaking through a NAT box? Because the target is atractive? - jeff parker _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 11:10:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02203 for ; Wed, 26 Mar 2003 11:10:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QGVLV09408 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 11:31:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGInO08675; Wed, 26 Mar 2003 11:18:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGFCO08509 for ; Wed, 26 Mar 2003 11:15:12 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01584 for ; Wed, 26 Mar 2003 10:53:51 -0500 (EST) Message-ID: From: Jeff Parker To: "'David Conrad'" , Roland Bless Cc: Jing Shen , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Subject: RE: IPv6 site-locals... end of story... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:55:53 -0500 > When there are hundreds of sites out there > running unpatched old versions of BIND or IIS > ...why waste your time breaking through a NAT box? Because the target is atractive? - jeff parker _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 13:12:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05893 for ; Wed, 26 Mar 2003 13:12:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIRWO19474; Wed, 26 Mar 2003 13:27:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIMjO19305 for ; Wed, 26 Mar 2003 13:22:45 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05673 for ; Wed, 26 Mar 2003 13:01:20 -0500 (EST) Received: from cisco.com (sjc-vpn3-615.cisco.com [10.21.66.103]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA21138; Wed, 26 Mar 2003 10:02:57 -0800 (PST) Message-ID: <3E81EB52.5000302@cisco.com> From: Eliot Lear 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: Jing Shen CC: curtis@fictitious.org, Roland Bless , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <20030326065609.22367.qmail@web15103.mail.bjs.yahoo.com> In-Reply-To: <20030326065609.22367.qmail@web15103.mail.bjs.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:02:58 -0800 Content-Transfer-Encoding: 7bit As has been said, if you're relying on NAT for security you are getting very weak security, especially if your ISP is compromised. They may well be able to route right through the NAT, depending on your network configuration. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 13:13:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05924 for ; Wed, 26 Mar 2003 13:13:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QIYMA19650 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 13:34:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIRWO19474; Wed, 26 Mar 2003 13:27:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIMjO19305 for ; Wed, 26 Mar 2003 13:22:45 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05673 for ; Wed, 26 Mar 2003 13:01:20 -0500 (EST) Received: from cisco.com (sjc-vpn3-615.cisco.com [10.21.66.103]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA21138; Wed, 26 Mar 2003 10:02:57 -0800 (PST) Message-ID: <3E81EB52.5000302@cisco.com> From: Eliot Lear 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: Jing Shen CC: curtis@fictitious.org, Roland Bless , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: <20030326065609.22367.qmail@web15103.mail.bjs.yahoo.com> In-Reply-To: <20030326065609.22367.qmail@web15103.mail.bjs.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:02:58 -0800 Content-Transfer-Encoding: 7bit As has been said, if you're relying on NAT for security you are getting very weak security, especially if your ISP is compromised. They may well be able to route right through the NAT, depending on your network configuration. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 13:25:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06189 for ; Wed, 26 Mar 2003 13:25:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIdtO20598; Wed, 26 Mar 2003 13:39:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIa0O19708 for ; Wed, 26 Mar 2003 13:36:00 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05949 for ; Wed, 26 Mar 2003 13:14:35 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 79D6634450; Wed, 26 Mar 2003 09:30:09 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2QIGoYB001910; Wed, 26 Mar 2003 10:16:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLzs+S5fHL75XruQ2iOwKjobY5UxAAD0Gpg From: "Tony Li" To: "Jeff Parker" , "David Conrad" , "Roland Bless" Cc: "Jing Shen" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QIa0O19709 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:16:49 -0800 Content-Transfer-Encoding: 8bit Folks, One of the points that is being entirely missed in this discussion is the distinction between NATs and firewalls. Yes, many NAT boxes also perform firewalling and we're not at all out to architecturally deprecate firewalls (at least here and now). The question is soley about NAT functionality. As other posters have said, either IPv6 renumbering works well and you don't need NAT because you can run your entire network on PA addresses comfortably, or IPv6 renumbering (and therefore all of IPv6) isn't ready for prime time. While an Internet architecture should certainly not preclude the many things that folks will want to do, it should also not endorse the functions that we find to be counter-productive to the overall life of the Internet. In that spirit, if we have done our jobs correctly with IPv6, NAT should not be required. It serves no purpose that a correctly architected and implemented IPv6 doesn't do. Endorsing NAT is an admission that IPv6 has failed. Tony | > When there are hundreds of sites out there | > running unpatched old versions of BIND or IIS | > ...why waste your time breaking through a NAT box? | | Because the target is atractive? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 13:25:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06209 for ; Wed, 26 Mar 2003 13:25:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QIkYu20937 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 13:46:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIdtO20598; Wed, 26 Mar 2003 13:39:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIa0O19708 for ; Wed, 26 Mar 2003 13:36:00 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05949 for ; Wed, 26 Mar 2003 13:14:35 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 79D6634450; Wed, 26 Mar 2003 09:30:09 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2QIGoYB001910; Wed, 26 Mar 2003 10:16:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 site-locals... end of story... Message-ID: Thread-Topic: IPv6 site-locals... end of story... Thread-Index: AcLzs+S5fHL75XruQ2iOwKjobY5UxAAD0Gpg From: "Tony Li" To: "Jeff Parker" , "David Conrad" , "Roland Bless" Cc: "Jing Shen" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QIa0O19709 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:16:49 -0800 Content-Transfer-Encoding: 8bit Folks, One of the points that is being entirely missed in this discussion is the distinction between NATs and firewalls. Yes, many NAT boxes also perform firewalling and we're not at all out to architecturally deprecate firewalls (at least here and now). The question is soley about NAT functionality. As other posters have said, either IPv6 renumbering works well and you don't need NAT because you can run your entire network on PA addresses comfortably, or IPv6 renumbering (and therefore all of IPv6) isn't ready for prime time. While an Internet architecture should certainly not preclude the many things that folks will want to do, it should also not endorse the functions that we find to be counter-productive to the overall life of the Internet. In that spirit, if we have done our jobs correctly with IPv6, NAT should not be required. It serves no purpose that a correctly architected and implemented IPv6 doesn't do. Endorsing NAT is an admission that IPv6 has failed. Tony | > When there are hundreds of sites out there | > running unpatched old versions of BIND or IIS | > ...why waste your time breaking through a NAT box? | | Because the target is atractive? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 13:51:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07109 for ; Wed, 26 Mar 2003 13:51:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJ5ZO22061; Wed, 26 Mar 2003 14:05:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJ0vO21815 for ; Wed, 26 Mar 2003 14:00:57 -0500 Received: from smtp.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06676 for ; Wed, 26 Mar 2003 13:39:31 -0500 (EST) Received: from jersey.sghosh.org (bgp510508bgs.verona01.nj.comcast.net [68.38.20.121]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HCD00DJZD4GGI@mtaout11.icomcast.net> for routing-discussion@ietf.org; Wed, 26 Mar 2003 13:38:40 -0500 (EST) Received: from calcutta.sghosh.org (calcutta.sghosh.org [192.168.0.5]) by jersey.sghosh.org (8.11.6/8.11.6) with ESMTP id h2QIceH09346 for ; Wed, 26 Mar 2003 13:38:40 -0500 Received: from localhost (sghosh@localhost) by calcutta.sghosh.org (8.11.6/8.11.6) with ESMTP id h2QIcdt23087 for ; Wed, 26 Mar 2003 13:38:39 -0500 From: Subhendu Ghosh Subject: RE: IPv6 site-locals... end of story... In-reply-to: To: routing-discussion@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Authentication-warning: calcutta.sghosh.org: sghosh owned process doing -bs Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 13:38:39 -0500 (EST) Content-Transfer-Encoding: 7BIT On Wed, 26 Mar 2003, Tony Li wrote: > While an Internet architecture should certainly not preclude > the many things that folks will want to do, it should also not > endorse the functions that we find to be counter-productive to > the overall life of the Internet. In that spirit, if we have > done our jobs correctly with IPv6, NAT should not be required. > It serves no purpose that a correctly architected and implemented > IPv6 doesn't do. Endorsing NAT is an admission that IPv6 has > failed. > There is a difference between architecture and cost. While NAT may not be needed in the architecture, it may be forced by pricing and address allocation policies a couple of levels downstream from the RIRs. Thus while endorsement of NAT is not needed - explictly disallowing NAT has a huge cost for a lot of small shops. Without regard to NAT, the concept of an address block available for private use similar 1918 is a useful one. site-locals are not the only way to get private address and are probably much more of a pain to debug and manage. -- -subhendu _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 13:52:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07149 for ; Wed, 26 Mar 2003 13:52:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJD0R23334 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 14:13:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJ5ZO22061; Wed, 26 Mar 2003 14:05:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJ0vO21815 for ; Wed, 26 Mar 2003 14:00:57 -0500 Received: from smtp.comcast.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06676 for ; Wed, 26 Mar 2003 13:39:31 -0500 (EST) Received: from jersey.sghosh.org (bgp510508bgs.verona01.nj.comcast.net [68.38.20.121]) by mtaout11.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HCD00DJZD4GGI@mtaout11.icomcast.net> for routing-discussion@ietf.org; Wed, 26 Mar 2003 13:38:40 -0500 (EST) Received: from calcutta.sghosh.org (calcutta.sghosh.org [192.168.0.5]) by jersey.sghosh.org (8.11.6/8.11.6) with ESMTP id h2QIceH09346 for ; Wed, 26 Mar 2003 13:38:40 -0500 Received: from localhost (sghosh@localhost) by calcutta.sghosh.org (8.11.6/8.11.6) with ESMTP id h2QIcdt23087 for ; Wed, 26 Mar 2003 13:38:39 -0500 From: Subhendu Ghosh Subject: RE: IPv6 site-locals... end of story... In-reply-to: To: routing-discussion@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Authentication-warning: calcutta.sghosh.org: sghosh owned process doing -bs Content-Transfer-Encoding: 7BIT Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 13:38:39 -0500 (EST) Content-Transfer-Encoding: 7BIT On Wed, 26 Mar 2003, Tony Li wrote: > While an Internet architecture should certainly not preclude > the many things that folks will want to do, it should also not > endorse the functions that we find to be counter-productive to > the overall life of the Internet. In that spirit, if we have > done our jobs correctly with IPv6, NAT should not be required. > It serves no purpose that a correctly architected and implemented > IPv6 doesn't do. Endorsing NAT is an admission that IPv6 has > failed. > There is a difference between architecture and cost. While NAT may not be needed in the architecture, it may be forced by pricing and address allocation policies a couple of levels downstream from the RIRs. Thus while endorsement of NAT is not needed - explictly disallowing NAT has a huge cost for a lot of small shops. Without regard to NAT, the concept of an address block available for private use similar 1918 is a useful one. site-locals are not the only way to get private address and are probably much more of a pain to debug and manage. -- -subhendu _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 14:20:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08262 for ; Wed, 26 Mar 2003 14:20:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJTEO24239; Wed, 26 Mar 2003 14:29:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJPWO24110 for ; Wed, 26 Mar 2003 14:25:32 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07652 for ; Wed, 26 Mar 2003 14:04:05 -0500 (EST) Received: from cisco.com (sjc-vpn3-615.cisco.com [10.21.66.103]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA06012; Wed, 26 Mar 2003 11:06:20 -0800 (PST) Message-ID: <3E81FA2B.3090002@cisco.com> From: Eliot Lear 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: Subhendu Ghosh CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 11:06:19 -0800 Content-Transfer-Encoding: 7bit Subhendu Ghosh wrote: > Thus while endorsement of NAT is not needed - explictly disallowing NAT > has a huge cost for a lot of small shops. The presence or absense of assigned site-local address space will not allow or disallow NATs. You can just as easily pull a random unassigned value out of a hat. And I think this also harkens back to RFC-1627. Some practices should NOT be codified. Doesn't mean you can't do them. It just means they're a bad idea. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 14:21:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08303 for ; Wed, 26 Mar 2003 14:21:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJgN725756 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 14:42:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJTEO24239; Wed, 26 Mar 2003 14:29:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJPWO24110 for ; Wed, 26 Mar 2003 14:25:32 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07652 for ; Wed, 26 Mar 2003 14:04:05 -0500 (EST) Received: from cisco.com (sjc-vpn3-615.cisco.com [10.21.66.103]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA06012; Wed, 26 Mar 2003 11:06:20 -0800 (PST) Message-ID: <3E81FA2B.3090002@cisco.com> From: Eliot Lear 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: Subhendu Ghosh CC: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 11:06:19 -0800 Content-Transfer-Encoding: 7bit Subhendu Ghosh wrote: > Thus while endorsement of NAT is not needed - explictly disallowing NAT > has a huge cost for a lot of small shops. The presence or absense of assigned site-local address space will not allow or disallow NATs. You can just as easily pull a random unassigned value out of a hat. And I think this also harkens back to RFC-1627. Some practices should NOT be codified. Doesn't mean you can't do them. It just means they're a bad idea. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 14:27:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08552 for ; Wed, 26 Mar 2003 14:27:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJarO24600; Wed, 26 Mar 2003 14:36:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJXuO24456 for ; Wed, 26 Mar 2003 14:33:56 -0500 Received: from merlot.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07943 for ; Wed, 26 Mar 2003 14:12:29 -0500 (EST) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2QJEoS13341 for ; Wed, 26 Mar 2003 11:14:50 -0800 (PST) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id h2QJEob61816 for routing-discussion@ietf.org; Wed, 26 Mar 2003 11:14:50 -0800 (PST) (envelope-from kireeti) From: Kireeti Kompella Message-Id: <200303261914.h2QJEob61816@kummer.juniper.net> To: routing-discussion@ietf.org Subject: IPv6 site-locals... the story goes on ... and on ... and on ... In-Reply-To: <3E81FA2B.3090002@cisco.com> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 11:14:50 -0800 (PST) Thoroughly engrossing discussion. But please change the subject line. Kireeti. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 14:27:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08569 for ; Wed, 26 Mar 2003 14:27:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJmWt26052 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 14:48:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJarO24600; Wed, 26 Mar 2003 14:36:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJXuO24456 for ; Wed, 26 Mar 2003 14:33:56 -0500 Received: from merlot.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07943 for ; Wed, 26 Mar 2003 14:12:29 -0500 (EST) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2QJEoS13341 for ; Wed, 26 Mar 2003 11:14:50 -0800 (PST) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id h2QJEob61816 for routing-discussion@ietf.org; Wed, 26 Mar 2003 11:14:50 -0800 (PST) (envelope-from kireeti) From: Kireeti Kompella Message-Id: <200303261914.h2QJEob61816@kummer.juniper.net> To: routing-discussion@ietf.org Subject: IPv6 site-locals... the story goes on ... and on ... and on ... In-Reply-To: <3E81FA2B.3090002@cisco.com> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 11:14:50 -0800 (PST) Thoroughly engrossing discussion. But please change the subject line. Kireeti. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 15:58:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14242 for ; Wed, 26 Mar 2003 15:58:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLCZO01111; Wed, 26 Mar 2003 16:12:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QL4BO32466 for ; Wed, 26 Mar 2003 16:04:11 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13540 for ; Wed, 26 Mar 2003 15:42:43 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA31575; Wed, 26 Mar 2003 15:45:39 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303262045.PAA31575@workhorse.fictitious.org> To: "Stephen Sprunk" cc: "Eliot Lear" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: You want Fries with that? (was Re: IPv6 site-locals... end of story) In-reply-to: Your message of "Tue, 25 Mar 2003 16:27:45 CST." <023801c2f31d$e1f64710$93b58742@ssprunk> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 15:45:39 -0500 In message <023801c2f31d$e1f64710$93b58742@ssprunk>, "Stephen Sprunk" writes: > Thus spake "Eliot Lear" > > > > How many networks exist that have 10,000 sites/subnets? The > > people who support such networks ARE service providers... > > I can't give names, but let's think about this. There are about 15,000 > McDonalds restaurants in the US alone; many retail stores have similar > numbers. Bank ATMs typically have a router and local subnet inside them, > and there's tens of thousands of those things around too. I don't have > exact numbers, but I'd guess the major oil companies have 20,000 gas station > each. And let's not forget the US Postal Service with tens of thousands of > post offices. And fedex and UPS have routeable IPv4 addresses for similar purposes. Works fine for them so Mickey D's and the the banks should be fine too. Its about time the banks figured out how to implement real security within their infrastructures (but with personal identification still stuck in the stone ages with PIN numbers and US SS numbers and mother's maiden name, that would be asking a lot). > While it may be tempting to give these folks their own portable space, > they only have a couple dozen machines exposed to the outside world so > that's a horrific waste -- not to mention unfair to all the other folks who > are stuck with provider addresses and renumbering every year or two. Renumbering is supposed to be easy with IPv6. I always found it plenty easy enough with IPv4, so I won't comment on whether it is easy enough with IPv6. > Private addresses solve many different real-world problems, not just a > general shortage of addresses. I'm not fond of site-local addresses per se, > but we do need a private address block. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein Curtis ps - You happy Kireeti? - I changed the subject line. (Are we ever off topic!) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 15:59:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14305 for ; Wed, 26 Mar 2003 15:59:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QLJxj01896 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 16:19:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLCZO01111; Wed, 26 Mar 2003 16:12:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QL4BO32466 for ; Wed, 26 Mar 2003 16:04:11 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13540 for ; Wed, 26 Mar 2003 15:42:43 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA31575; Wed, 26 Mar 2003 15:45:39 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303262045.PAA31575@workhorse.fictitious.org> To: "Stephen Sprunk" cc: "Eliot Lear" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: You want Fries with that? (was Re: IPv6 site-locals... end of story) In-reply-to: Your message of "Tue, 25 Mar 2003 16:27:45 CST." <023801c2f31d$e1f64710$93b58742@ssprunk> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 15:45:39 -0500 In message <023801c2f31d$e1f64710$93b58742@ssprunk>, "Stephen Sprunk" writes: > Thus spake "Eliot Lear" > > > > How many networks exist that have 10,000 sites/subnets? The > > people who support such networks ARE service providers... > > I can't give names, but let's think about this. There are about 15,000 > McDonalds restaurants in the US alone; many retail stores have similar > numbers. Bank ATMs typically have a router and local subnet inside them, > and there's tens of thousands of those things around too. I don't have > exact numbers, but I'd guess the major oil companies have 20,000 gas station > each. And let's not forget the US Postal Service with tens of thousands of > post offices. And fedex and UPS have routeable IPv4 addresses for similar purposes. Works fine for them so Mickey D's and the the banks should be fine too. Its about time the banks figured out how to implement real security within their infrastructures (but with personal identification still stuck in the stone ages with PIN numbers and US SS numbers and mother's maiden name, that would be asking a lot). > While it may be tempting to give these folks their own portable space, > they only have a couple dozen machines exposed to the outside world so > that's a horrific waste -- not to mention unfair to all the other folks who > are stuck with provider addresses and renumbering every year or two. Renumbering is supposed to be easy with IPv6. I always found it plenty easy enough with IPv4, so I won't comment on whether it is easy enough with IPv6. > Private addresses solve many different real-world problems, not just a > general shortage of addresses. I'm not fond of site-local addresses per se, > but we do need a private address block. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein Curtis ps - You happy Kireeti? - I changed the subject line. (Are we ever off topic!) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 16:18:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15214 for ; Wed, 26 Mar 2003 16:18:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLYEO03034; Wed, 26 Mar 2003 16:34:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLVoO02922 for ; Wed, 26 Mar 2003 16:31:50 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14924 for ; Wed, 26 Mar 2003 16:10:22 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA32035; Wed, 26 Mar 2003 16:13:22 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303262113.QAA32035@workhorse.fictitious.org> To: "Stephen Sprunk" cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: whining about renumbering (was: Re: IPv6 site-locals... end of story) In-reply-to: Your message of "Tue, 25 Mar 2003 15:53:53 CST." <01fa01c2f319$0c706660$93b58742@ssprunk> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 16:13:22 -0500 In message <01fa01c2f319$0c706660$93b58742@ssprunk>, "Stephen Sprunk" writes: > Thus spake David Conrad > > >The ONLY reason to use NAT was the lack of enough addresses. > > > > No. Another reason is that companies do not want to be held hostage > > due to the cost of renumbering which many would feel would be the > > case should they want to change providers. > > This is a point many people seem to be missing. Renumbering a few subnets > filled with clients is trivial with IPv6 -- just like it is with IPv4 DHCP. > However, renumbering servers and the resultant DNS issues is not trivial, > requiring months of planning if you can get management approval at all. Only if you are incompetent or don't have access to the client. Create two addresses for the servers and everything else. Take as much time as you need to do this. Then change DNS. Wait a few days (weeks) until you are sure that DNS everywhere is flushed out and no adverse reactions have ocurred. Then remove the old addresses. Take as much time as you need to do this too. Services are given CNAMEs and servers are given A records. For hardware upgrade services were moved to different servers. We got good enough at this that we could cut certain services over to new servers mid-day and no one could tell the difference. > Worse, renumbering is manpower-intensive when you consider there are > networks out there with 10,000+ sites/subnets, and some being built with the > goal of 50,000+ sites/subnets. Without 10/8, these networks wouldn't be > administratively possible. Remote administration and shell scripts / perl programs is the only way to go administering large networks. > Renumbering is not easy. Repeating it over and over doesn't make it so. > > 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 I've done it admitedly for only a few hundred subnets if that many, but it went fine and was not all that manpower intensive. This was without DHCP. We didn't have to walk up to pee-cees and click in the dialog boxes or it would have been impossible. As an ISP we routinely drilled taking the Michagan NOC down and switching over to the NY NOC, including changing servers for multiple database services. All generally worked fine and cutover in 15 minutes would have been easy if the telco didn't consistently mess up the transition of the incoming NOC phone lines. :-) DHCP or autoconfig can actually make the problem harder if learning two addresses for the same interface is not supported by all clients and servers. Two addresses are needed during the transition. Absent the ability to have two addresses on the clients, a few subnets at a time have to be cut over with routing between subnets in the old and the new address space. Still not overly difficult but a little better planning is required. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 16:19:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15251 for ; Wed, 26 Mar 2003 16:19:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QLeCb04051 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 16:40:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLYEO03034; Wed, 26 Mar 2003 16:34:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLVoO02922 for ; Wed, 26 Mar 2003 16:31:50 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14924 for ; Wed, 26 Mar 2003 16:10:22 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA32035; Wed, 26 Mar 2003 16:13:22 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303262113.QAA32035@workhorse.fictitious.org> To: "Stephen Sprunk" cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: whining about renumbering (was: Re: IPv6 site-locals... end of story) In-reply-to: Your message of "Tue, 25 Mar 2003 15:53:53 CST." <01fa01c2f319$0c706660$93b58742@ssprunk> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 16:13:22 -0500 In message <01fa01c2f319$0c706660$93b58742@ssprunk>, "Stephen Sprunk" writes: > Thus spake David Conrad > > >The ONLY reason to use NAT was the lack of enough addresses. > > > > No. Another reason is that companies do not want to be held hostage > > due to the cost of renumbering which many would feel would be the > > case should they want to change providers. > > This is a point many people seem to be missing. Renumbering a few subnets > filled with clients is trivial with IPv6 -- just like it is with IPv4 DHCP. > However, renumbering servers and the resultant DNS issues is not trivial, > requiring months of planning if you can get management approval at all. Only if you are incompetent or don't have access to the client. Create two addresses for the servers and everything else. Take as much time as you need to do this. Then change DNS. Wait a few days (weeks) until you are sure that DNS everywhere is flushed out and no adverse reactions have ocurred. Then remove the old addresses. Take as much time as you need to do this too. Services are given CNAMEs and servers are given A records. For hardware upgrade services were moved to different servers. We got good enough at this that we could cut certain services over to new servers mid-day and no one could tell the difference. > Worse, renumbering is manpower-intensive when you consider there are > networks out there with 10,000+ sites/subnets, and some being built with the > goal of 50,000+ sites/subnets. Without 10/8, these networks wouldn't be > administratively possible. Remote administration and shell scripts / perl programs is the only way to go administering large networks. > Renumbering is not easy. Repeating it over and over doesn't make it so. > > 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 I've done it admitedly for only a few hundred subnets if that many, but it went fine and was not all that manpower intensive. This was without DHCP. We didn't have to walk up to pee-cees and click in the dialog boxes or it would have been impossible. As an ISP we routinely drilled taking the Michagan NOC down and switching over to the NY NOC, including changing servers for multiple database services. All generally worked fine and cutover in 15 minutes would have been easy if the telco didn't consistently mess up the transition of the incoming NOC phone lines. :-) DHCP or autoconfig can actually make the problem harder if learning two addresses for the same interface is not supported by all clients and servers. Two addresses are needed during the transition. Absent the ability to have two addresses on the clients, a few subnets at a time have to be cut over with routing between subnets in the old and the new address space. Still not overly difficult but a little better planning is required. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 16:54:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17112 for ; Wed, 26 Mar 2003 16:54:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMADO07275; Wed, 26 Mar 2003 17:10:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QM58O06296 for ; Wed, 26 Mar 2003 17:05:08 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16661 for ; Wed, 26 Mar 2003 16:43:39 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA32186; Wed, 26 Mar 2003 16:46:29 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303262146.QAA32186@workhorse.fictitious.org> To: Jing Shen cc: curtis@fictitious.org, Roland Bless , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: NAT != security (was Re: IPv6 site-locals... end of story...) In-reply-to: Your message of "Wed, 26 Mar 2003 14:56:09 +0800." <20030326065609.22367.qmail@web15103.mail.bjs.yahoo.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 16:46:29 -0500 In message <20030326065609.22367.qmail@web15103.mail.bjs.yahoo.com>, Jing Shen writes: > > > Hi, > >What this (and NAT) doesn't do is allow filtering based control of > >internal users. Clever user have put all sorts of services inside > >port 80 and even over HTTP. > > I have another sample: if we hire some service from ISP to connect our inter > nnal network to internet, we use NAT at access point which dynamically share > IP address pool to the whole subnet. If someone outside want to crack my comp > uter, he must firstly locate my computer's real address. This means the hacke > r must crack the NAT router at first. I think this improve the difficulty of > cracking. Also, round-robin load balancing between server farm is achived by > mapping single real address to several private address, this also improves th > e service reliablity. > thanks. > regards > Jing Shen NAT still adds nothing. If someone want to send an unfriendly UDP packet to a random SQL server, they only have to scan the 256 addresses of the NAT (or whatever), not the larger address space behind it. Any computer that has recently been active is hit by the scan. If computers have no reason to access anything outside the local network except through proxy, then filtering all but the server addresses solves the problem with or without NAT. If someone wanted to break into a specific computer, they'd just break into any old computer behind the NAT and then break into the computer they were targeting. For example, Has a PC ever contracted a virus? If so you have proven to be vulnerable behind the NAT and an attacker could leverage that vulnerability. Curtis ps - ANS used to log 300 attacks a day on the NSFnet infrastructure, all to no avail and only those not deemed not to be "kiddies" trying well known trivial attacks were tracked and turned over to the US FBI. We pointed to Mitnik attacking from university campuses and netcom long before SDSC got motivated to track him back to his cell phone. We caught a number of security audits where we were not notified, including ones from Purdue, BBN, and AT&T (all contracted security experts asked to audit us, one contracted by a federal agency and in two of these cases we contacted the FBI). _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 16:55:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17160 for ; Wed, 26 Mar 2003 16:55:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QMGSu07590 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 17:16:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMADO07275; Wed, 26 Mar 2003 17:10:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QM58O06296 for ; Wed, 26 Mar 2003 17:05:08 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16661 for ; Wed, 26 Mar 2003 16:43:39 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA32186; Wed, 26 Mar 2003 16:46:29 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303262146.QAA32186@workhorse.fictitious.org> To: Jing Shen cc: curtis@fictitious.org, Roland Bless , jshen@cad.zju.edu.cn, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: NAT != security (was Re: IPv6 site-locals... end of story...) In-reply-to: Your message of "Wed, 26 Mar 2003 14:56:09 +0800." <20030326065609.22367.qmail@web15103.mail.bjs.yahoo.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 16:46:29 -0500 In message <20030326065609.22367.qmail@web15103.mail.bjs.yahoo.com>, Jing Shen writes: > > > Hi, > >What this (and NAT) doesn't do is allow filtering based control of > >internal users. Clever user have put all sorts of services inside > >port 80 and even over HTTP. > > I have another sample: if we hire some service from ISP to connect our inter > nnal network to internet, we use NAT at access point which dynamically share > IP address pool to the whole subnet. If someone outside want to crack my comp > uter, he must firstly locate my computer's real address. This means the hacke > r must crack the NAT router at first. I think this improve the difficulty of > cracking. Also, round-robin load balancing between server farm is achived by > mapping single real address to several private address, this also improves th > e service reliablity. > thanks. > regards > Jing Shen NAT still adds nothing. If someone want to send an unfriendly UDP packet to a random SQL server, they only have to scan the 256 addresses of the NAT (or whatever), not the larger address space behind it. Any computer that has recently been active is hit by the scan. If computers have no reason to access anything outside the local network except through proxy, then filtering all but the server addresses solves the problem with or without NAT. If someone wanted to break into a specific computer, they'd just break into any old computer behind the NAT and then break into the computer they were targeting. For example, Has a PC ever contracted a virus? If so you have proven to be vulnerable behind the NAT and an attacker could leverage that vulnerability. Curtis ps - ANS used to log 300 attacks a day on the NSFnet infrastructure, all to no avail and only those not deemed not to be "kiddies" trying well known trivial attacks were tracked and turned over to the US FBI. We pointed to Mitnik attacking from university campuses and netcom long before SDSC got motivated to track him back to his cell phone. We caught a number of security audits where we were not notified, including ones from Purdue, BBN, and AT&T (all contracted security experts asked to audit us, one contracted by a federal agency and in two of these cases we contacted the FBI). _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 17:13:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17967 for ; Wed, 26 Mar 2003 17:13:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMMxO07995; Wed, 26 Mar 2003 17:22:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMCvO07433 for ; Wed, 26 Mar 2003 17:12:57 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16992 for ; Wed, 26 Mar 2003 16:51:28 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id A0947137F11; Wed, 26 Mar 2003 13:53:48 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Roland Bless , Jing Shen , jshen@cad.zju.edu.cn, routing-discussion@ietf.org To: Jeff Parker From: David Conrad In-Reply-To: Message-Id: <6C911300-5FD5-11D7-BCE2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 13:53:48 -0800 Content-Transfer-Encoding: 7bit Jeff, On Wednesday, March 26, 2003, at 07:55 AM, Jeff Parker wrote: >> When there are hundreds of sites out there >> running unpatched old versions of BIND or IIS >> ...why waste your time breaking through a NAT box? > Because the target is atractive? If the target is deemed attractive, then it would presumably have real security. I was suggesting that, all other things being equal, it is easier for the script kiddies to target known and easily accessible vulnerabilities of which there are myriad than it is to try to take on boxes in a disconnected address space. That's all. I'm not suggesting NAT provides real security, merely that it raises the bar a bit (sort of like the lock on your office door). Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 17:14:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18004 for ; Wed, 26 Mar 2003 17:14:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QMZMU08701 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 17:35:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMMxO07995; Wed, 26 Mar 2003 17:22:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMCvO07433 for ; Wed, 26 Mar 2003 17:12:57 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16992 for ; Wed, 26 Mar 2003 16:51:28 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id A0947137F11; Wed, 26 Mar 2003 13:53:48 -0800 (PST) Subject: Re: IPv6 site-locals... end of story... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Roland Bless , Jing Shen , jshen@cad.zju.edu.cn, routing-discussion@ietf.org To: Jeff Parker From: David Conrad In-Reply-To: Message-Id: <6C911300-5FD5-11D7-BCE2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 13:53:48 -0800 Content-Transfer-Encoding: 7bit Jeff, On Wednesday, March 26, 2003, at 07:55 AM, Jeff Parker wrote: >> When there are hundreds of sites out there >> running unpatched old versions of BIND or IIS >> ...why waste your time breaking through a NAT box? > Because the target is atractive? If the target is deemed attractive, then it would presumably have real security. I was suggesting that, all other things being equal, it is easier for the script kiddies to target known and easily accessible vulnerabilities of which there are myriad than it is to try to take on boxes in a disconnected address space. That's all. I'm not suggesting NAT provides real security, merely that it raises the bar a bit (sort of like the lock on your office door). Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 17:38:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18815 for ; Wed, 26 Mar 2003 17:38:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMraO10336; Wed, 26 Mar 2003 17:53:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMmpO10083 for ; Wed, 26 Mar 2003 17:48:51 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18294 for ; Wed, 26 Mar 2003 17:27:21 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 403BE137F11; Wed, 26 Mar 2003 14:29:41 -0800 (PST) Subject: Re: whining about renumbering (was: Re: IPv6 site-locals... end of story) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Stephen Sprunk" , routing-discussion@ietf.org To: curtis@fictitious.org From: David Conrad In-Reply-To: <200303262113.QAA32035@workhorse.fictitious.org> Message-Id: <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 14:29:41 -0800 Content-Transfer-Encoding: 7bit Curtis, On Wednesday, March 26, 2003, at 01:13 PM, Curtis Villamizar wrote: > Only if you are incompetent or don't have access to the client. I might suggest that you and everyone else on this list have a bit more technical competence than the vast majority of folks who are operating networks in the real world today. Oh yeah, and in most large scale enterprise networks I've encountered, it is excruciatingly common that the folks who run the routers and interact with the ISPs have absolutely no access or control over the vast majority of client systems. In many cases that I've personally experienced, the folks who run the routers and the folks who run the DNS servers and the folks tho allocate addresses/run DHCP servers are all different (and they typically don't communicate with each other particularly well). Pretending that renumbering is never a significant cost in large scale networks isn't going to get us anywhere other than NATsville. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 17:39:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18842 for ; Wed, 26 Mar 2003 17:39:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QN0NN10617 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 18:00:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMraO10336; Wed, 26 Mar 2003 17:53:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QMmpO10083 for ; Wed, 26 Mar 2003 17:48:51 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18294 for ; Wed, 26 Mar 2003 17:27:21 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 403BE137F11; Wed, 26 Mar 2003 14:29:41 -0800 (PST) Subject: Re: whining about renumbering (was: Re: IPv6 site-locals... end of story) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Stephen Sprunk" , routing-discussion@ietf.org To: curtis@fictitious.org From: David Conrad In-Reply-To: <200303262113.QAA32035@workhorse.fictitious.org> Message-Id: <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 14:29:41 -0800 Content-Transfer-Encoding: 7bit Curtis, On Wednesday, March 26, 2003, at 01:13 PM, Curtis Villamizar wrote: > Only if you are incompetent or don't have access to the client. I might suggest that you and everyone else on this list have a bit more technical competence than the vast majority of folks who are operating networks in the real world today. Oh yeah, and in most large scale enterprise networks I've encountered, it is excruciatingly common that the folks who run the routers and interact with the ISPs have absolutely no access or control over the vast majority of client systems. In many cases that I've personally experienced, the folks who run the routers and the folks who run the DNS servers and the folks tho allocate addresses/run DHCP servers are all different (and they typically don't communicate with each other particularly well). Pretending that renumbering is never a significant cost in large scale networks isn't going to get us anywhere other than NATsville. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 18:12:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21348 for ; Wed, 26 Mar 2003 18:12:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QNL3O12286; Wed, 26 Mar 2003 18:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QNHCO12150 for ; Wed, 26 Mar 2003 18:17:12 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19770 for ; Wed, 26 Mar 2003 17:55:42 -0500 (EST) Received: from cisco.com (sjc-vpn2-128.cisco.com [10.21.112.128]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA26805; Wed, 26 Mar 2003 14:57:48 -0800 (PST) Message-ID: <3E82306C.5050108@cisco.com> From: Eliot Lear 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: David Conrad CC: curtis@fictitious.org, Stephen Sprunk , routing-discussion@ietf.org Subject: Re: whining about renumbering (was: Re: IPv6 site-locals... end of story) References: <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> In-Reply-To: <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 14:57:48 -0800 Content-Transfer-Encoding: 7bit David Conrad wrote: > I might suggest that you and everyone else on this list have a bit more > technical competence than the vast majority of folks who are operating > networks in the real world today. Dave, you're absolutely right. But that puts the burden on us to make renumbering easier. Kludging the answer with site-local would be to shirk that responsibility. > Oh yeah, and in most large scale > enterprise networks I've encountered, it is excruciatingly common that > the folks who run the routers and interact with the ISPs have absolutely > no access or control over the vast majority of client systems. What we're talking about here is the IP address associated with that client system. There we are doing better. DHCP is the client interface to the network, and the network administrator largely controls that. > In many > cases that I've personally experienced, the folks who run the routers > and the folks who run the DNS servers and the folks tho allocate > addresses/run DHCP servers are all different (and they typically don't > communicate with each other particularly well). While I'm sure this happens, it is not commonplace for enterprises in my experience. Enterprises handle renumbering already. Once you move people you have to reallocate addressing periodically in order to ensure there are enough addresses. There are products out there that make this particularly easy. We sell one such thing. It's not the client that I would worry about. It's the big servers who stick IP addresses in weird places. > Pretending that renumbering is never a significant cost in large scale > networks isn't going to get us anywhere other than NATsville. You're right. But let's talk realistically about what tools and functions need to be dealt with. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 18:12:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21482 for ; Wed, 26 Mar 2003 18:12:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QNXwK12846 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 18:33:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QNL3O12286; Wed, 26 Mar 2003 18:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QNHCO12150 for ; Wed, 26 Mar 2003 18:17:12 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19770 for ; Wed, 26 Mar 2003 17:55:42 -0500 (EST) Received: from cisco.com (sjc-vpn2-128.cisco.com [10.21.112.128]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA26805; Wed, 26 Mar 2003 14:57:48 -0800 (PST) Message-ID: <3E82306C.5050108@cisco.com> From: Eliot Lear 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: David Conrad CC: curtis@fictitious.org, Stephen Sprunk , routing-discussion@ietf.org Subject: Re: whining about renumbering (was: Re: IPv6 site-locals... end of story) References: <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> In-Reply-To: <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 14:57:48 -0800 Content-Transfer-Encoding: 7bit David Conrad wrote: > I might suggest that you and everyone else on this list have a bit more > technical competence than the vast majority of folks who are operating > networks in the real world today. Dave, you're absolutely right. But that puts the burden on us to make renumbering easier. Kludging the answer with site-local would be to shirk that responsibility. > Oh yeah, and in most large scale > enterprise networks I've encountered, it is excruciatingly common that > the folks who run the routers and interact with the ISPs have absolutely > no access or control over the vast majority of client systems. What we're talking about here is the IP address associated with that client system. There we are doing better. DHCP is the client interface to the network, and the network administrator largely controls that. > In many > cases that I've personally experienced, the folks who run the routers > and the folks who run the DNS servers and the folks tho allocate > addresses/run DHCP servers are all different (and they typically don't > communicate with each other particularly well). While I'm sure this happens, it is not commonplace for enterprises in my experience. Enterprises handle renumbering already. Once you move people you have to reallocate addressing periodically in order to ensure there are enough addresses. There are products out there that make this particularly easy. We sell one such thing. It's not the client that I would worry about. It's the big servers who stick IP addresses in weird places. > Pretending that renumbering is never a significant cost in large scale > networks isn't going to get us anywhere other than NATsville. You're right. But let's talk realistically about what tools and functions need to be dealt with. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 18:32:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22414 for ; Wed, 26 Mar 2003 18:32:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QNfkO13898; Wed, 26 Mar 2003 18:41:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QNcjO13749 for ; Wed, 26 Mar 2003 18:38:45 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21915 for ; Wed, 26 Mar 2003 18:17:14 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA33361; Wed, 26 Mar 2003 18:20:10 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303262320.SAA33361@workhorse.fictitious.org> To: David Conrad cc: curtis@fictitious.org, "Stephen Sprunk" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: whining about renumbering (was: Re: IPv6 site-locals... end of story) In-reply-to: Your message of "Wed, 26 Mar 2003 14:29:41 PST." <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 18:20:10 -0500 In message <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com>, David Conrad wri tes: > > Pretending that renumbering is never a significant cost in large scale > networks isn't going to get us anywhere other than NATsville. > > Rgds, > -drc You are entirely correct. An ISP running entire *ix systems with authentication framework and complete remote administration in place will have a very easy time renumbering relative to a corporation which has lost control over the administration of their systems and can't even get at some machines or contact the people administering them. The only thing we can do is provide the means for easy renumbering. We can't really prevent anyone from botching it. I don't think this is a reason to continue to support NAT. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 18:33:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22437 for ; Wed, 26 Mar 2003 18:33:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QNsDG14447 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 18:54:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QNfkO13898; Wed, 26 Mar 2003 18:41:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QNcjO13749 for ; Wed, 26 Mar 2003 18:38:45 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21915 for ; Wed, 26 Mar 2003 18:17:14 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA33361; Wed, 26 Mar 2003 18:20:10 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303262320.SAA33361@workhorse.fictitious.org> To: David Conrad cc: curtis@fictitious.org, "Stephen Sprunk" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: whining about renumbering (was: Re: IPv6 site-locals... end of story) In-reply-to: Your message of "Wed, 26 Mar 2003 14:29:41 PST." <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 18:20:10 -0500 In message <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com>, David Conrad wri tes: > > Pretending that renumbering is never a significant cost in large scale > networks isn't going to get us anywhere other than NATsville. > > Rgds, > -drc You are entirely correct. An ISP running entire *ix systems with authentication framework and complete remote administration in place will have a very easy time renumbering relative to a corporation which has lost control over the administration of their systems and can't even get at some machines or contact the people administering them. The only thing we can do is provide the means for easy renumbering. We can't really prevent anyone from botching it. I don't think this is a reason to continue to support NAT. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 21:06:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27856 for ; Wed, 26 Mar 2003 21:06:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2CZO23800; Wed, 26 Mar 2003 21:12:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R29UO23601 for ; Wed, 26 Mar 2003 21:09:30 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27179 for ; Wed, 26 Mar 2003 20:47:55 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2R1o9L04553; Wed, 26 Mar 2003 19:50:09 -0600 Message-ID: <011201c2f403$32f743e0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Eliot Lear" , "David Conrad" Cc: , References: <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> <3E82306C.5050108@cisco.com> Subject: Re: whining about renumbering (was: Re: IPv6 site-locals... end of story) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 19:40:16 -0600 Content-Transfer-Encoding: 7bit Thus spake "Eliot Lear" > David Conrad wrote: > > In many > > cases that I've personally experienced, the folks who run the routers > > and the folks who run the DNS servers and the folks tho allocate > > addresses/run DHCP servers are all different (and they typically don't > > communicate with each other particularly well). > > While I'm sure this happens, it is not commonplace for enterprises in my > experience. I have yet to see a large Enterprise where DNS, DHCP, server administration (all twenty groups of it), and network engineering are run by the same people -- they're often handled from different continents. > Enterprises handle renumbering already. Once you move people you > have to reallocate addressing periodically in order to ensure there are > enough addresses. There are products out there that make > this particularly easy. We sell one such thing. Compare the administrative burden of having to comply with RIR allocation policies across your entire corporation (which may be under several dozen different administrative areas) and being forced to pay your ISP per IP address, vs. just tossing a NAT in, using a public /24 or two for external servers, and never having to worry about internal allocation. Companies with legacy class A/B space are an exception. Remember, under the proposed IPv6 allocation policies, no end users will have portable space. > It's not the client that I would worry about. It's the big servers who > stick IP addresses in weird places. Something as serious as changing an IP address can be a 6-12 month project due to all the testing and validation required. Seems loony, yes, but I've seen mission-critical servers made inoperable by installing a new printer driver. Would you bet your job and your pension on renumbering being a flawless overnight exercise? 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 21:07:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27887 for ; Wed, 26 Mar 2003 21:07:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R2SCF24872 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 21:28:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2CZO23800; Wed, 26 Mar 2003 21:12:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R29UO23601 for ; Wed, 26 Mar 2003 21:09:30 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27179 for ; Wed, 26 Mar 2003 20:47:55 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2R1o9L04553; Wed, 26 Mar 2003 19:50:09 -0600 Message-ID: <011201c2f403$32f743e0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Eliot Lear" , "David Conrad" Cc: , References: <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> <3E82306C.5050108@cisco.com> Subject: Re: whining about renumbering (was: Re: IPv6 site-locals... end of story) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 19:40:16 -0600 Content-Transfer-Encoding: 7bit Thus spake "Eliot Lear" > David Conrad wrote: > > In many > > cases that I've personally experienced, the folks who run the routers > > and the folks who run the DNS servers and the folks tho allocate > > addresses/run DHCP servers are all different (and they typically don't > > communicate with each other particularly well). > > While I'm sure this happens, it is not commonplace for enterprises in my > experience. I have yet to see a large Enterprise where DNS, DHCP, server administration (all twenty groups of it), and network engineering are run by the same people -- they're often handled from different continents. > Enterprises handle renumbering already. Once you move people you > have to reallocate addressing periodically in order to ensure there are > enough addresses. There are products out there that make > this particularly easy. We sell one such thing. Compare the administrative burden of having to comply with RIR allocation policies across your entire corporation (which may be under several dozen different administrative areas) and being forced to pay your ISP per IP address, vs. just tossing a NAT in, using a public /24 or two for external servers, and never having to worry about internal allocation. Companies with legacy class A/B space are an exception. Remember, under the proposed IPv6 allocation policies, no end users will have portable space. > It's not the client that I would worry about. It's the big servers who > stick IP addresses in weird places. Something as serious as changing an IP address can be a 6-12 month project due to all the testing and validation required. Seems loony, yes, but I've seen mission-critical servers made inoperable by installing a new printer driver. Would you bet your job and your pension on renumbering being a flawless overnight exercise? 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 21:17:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28288 for ; Wed, 26 Mar 2003 21:17:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2R8O24773; Wed, 26 Mar 2003 21:27:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2OvO24593 for ; Wed, 26 Mar 2003 21:24:57 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27778 for ; Wed, 26 Mar 2003 21:03:22 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2R25eL04847; Wed, 26 Mar 2003 20:05:40 -0600 Message-ID: <014c01c2f405$5e208ac0$93b58742@ssprunk> From: "Stephen Sprunk" To: Cc: "David Conrad" , References: <200303262320.SAA33361@workhorse.fictitious.org> Subject: Re: whining about renumbering (was: Re: IPv6 site-locals... end of story) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 19:51:44 -0600 Content-Transfer-Encoding: 7bit Thus spake "Curtis Villamizar" > The only thing we can do is provide the means for easy renumbering. > We can't really prevent anyone from botching it. I don't think this > is a reason to continue to support NAT. Users want NATs, and that means they'll buy and use them. The IETF can discourage this practice as it has done with IPv4 NATs, but that's it. Refusing to standardize it will only hurt us down the road. Re: the topic. I'm not advocating site-local addressing or indeed any other form of scoped addresses; what I do advocate is a single private address prefix, which many of us had been planning on using the site-local prefix for. This may be why anti-NAT folks seem to be taken by surprise at the number of folks planning to use NATs with IPv6 -- we just weren't going to tell you. 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 21:18:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28304 for ; Wed, 26 Mar 2003 21:18:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R2dOg26245 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 21:39:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2R8O24773; Wed, 26 Mar 2003 21:27:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2OvO24593 for ; Wed, 26 Mar 2003 21:24:57 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27778 for ; Wed, 26 Mar 2003 21:03:22 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2R25eL04847; Wed, 26 Mar 2003 20:05:40 -0600 Message-ID: <014c01c2f405$5e208ac0$93b58742@ssprunk> From: "Stephen Sprunk" To: Cc: "David Conrad" , References: <200303262320.SAA33361@workhorse.fictitious.org> Subject: Re: whining about renumbering (was: Re: IPv6 site-locals... end of story) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 19:51:44 -0600 Content-Transfer-Encoding: 7bit Thus spake "Curtis Villamizar" > The only thing we can do is provide the means for easy renumbering. > We can't really prevent anyone from botching it. I don't think this > is a reason to continue to support NAT. Users want NATs, and that means they'll buy and use them. The IETF can discourage this practice as it has done with IPv4 NATs, but that's it. Refusing to standardize it will only hurt us down the road. Re: the topic. I'm not advocating site-local addressing or indeed any other form of scoped addresses; what I do advocate is a single private address prefix, which many of us had been planning on using the site-local prefix for. This may be why anti-NAT folks seem to be taken by surprise at the number of folks planning to use NATs with IPv6 -- we just weren't going to tell you. 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 21:18:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28323 for ; Wed, 26 Mar 2003 21:18:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2NCO24505; Wed, 26 Mar 2003 21:23:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2KdO24369 for ; Wed, 26 Mar 2003 21:20:39 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27684 for ; Wed, 26 Mar 2003 20:59:03 -0500 (EST) Received: from cisco.com (sjc-vpn3-217.cisco.com [10.21.64.217]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA25651; Wed, 26 Mar 2003 18:01:10 -0800 (PST) Message-ID: <3E825B64.2090507@cisco.com> From: Eliot Lear 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: Stephen Sprunk CC: David Conrad , curtis@fictitious.org, routing-discussion@ietf.org Subject: Re: whining about renumbering References: <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> <3E82306C.5050108@cisco.com> <011201c2f403$32f743e0$93b58742@ssprunk> In-Reply-To: <011201c2f403$32f743e0$93b58742@ssprunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 18:01:08 -0800 Content-Transfer-Encoding: 7bit Stephen Sprunk wrote: > I have yet to see a large Enterprise where DNS, DHCP, server administration > (all twenty groups of it), and network engineering are run by the same > people -- they're often handled from different continents. You snuck one in there, and made it a red herring. Server administration is a very different beast. Take that out and I would hazard to say that the majority of enterprises aggregate these roles into either network engineering or network management. The keyword there is "network". > Compare the administrative burden of having to comply with RIR allocation > policies across your entire corporation (which may be under several dozen > different administrative areas) and being forced to pay your ISP per IP > address, vs. just tossing a NAT in, using a public /24 or two for external > servers, and never having to worry about internal allocation. Ye of little faith. This is what a healthy market is for. Service providers sell bandwidth. If they make it too hard to add networks and hosts they will sell less bandwidth. They know this. RIRs sell addresses. If addresses get too expensive then we need more RIRs. > Companies with legacy class A/B space are an exception. Remember, under the > proposed IPv6 allocation policies, no end users will have portable space. Not so. Anyone can buy address space. Whether it's routable is another story. > Something as serious as changing an IP address can be a 6-12 month project > due to all the testing and validation required. Seems loony, yes, but I've > seen mission-critical servers made inoperable by installing a new printer > driver. Would you bet your job and your pension on renumbering being a > flawless overnight exercise? I *did* bet my job on renumbering a large corporate network, complete with mission critical components. Network didn't work? No bookings. If you're challenging whether I take this stuff seriously, I certainly do. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 21:19:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28345 for ; Wed, 26 Mar 2003 21:19:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R2eFq26310 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 21:40:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2NCO24505; Wed, 26 Mar 2003 21:23:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2KdO24369 for ; Wed, 26 Mar 2003 21:20:39 -0500 Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27684 for ; Wed, 26 Mar 2003 20:59:03 -0500 (EST) Received: from cisco.com (sjc-vpn3-217.cisco.com [10.21.64.217]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA25651; Wed, 26 Mar 2003 18:01:10 -0800 (PST) Message-ID: <3E825B64.2090507@cisco.com> From: Eliot Lear 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: Stephen Sprunk CC: David Conrad , curtis@fictitious.org, routing-discussion@ietf.org Subject: Re: whining about renumbering References: <6FC38EC8-5FDA-11D7-BCE2-000393DB42B2@nominum.com> <3E82306C.5050108@cisco.com> <011201c2f403$32f743e0$93b58742@ssprunk> In-Reply-To: <011201c2f403$32f743e0$93b58742@ssprunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 18:01:08 -0800 Content-Transfer-Encoding: 7bit Stephen Sprunk wrote: > I have yet to see a large Enterprise where DNS, DHCP, server administration > (all twenty groups of it), and network engineering are run by the same > people -- they're often handled from different continents. You snuck one in there, and made it a red herring. Server administration is a very different beast. Take that out and I would hazard to say that the majority of enterprises aggregate these roles into either network engineering or network management. The keyword there is "network". > Compare the administrative burden of having to comply with RIR allocation > policies across your entire corporation (which may be under several dozen > different administrative areas) and being forced to pay your ISP per IP > address, vs. just tossing a NAT in, using a public /24 or two for external > servers, and never having to worry about internal allocation. Ye of little faith. This is what a healthy market is for. Service providers sell bandwidth. If they make it too hard to add networks and hosts they will sell less bandwidth. They know this. RIRs sell addresses. If addresses get too expensive then we need more RIRs. > Companies with legacy class A/B space are an exception. Remember, under the > proposed IPv6 allocation policies, no end users will have portable space. Not so. Anyone can buy address space. Whether it's routable is another story. > Something as serious as changing an IP address can be a 6-12 month project > due to all the testing and validation required. Seems loony, yes, but I've > seen mission-critical servers made inoperable by installing a new printer > driver. Would you bet your job and your pension on renumbering being a > flawless overnight exercise? I *did* bet my job on renumbering a large corporate network, complete with mission critical components. Network didn't work? No bookings. If you're challenging whether I take this stuff seriously, I certainly do. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 21:35:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29064 for ; Wed, 26 Mar 2003 21:35:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2hAO26477; Wed, 26 Mar 2003 21:43:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2ebO26352 for ; Wed, 26 Mar 2003 21:40:37 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28343 for ; Wed, 26 Mar 2003 21:19:01 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2R2LKL05131; Wed, 26 Mar 2003 20:21:20 -0600 Message-ID: <000001c2f407$8deaf810$93b58742@ssprunk> From: "Stephen Sprunk" To: Cc: "Eliot Lear" , References: <200303262045.PAA31575@workhorse.fictitious.org> Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 20:14:41 -0600 Content-Transfer-Encoding: 7bit Thus spake "Curtis Villamizar" > > I can't give names, but let's think about this. There are about 15,000 > > McDonalds restaurants in the US alone; many retail stores have similar > > numbers. Bank ATMs typically have a router and local subnet inside them, > > and there's tens of thousands of those things around too. I don't have > > exact numbers, but I'd guess the major oil companies have 20,000 gas station > > each. And let's not forget the US Postal Service with tens of thousands of > > post offices. > > And fedex and UPS have routeable IPv4 addresses for similar > purposes. Works fine for them so Mickey D's and the the banks > should be fine too. A few have legacy class A/B allocations for this, but those who don't use 10/8. Even many companies with portable addresses use 10/8 anyways because it offers more flexibility. Much of this would be solved if we'd give portable IPv6 addresses to anyone with a reasonable justification. It's not like there's a shortage of them. > Renumbering is supposed to be easy with IPv6. I always found it > plenty easy enough with IPv4, so I won't comment on whether it is easy > enough with IPv6. Renumbering costs manpower, and businesses do not spend time (aka money) on projects like that unless there is a financial return. Renumbering is not free and _it has no business value_. Given that, NATs will win in the real world no matter how much we work to reduce the absolute cost of renumbering. 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 21:36:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29099 for ; Wed, 26 Mar 2003 21:36:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R2v7b27228 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 21:57:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2hAO26477; Wed, 26 Mar 2003 21:43:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2ebO26352 for ; Wed, 26 Mar 2003 21:40:37 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28343 for ; Wed, 26 Mar 2003 21:19:01 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2R2LKL05131; Wed, 26 Mar 2003 20:21:20 -0600 Message-ID: <000001c2f407$8deaf810$93b58742@ssprunk> From: "Stephen Sprunk" To: Cc: "Eliot Lear" , References: <200303262045.PAA31575@workhorse.fictitious.org> Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 20:14:41 -0600 Content-Transfer-Encoding: 7bit Thus spake "Curtis Villamizar" > > I can't give names, but let's think about this. There are about 15,000 > > McDonalds restaurants in the US alone; many retail stores have similar > > numbers. Bank ATMs typically have a router and local subnet inside them, > > and there's tens of thousands of those things around too. I don't have > > exact numbers, but I'd guess the major oil companies have 20,000 gas station > > each. And let's not forget the US Postal Service with tens of thousands of > > post offices. > > And fedex and UPS have routeable IPv4 addresses for similar > purposes. Works fine for them so Mickey D's and the the banks > should be fine too. A few have legacy class A/B allocations for this, but those who don't use 10/8. Even many companies with portable addresses use 10/8 anyways because it offers more flexibility. Much of this would be solved if we'd give portable IPv6 addresses to anyone with a reasonable justification. It's not like there's a shortage of them. > Renumbering is supposed to be easy with IPv6. I always found it > plenty easy enough with IPv4, so I won't comment on whether it is easy > enough with IPv6. Renumbering costs manpower, and businesses do not spend time (aka money) on projects like that unless there is a financial return. Renumbering is not free and _it has no business value_. Given that, NATs will win in the real world no matter how much we work to reduce the absolute cost of renumbering. 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 21:40:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29347 for ; Wed, 26 Mar 2003 21:40:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2o4O26908; Wed, 26 Mar 2003 21:50:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2lhO26822 for ; Wed, 26 Mar 2003 21:47:43 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28642 for ; Wed, 26 Mar 2003 21:26:08 -0500 (EST) Received: from 78-RC321.bbn.com (tc238-196.bbn.com [128.33.238.196]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2R2Rm5w015218; Wed, 26 Mar 2003 21:27:50 -0500 (EST) Message-Id: <5.1.0.14.2.20030326212252.02617ad0@po2.bbn.com> X-Sender: celliott@po2.bbn.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: "Stephen Sprunk" , From: Chip Elliott Subject: IPv6: site-local vs private Cc: "David Conrad" , In-Reply-To: <014c01c2f405$5e208ac0$93b58742@ssprunk> References: <200303262320.SAA33361@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 21:26:55 -0500 At 08:51 PM 3/26/2003, Stephen Sprunk wrote: >Re: the topic. I'm not advocating site-local addressing or indeed any other >form of scoped addresses; what I do advocate is a single private address >prefix, which many of us had been planning on using the site-local prefix >for. One more datapoint for this discussion. I have never been able to figure out how I would define or use site-local addressing in my life, but have often had applications for a private address space. It would not be hard to carry that IPv4 concept over into IPv6 and would, IMHO, in fact be useful. Cheers, Chip Elliott Principal Engineer, BBN _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 21:41:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29372 for ; Wed, 26 Mar 2003 21:41:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R32JQ27500 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 22:02:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2o4O26908; Wed, 26 Mar 2003 21:50:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2lhO26822 for ; Wed, 26 Mar 2003 21:47:43 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28642 for ; Wed, 26 Mar 2003 21:26:08 -0500 (EST) Received: from 78-RC321.bbn.com (tc238-196.bbn.com [128.33.238.196]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2R2Rm5w015218; Wed, 26 Mar 2003 21:27:50 -0500 (EST) Message-Id: <5.1.0.14.2.20030326212252.02617ad0@po2.bbn.com> X-Sender: celliott@po2.bbn.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: "Stephen Sprunk" , From: Chip Elliott Subject: IPv6: site-local vs private Cc: "David Conrad" , In-Reply-To: <014c01c2f405$5e208ac0$93b58742@ssprunk> References: <200303262320.SAA33361@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 21:26:55 -0500 At 08:51 PM 3/26/2003, Stephen Sprunk wrote: >Re: the topic. I'm not advocating site-local addressing or indeed any other >form of scoped addresses; what I do advocate is a single private address >prefix, which many of us had been planning on using the site-local prefix >for. One more datapoint for this discussion. I have never been able to figure out how I would define or use site-local addressing in my life, but have often had applications for a private address space. It would not be hard to carry that IPv4 concept over into IPv6 and would, IMHO, in fact be useful. Cheers, Chip Elliott Principal Engineer, BBN _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 22:13:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00178 for ; Wed, 26 Mar 2003 22:13:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3LRO28851; Wed, 26 Mar 2003 22:21:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3GvO28689 for ; Wed, 26 Mar 2003 22:16:57 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29630 for ; Wed, 26 Mar 2003 21:55:22 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id AD476137F09; Wed, 26 Mar 2003 18:57:41 -0800 (PST) Subject: Re: whining about renumbering Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Stephen Sprunk , curtis@fictitious.org, routing-discussion@ietf.org To: Eliot Lear From: David Conrad In-Reply-To: <3E825B64.2090507@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 18:57:42 -0800 Content-Transfer-Encoding: 7bit Eliot, On Wednesday, March 26, 2003, at 06:01 PM, Eliot Lear wrote: > You snuck one in there, and made it a red herring. Server > administration is a very different beast. Take that out and I would > hazard to say that the majority of enterprises aggregate these roles > into either network engineering or network management. Not in my experience, but the world is full of surprises. > Ye of little faith. This is what a healthy market is for. Service > providers sell bandwidth. If they make it too hard to add networks > and hosts they will sell less bandwidth. They know this. Customers buy Internet connectivity. If it is easier/cheaper to obtain that connectivity via NAT, they'll do so. The "problem" is that NAT's true costs are not direct -- they show up in end user and system administrator time and/or inability to run certain applications, many of which CIOs don't particular care about anyway (and the ones that CIOs do care about get application layer gateways or other hacks). > RIRs sell addresses. No they don't. > If addresses get too expensive then we need more RIRs. I once used to argue for competitive address allocation organizations. People shouted me down. Suffice it to say, it doesn't work this way. > Anyone can buy address space. Well, yes, in as much anyone can buy snake oil, but in reality, no. It is possible to obtain address space via money, but it is a bit ... complicated. > Whether it's routable is another story. One out of four is pretty bad... :-) In any event, I suspect we are in violent agreement about the needs to make renumbering easy. Private addressing (site local or otherwise) is a bandaid on a sucking chest wound -- the real need is a scalable routing architecture and/or mechanisms that remove the costs/pain associated with addressing and renumbering. Lacking those, you'll have NAT -- I'd bet your life on it... :-) Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 22:13:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00223 for ; Wed, 26 Mar 2003 22:13:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R3Yqm29424 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 22:34:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3LRO28851; Wed, 26 Mar 2003 22:21:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3GvO28689 for ; Wed, 26 Mar 2003 22:16:57 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29630 for ; Wed, 26 Mar 2003 21:55:22 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id AD476137F09; Wed, 26 Mar 2003 18:57:41 -0800 (PST) Subject: Re: whining about renumbering Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Stephen Sprunk , curtis@fictitious.org, routing-discussion@ietf.org To: Eliot Lear From: David Conrad In-Reply-To: <3E825B64.2090507@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 18:57:42 -0800 Content-Transfer-Encoding: 7bit Eliot, On Wednesday, March 26, 2003, at 06:01 PM, Eliot Lear wrote: > You snuck one in there, and made it a red herring. Server > administration is a very different beast. Take that out and I would > hazard to say that the majority of enterprises aggregate these roles > into either network engineering or network management. Not in my experience, but the world is full of surprises. > Ye of little faith. This is what a healthy market is for. Service > providers sell bandwidth. If they make it too hard to add networks > and hosts they will sell less bandwidth. They know this. Customers buy Internet connectivity. If it is easier/cheaper to obtain that connectivity via NAT, they'll do so. The "problem" is that NAT's true costs are not direct -- they show up in end user and system administrator time and/or inability to run certain applications, many of which CIOs don't particular care about anyway (and the ones that CIOs do care about get application layer gateways or other hacks). > RIRs sell addresses. No they don't. > If addresses get too expensive then we need more RIRs. I once used to argue for competitive address allocation organizations. People shouted me down. Suffice it to say, it doesn't work this way. > Anyone can buy address space. Well, yes, in as much anyone can buy snake oil, but in reality, no. It is possible to obtain address space via money, but it is a bit ... complicated. > Whether it's routable is another story. One out of four is pretty bad... :-) In any event, I suspect we are in violent agreement about the needs to make renumbering easy. Private addressing (site local or otherwise) is a bandaid on a sucking chest wound -- the real need is a scalable routing architecture and/or mechanisms that remove the costs/pain associated with addressing and renumbering. Lacking those, you'll have NAT -- I'd bet your life on it... :-) Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 22:14:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00263 for ; Wed, 26 Mar 2003 22:14:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3O3O28931; Wed, 26 Mar 2003 22:24:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3I8O28724 for ; Wed, 26 Mar 2003 22:18:08 -0500 Received: from ginger.lcs.mit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29649 for ; Wed, 26 Mar 2003 21:56:34 -0500 (EST) Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h2R2wrkw018335; Wed, 26 Mar 2003 21:58:53 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h2R2wqGB018334; Wed, 26 Mar 2003 21:58:52 -0500 From: "J. Noel Chiappa" Message-Id: <200303270258.h2R2wqGB018334@ginger.lcs.mit.edu> To: routing-discussion@ietf.org Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) Cc: jnc@ginger.lcs.mit.edu Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 21:58:52 -0500 > From: "Stephen Sprunk" > Much of this would be solved if we'd give portable IPv6 addresses to > anyone with a reasonable justification. Much of the energy crisis would be solved if we'd give perpetual motion machines to anyone with a reasonable justification. Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 22:15:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00306 for ; Wed, 26 Mar 2003 22:15:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R3aXA29548 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 22:36:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3O3O28931; Wed, 26 Mar 2003 22:24:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3I8O28724 for ; Wed, 26 Mar 2003 22:18:08 -0500 Received: from ginger.lcs.mit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29649 for ; Wed, 26 Mar 2003 21:56:34 -0500 (EST) Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h2R2wrkw018335; Wed, 26 Mar 2003 21:58:53 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h2R2wqGB018334; Wed, 26 Mar 2003 21:58:52 -0500 From: "J. Noel Chiappa" Message-Id: <200303270258.h2R2wqGB018334@ginger.lcs.mit.edu> To: routing-discussion@ietf.org Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) Cc: jnc@ginger.lcs.mit.edu Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 21:58:52 -0500 > From: "Stephen Sprunk" > Much of this would be solved if we'd give portable IPv6 addresses to > anyone with a reasonable justification. Much of the energy crisis would be solved if we'd give perpetual motion machines to anyone with a reasonable justification. Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Mar 26 22:17:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00428 for ; Wed, 26 Mar 2003 22:17:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3QBO29003; Wed, 26 Mar 2003 22:26:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3JbO28771 for ; Wed, 26 Mar 2003 22:19:37 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29671 for ; Wed, 26 Mar 2003 21:58:03 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id DF1D3137F09; Wed, 26 Mar 2003 19:00:22 -0800 (PST) Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: , "Eliot Lear" , To: "Stephen Sprunk" From: David Conrad In-Reply-To: <000001c2f407$8deaf810$93b58742@ssprunk> Message-Id: <40800C56-6000-11D7-BCE2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 19:00:22 -0800 Content-Transfer-Encoding: 7bit Stephen, On Wednesday, March 26, 2003, at 06:14 PM, Stephen Sprunk wrote: > Much of this would be solved if we'd give portable IPv6 addresses to > anyone > with a reasonable justification. Define "reasonable justification". As you note, scarcity is not the current constraining factor. Swamp avoidance is. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Wed Mar 26 22:17:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00451 for ; Wed, 26 Mar 2003 22:17:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R3ccq30452 for routing-discussion-archive@odin.ietf.org; Wed, 26 Mar 2003 22:38:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3QBO29003; Wed, 26 Mar 2003 22:26:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R3JbO28771 for ; Wed, 26 Mar 2003 22:19:37 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29671 for ; Wed, 26 Mar 2003 21:58:03 -0500 (EST) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id DF1D3137F09; Wed, 26 Mar 2003 19:00:22 -0800 (PST) Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: , "Eliot Lear" , To: "Stephen Sprunk" From: David Conrad In-Reply-To: <000001c2f407$8deaf810$93b58742@ssprunk> Message-Id: <40800C56-6000-11D7-BCE2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 19:00:22 -0800 Content-Transfer-Encoding: 7bit Stephen, On Wednesday, March 26, 2003, at 06:14 PM, Stephen Sprunk wrote: > Much of this would be solved if we'd give portable IPv6 addresses to > anyone > with a reasonable justification. Define "reasonable justification". As you note, scarcity is not the current constraining factor. Swamp avoidance is. Rgds, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 27 00:23:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03279 for ; Thu, 27 Mar 2003 00:23:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R5cdO05927; Thu, 27 Mar 2003 00:38:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R5W9O04997 for ; Thu, 27 Mar 2003 00:32:09 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02741 for ; Thu, 27 Mar 2003 00:10:31 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2R5CkL07823; Wed, 26 Mar 2003 23:12:46 -0600 Message-ID: <00d701c2f41f$817076b0$93b58742@ssprunk> From: "Stephen Sprunk" To: "David Conrad" Cc: , "Eliot Lear" , References: <40800C56-6000-11D7-BCE2-000393DB42B2@nominum.com> Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 23:02:01 -0600 Content-Transfer-Encoding: 7bit Thus spake "David Conrad" > On Wednesday, March 26, 2003, at 06:14 PM, Stephen Sprunk wrote: > > Much of this would be solved if we'd give portable IPv6 addresses to > > anyone with a reasonable justification. > > Define "reasonable justification". > > As you note, scarcity is not the current constraining factor. Swamp > avoidance is. I don't see how we can expect to reduce the tables to less than one prefix per ASN, so that's a start right there: every ASN comes with a pre-assigned prefix*. This is how 6bone worked for many years, in fact. Beyond that, it's hard to say. I can't think of any examples of companies with substantial internal networks that don't have an ASN already, but I'm sure there are some. Given how easy it is to get an ASN, I'm not sure there's much utility in developing a rule for the no-ASN case. * I'd suggest a /48 for AS-based allocations, not to be suballocated to customers; ISPs would need a second, larger allocation and probably not use the AS-based one. 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Mar 27 00:24:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03368 for ; Thu, 27 Mar 2003 00:24:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R5jpu06341 for routing-discussion-archive@odin.ietf.org; Thu, 27 Mar 2003 00:45:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R5cdO05927; Thu, 27 Mar 2003 00:38:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R5W9O04997 for ; Thu, 27 Mar 2003 00:32:09 -0500 Received: from defiant.dfw.nostrum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02741 for ; Thu, 27 Mar 2003 00:10:31 -0500 (EST) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h2R5CkL07823; Wed, 26 Mar 2003 23:12:46 -0600 Message-ID: <00d701c2f41f$817076b0$93b58742@ssprunk> From: "Stephen Sprunk" To: "David Conrad" Cc: , "Eliot Lear" , References: <40800C56-6000-11D7-BCE2-000393DB42B2@nominum.com> Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 23:02:01 -0600 Content-Transfer-Encoding: 7bit Thus spake "David Conrad" > On Wednesday, March 26, 2003, at 06:14 PM, Stephen Sprunk wrote: > > Much of this would be solved if we'd give portable IPv6 addresses to > > anyone with a reasonable justification. > > Define "reasonable justification". > > As you note, scarcity is not the current constraining factor. Swamp > avoidance is. I don't see how we can expect to reduce the tables to less than one prefix per ASN, so that's a start right there: every ASN comes with a pre-assigned prefix*. This is how 6bone worked for many years, in fact. Beyond that, it's hard to say. I can't think of any examples of companies with substantial internal networks that don't have an ASN already, but I'm sure there are some. Given how easy it is to get an ASN, I'm not sure there's much utility in developing a rule for the no-ASN case. * I'd suggest a /48 for AS-based allocations, not to be suballocated to customers; ISPs would need a second, larger allocation and probably not use the AS-based one. 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 27 00:35:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04021 for ; Thu, 27 Mar 2003 00:35:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R5oqO06496; Thu, 27 Mar 2003 00:50:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R5kVO06379 for ; Thu, 27 Mar 2003 00:46:31 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03383 for ; Thu, 27 Mar 2003 00:24:48 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 5B2E223C38; Wed, 26 Mar 2003 21:17:09 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2R5R9YB024009; Wed, 26 Mar 2003 21:27:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: whining about renumbering (was: Re: IPv6 site-locals... end of story) Message-ID: Thread-Topic: whining about renumbering (was: Re: IPv6 site-locals... end of story) Thread-Index: AcLz6Y1ljGDKtCZrTB+O69AODblZiQAN9MrA From: "Tony Li" To: "David Conrad" , Cc: "Stephen Sprunk" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2R5kVO06380 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 21:27:09 -0800 Content-Transfer-Encoding: 8bit One of the big selling points of v6 was that renumbering was gonna be easy, right? So we didn't have to do funky addressing... Are you telling me that one of the selling points of v6 is bunk? Tony | -----Original Message----- | From: David Conrad [mailto:david.conrad@nominum.com] | Sent: Wednesday, March 26, 2003 2:30 PM | To: curtis@fictitious.org | Cc: Stephen Sprunk; routing-discussion@ietf.org | Subject: Re: whining about renumbering (was: Re: IPv6 | site-locals... end of story) | | | Curtis, | | On Wednesday, March 26, 2003, at 01:13 PM, Curtis | Villamizar wrote: | > Only if you are incompetent or don't have access to the client. | | I might suggest that you and everyone else on this list | have a bit more | technical competence than the vast majority of folks who | are operating | networks in the real world today. Oh yeah, and in most | large scale | enterprise networks I've encountered, it is excruciatingly | common that | the folks who run the routers and interact with the ISPs have | absolutely no access or control over the vast majority of client | systems. In many cases that I've personally experienced, | the folks who | run the routers and the folks who run the DNS servers and | the folks tho | allocate addresses/run DHCP servers are all different (and they | typically don't communicate with each other particularly well). | | Pretending that renumbering is never a significant cost in | large scale | networks isn't going to get us anywhere other than NATsville. | | Rgds, | -drc | | | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Mar 27 00:36:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04046 for ; Thu, 27 Mar 2003 00:36:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R5vOc06953 for routing-discussion-archive@odin.ietf.org; Thu, 27 Mar 2003 00:57:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R5oqO06496; Thu, 27 Mar 2003 00:50:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R5kVO06379 for ; Thu, 27 Mar 2003 00:46:31 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03383 for ; Thu, 27 Mar 2003 00:24:48 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 5B2E223C38; Wed, 26 Mar 2003 21:17:09 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h2R5R9YB024009; Wed, 26 Mar 2003 21:27:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: whining about renumbering (was: Re: IPv6 site-locals... end of story) Message-ID: Thread-Topic: whining about renumbering (was: Re: IPv6 site-locals... end of story) Thread-Index: AcLz6Y1ljGDKtCZrTB+O69AODblZiQAN9MrA From: "Tony Li" To: "David Conrad" , Cc: "Stephen Sprunk" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2R5kVO06380 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Mar 2003 21:27:09 -0800 Content-Transfer-Encoding: 8bit One of the big selling points of v6 was that renumbering was gonna be easy, right? So we didn't have to do funky addressing... Are you telling me that one of the selling points of v6 is bunk? Tony | -----Original Message----- | From: David Conrad [mailto:david.conrad@nominum.com] | Sent: Wednesday, March 26, 2003 2:30 PM | To: curtis@fictitious.org | Cc: Stephen Sprunk; routing-discussion@ietf.org | Subject: Re: whining about renumbering (was: Re: IPv6 | site-locals... end of story) | | | Curtis, | | On Wednesday, March 26, 2003, at 01:13 PM, Curtis | Villamizar wrote: | > Only if you are incompetent or don't have access to the client. | | I might suggest that you and everyone else on this list | have a bit more | technical competence than the vast majority of folks who | are operating | networks in the real world today. Oh yeah, and in most | large scale | enterprise networks I've encountered, it is excruciatingly | common that | the folks who run the routers and interact with the ISPs have | absolutely no access or control over the vast majority of client | systems. In many cases that I've personally experienced, | the folks who | run the routers and the folks who run the DNS servers and | the folks tho | allocate addresses/run DHCP servers are all different (and they | typically don't communicate with each other particularly well). | | Pretending that renumbering is never a significant cost in | large scale | networks isn't going to get us anywhere other than NATsville. | | Rgds, | -drc | | | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Mar 27 01:00:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04822 for ; Thu, 27 Mar 2003 01:00:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R6GeO08529; Thu, 27 Mar 2003 01:16:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONEsO08986 for ; Mon, 24 Mar 2003 18:14:54 -0500 Received: from lakecmmtao01.coxmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07033 for ; Mon, 24 Mar 2003 17:54:22 -0500 (EST) Received: from apocalypse.org ([68.15.42.104]) by lakecmmtao01.coxmail.com (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030324225641.KRHD25316.lakecmmtao01.coxmail.com@apocalypse.org> for ; Mon, 24 Mar 2003 17:56:41 -0500 Message-ID: <3E7F8C4D.1090900@apocalypse.org> From: avri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 14:53:01 -0800 Content-Transfer-Encoding: 7bit While it may not be necessary to economize with IP space in IPv6, there is nothing to prevent a local service provider from creating an artificial shortage that then allows them to charge me for every address I use in my home. Local addressing gives the user, i.e.. our silent majority, some means of fighting those who would make them pay for every address used. I believe that as long as this address monopoly exists, there will be users who will buy any device that gives them address freedom. So, it isn't the end of the story, just the end of a chapter. a. Tony Li wrote: > > > If we need to economize on v6 address space, then it isn't big enough. > > Tony > > > | -----Original Message----- > | From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > | Sent: Monday, March 24, 2003 2:08 PM > | To: routing-discussion@ietf.org > | Subject: RE: IPv6 site-locals... end of story... > | > | > | About RFC 1627 ... > | > | The reasons for using a private address space, as in RFC > | 1597/1918, is not JUST to economize on address space. > | Similarly, the use of NATs is not JUST to extend the life > | of a 32-bit address space. > | > | Here's the telling quote from RFC 1627: > | > | ----------- > | The IP version 4 (IPv4) address space will be exhausted. The > | question is simply: when? > | > | If we assert that all IP addresses must be unique > | globally, connected > | or not, then we will run out of IP address space soon. > | > | If we assert that only IP addresses used on the > | world-wide Internet > | need to be globally unique, then we will run out of IP > | address space > | later. > | > | It is absolutely key to keep the Internet community's attention > | focused on the efforts toward IP next generation > | (IPng), so that we > | may transcend the limitations of IPv4. RFC 1597 > | produces apparent > | relief from IPv4 address space exhaustion by masking > | those networks > | that are not connecting to the Internet, today. > | ----------- > | > | RFC 1918 and NATs can also be used to configure small > | networks the same, then avoid renumbering these networks > | when/if they are connected to the Internet. A 1:1 > | relationship between IP addresses on either side of the > | NAT can be implemented. (That is, you're not using the > | Port ID field as a kludgey extension of the IP address field.) > | > | The arguments of RFC 1627 really emphasize the economizing > | of address space as motivation for using the private > | address space. Not always germaine, IMO. But anyway, as > | long as the FECO:: continues to exist, all should work out. > | > | Bert > | _______________________________________________ > | routing-discussion mailing list > | routing-discussion@ietf.org > | https://www1.ietf.org/mailman/listinfo/routing-discussion > | > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Thu Mar 27 01:01:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04881 for ; Thu, 27 Mar 2003 01:01:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R6Mjb08820 for routing-discussion-archive@odin.ietf.org; Thu, 27 Mar 2003 01:22:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R6GeO08529; Thu, 27 Mar 2003 01:16:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONEsO08986 for ; Mon, 24 Mar 2003 18:14:54 -0500 Received: from lakecmmtao01.coxmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07033 for ; Mon, 24 Mar 2003 17:54:22 -0500 (EST) Received: from apocalypse.org ([68.15.42.104]) by lakecmmtao01.coxmail.com (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20030324225641.KRHD25316.lakecmmtao01.coxmail.com@apocalypse.org> for ; Mon, 24 Mar 2003 17:56:41 -0500 Message-ID: <3E7F8C4D.1090900@apocalypse.org> From: avri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: Re: IPv6 site-locals... end of story... References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Mar 2003 14:53:01 -0800 Content-Transfer-Encoding: 7bit While it may not be necessary to economize with IP space in IPv6, there is nothing to prevent a local service provider from creating an artificial shortage that then allows them to charge me for every address I use in my home. Local addressing gives the user, i.e.. our silent majority, some means of fighting those who would make them pay for every address used. I believe that as long as this address monopoly exists, there will be users who will buy any device that gives them address freedom. So, it isn't the end of the story, just the end of a chapter. a. Tony Li wrote: > > > If we need to economize on v6 address space, then it isn't big enough. > > Tony > > > | -----Original Message----- > | From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > | Sent: Monday, March 24, 2003 2:08 PM > | To: routing-discussion@ietf.org > | Subject: RE: IPv6 site-locals... end of story... > | > | > | About RFC 1627 ... > | > | The reasons for using a private address space, as in RFC > | 1597/1918, is not JUST to economize on address space. > | Similarly, the use of NATs is not JUST to extend the life > | of a 32-bit address space. > | > | Here's the telling quote from RFC 1627: > | > | ----------- > | The IP version 4 (IPv4) address space will be exhausted. The > | question is simply: when? > | > | If we assert that all IP addresses must be unique > | globally, connected > | or not, then we will run out of IP address space soon. > | > | If we assert that only IP addresses used on the > | world-wide Internet > | need to be globally unique, then we will run out of IP > | address space > | later. > | > | It is absolutely key to keep the Internet community's attention > | focused on the efforts toward IP next generation > | (IPng), so that we > | may transcend the limitations of IPv4. RFC 1597 > | produces apparent > | relief from IPv4 address space exhaustion by masking > | those networks > | that are not connecting to the Internet, today. > | ----------- > | > | RFC 1918 and NATs can also be used to configure small > | networks the same, then avoid renumbering these networks > | when/if they are connected to the Internet. A 1:1 > | relationship between IP addresses on either side of the > | NAT can be implemented. (That is, you're not using the > | Port ID field as a kludgey extension of the IP address field.) > | > | The arguments of RFC 1627 really emphasize the economizing > | of address space as motivation for using the private > | address space. Not always germaine, IMO. But anyway, as > | long as the FECO:: continues to exist, all should work out. > | > | Bert > | _______________________________________________ > | routing-discussion mailing list > | routing-discussion@ietf.org > | https://www1.ietf.org/mailman/listinfo/routing-discussion > | > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 28 14:40:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14002 for ; Fri, 28 Mar 2003 14:40:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJjuO00573; Fri, 28 Mar 2003 14:45:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJfcO00406 for ; Fri, 28 Mar 2003 14:41:38 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13115 for ; Fri, 28 Mar 2003 14:19:12 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA37319; Thu, 27 Mar 2003 12:10:25 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303271710.MAA37319@workhorse.fictitious.org> To: "Stephen Sprunk" cc: curtis@fictitious.org, "Eliot Lear" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) In-reply-to: Your message of "Wed, 26 Mar 2003 20:14:41 CST." <000001c2f407$8deaf810$93b58742@ssprunk> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Mar 2003 12:10:25 -0500 In message <000001c2f407$8deaf810$93b58742@ssprunk>, "Stephen Sprunk" writes: > > > > Renumbering is supposed to be easy with IPv6. I always found it > > plenty easy enough with IPv4, so I won't comment on whether it is easy > > enough with IPv6. > > Renumbering costs manpower, and businesses do not spend time (aka money) on > projects like that unless there is a financial return. Renumbering is not > free and _it has no business value_. Given that, NATs will win in the real > world no matter how much we work to reduce the absolute cost of renumbering. > > 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 It is true that renumbering cost is not zero. Given the cost of connectivity, the cost to renumber is minimal if IT staff is not too severely challenged (in which case cost of anything can approach infinity). The onging cost of using a NAT is also high because the NAT itself gets in the way of getting things done particularly in a multilocation environment where more than one NAT is needed. We need to agree to disagree. I keep trying to the point that the IETF has made efforts to provide no barriers to renumbering and explicit support for it, and that there is existance proof that renumbering large numbers of hosts can be done quite painlessly. You keep pointing out that the PC software industry and the MIS world repeatedly demonstrates widespread incompetence, and despite providing the capability to renumber and providing advice on good and bad practices, will carry most or all existing IPv4 bad practices through any IPv6 transition and will manage to make it overly difficult to renumber in IPv6. We're both at least partially right because a subset of organizations will update their practices when transitioning to IPv6 and another subset will try to carry existing bad practices to IPv6, and the largest subset will do nothing and continue to run IPv4. It may be perfectly reasonable to allow users to retain NATs and stay with IPv4 or transition to IPv6 topology based (non-portable) addresses. I think it is reasonable and you don't and that is where we need to agree to disagree. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Mar 28 14:41:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14061 for ; Fri, 28 Mar 2003 14:41:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SK2wF01565 for routing-discussion-archive@odin.ietf.org; Fri, 28 Mar 2003 15:02:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJjuO00573; Fri, 28 Mar 2003 14:45:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJfcO00406 for ; Fri, 28 Mar 2003 14:41:38 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13115 for ; Fri, 28 Mar 2003 14:19:12 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA37319; Thu, 27 Mar 2003 12:10:25 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303271710.MAA37319@workhorse.fictitious.org> To: "Stephen Sprunk" cc: curtis@fictitious.org, "Eliot Lear" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) In-reply-to: Your message of "Wed, 26 Mar 2003 20:14:41 CST." <000001c2f407$8deaf810$93b58742@ssprunk> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Mar 2003 12:10:25 -0500 In message <000001c2f407$8deaf810$93b58742@ssprunk>, "Stephen Sprunk" writes: > > > > Renumbering is supposed to be easy with IPv6. I always found it > > plenty easy enough with IPv4, so I won't comment on whether it is easy > > enough with IPv6. > > Renumbering costs manpower, and businesses do not spend time (aka money) on > projects like that unless there is a financial return. Renumbering is not > free and _it has no business value_. Given that, NATs will win in the real > world no matter how much we work to reduce the absolute cost of renumbering. > > 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 It is true that renumbering cost is not zero. Given the cost of connectivity, the cost to renumber is minimal if IT staff is not too severely challenged (in which case cost of anything can approach infinity). The onging cost of using a NAT is also high because the NAT itself gets in the way of getting things done particularly in a multilocation environment where more than one NAT is needed. We need to agree to disagree. I keep trying to the point that the IETF has made efforts to provide no barriers to renumbering and explicit support for it, and that there is existance proof that renumbering large numbers of hosts can be done quite painlessly. You keep pointing out that the PC software industry and the MIS world repeatedly demonstrates widespread incompetence, and despite providing the capability to renumber and providing advice on good and bad practices, will carry most or all existing IPv4 bad practices through any IPv6 transition and will manage to make it overly difficult to renumber in IPv6. We're both at least partially right because a subset of organizations will update their practices when transitioning to IPv6 and another subset will try to carry existing bad practices to IPv6, and the largest subset will do nothing and continue to run IPv4. It may be perfectly reasonable to allow users to retain NATs and stay with IPv4 or transition to IPv6 topology based (non-portable) addresses. I think it is reasonable and you don't and that is where we need to agree to disagree. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 28 14:41:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14091 for ; Fri, 28 Mar 2003 14:41:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJmNO00683; Fri, 28 Mar 2003 14:48:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJffO00413 for ; Fri, 28 Mar 2003 14:41:41 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13118 for ; Fri, 28 Mar 2003 14:19:16 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA37362; Thu, 27 Mar 2003 12:19:01 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303271719.MAA37362@workhorse.fictitious.org> To: "Stephen Sprunk" cc: "David Conrad" , curtis@fictitious.org, "Eliot Lear" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) In-reply-to: Your message of "Wed, 26 Mar 2003 23:02:01 CST." <00d701c2f41f$817076b0$93b58742@ssprunk> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Mar 2003 12:19:01 -0500 In message <00d701c2f41f$817076b0$93b58742@ssprunk>, "Stephen Sprunk" writes: > Thus spake "David Conrad" > > On Wednesday, March 26, 2003, at 06:14 PM, Stephen Sprunk wrote: > > > Much of this would be solved if we'd give portable IPv6 addresses to > > > anyone with a reasonable justification. > > > > Define "reasonable justification". > > > > As you note, scarcity is not the current constraining factor. Swamp > > avoidance is. > > I don't see how we can expect to reduce the tables to less than one prefix > per ASN, so that's a start right there: every ASN comes with a pre-assigned > prefix*. This is how 6bone worked for many years, in fact. > > Beyond that, it's hard to say. I can't think of any examples of companies > with substantial internal networks that don't have an ASN already, but I'm > sure there are some. Given how easy it is to get an ASN, I'm not sure > there's much utility in developing a rule for the no-ASN case. > > * I'd suggest a /48 for AS-based allocations, not to be suballocated to > customers; ISPs would need a second, larger allocation and probably not use > the AS-based one. > > 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 The current situation in IPv4 is that the topology is quite diverse but each provider has a small number of provider aggregates covering the majority of customers and a large number of provider independent (PI) aka portable prefixes that are singly homed. The result is 250,000 global routes where the number of routes could be about two decimal orders of magnitude smaller if all single homed site address space mapped into the topology. That is the situation we are trying to avoid in IPv6 without resorting to NAT to accomplish it. Otherwise we might as well stick with IPv4 and declare IPv6 a failure. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Mar 28 14:42:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14130 for ; Fri, 28 Mar 2003 14:42:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SK4CP01592 for routing-discussion-archive@odin.ietf.org; Fri, 28 Mar 2003 15:04:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJmNO00683; Fri, 28 Mar 2003 14:48:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJffO00413 for ; Fri, 28 Mar 2003 14:41:41 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13118 for ; Fri, 28 Mar 2003 14:19:16 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA37362; Thu, 27 Mar 2003 12:19:01 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303271719.MAA37362@workhorse.fictitious.org> To: "Stephen Sprunk" cc: "David Conrad" , curtis@fictitious.org, "Eliot Lear" , routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: You want Fries with that? (was Re: IPv6 site-locals... end of story) In-reply-to: Your message of "Wed, 26 Mar 2003 23:02:01 CST." <00d701c2f41f$817076b0$93b58742@ssprunk> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Mar 2003 12:19:01 -0500 In message <00d701c2f41f$817076b0$93b58742@ssprunk>, "Stephen Sprunk" writes: > Thus spake "David Conrad" > > On Wednesday, March 26, 2003, at 06:14 PM, Stephen Sprunk wrote: > > > Much of this would be solved if we'd give portable IPv6 addresses to > > > anyone with a reasonable justification. > > > > Define "reasonable justification". > > > > As you note, scarcity is not the current constraining factor. Swamp > > avoidance is. > > I don't see how we can expect to reduce the tables to less than one prefix > per ASN, so that's a start right there: every ASN comes with a pre-assigned > prefix*. This is how 6bone worked for many years, in fact. > > Beyond that, it's hard to say. I can't think of any examples of companies > with substantial internal networks that don't have an ASN already, but I'm > sure there are some. Given how easy it is to get an ASN, I'm not sure > there's much utility in developing a rule for the no-ASN case. > > * I'd suggest a /48 for AS-based allocations, not to be suballocated to > customers; ISPs would need a second, larger allocation and probably not use > the AS-based one. > > 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 The current situation in IPv4 is that the topology is quite diverse but each provider has a small number of provider aggregates covering the majority of customers and a large number of provider independent (PI) aka portable prefixes that are singly homed. The result is 250,000 global routes where the number of routes could be about two decimal orders of magnitude smaller if all single homed site address space mapped into the topology. That is the situation we are trying to avoid in IPv6 without resorting to NAT to accomplish it. Otherwise we might as well stick with IPv4 and declare IPv6 a failure. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Mar 28 14:44:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14183 for ; Fri, 28 Mar 2003 14:44:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJoRO00812; Fri, 28 Mar 2003 14:50:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJfjO00417 for ; Fri, 28 Mar 2003 14:41:45 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13120 for ; Fri, 28 Mar 2003 14:19:19 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA37114; Thu, 27 Mar 2003 10:10:42 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303271510.KAA37114@workhorse.fictitious.org> To: "Stephen Sprunk" cc: "Eliot Lear" , "David Conrad" , curtis@fictitious.org, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: renumbering transition (was Re: whining .. (was: Re: ..site-locals..)) In-reply-to: Your message of "Wed, 26 Mar 2003 19:40:16 CST." <011201c2f403$32f743e0$93b58742@ssprunk> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Mar 2003 10:10:42 -0500 In message <011201c2f403$32f743e0$93b58742@ssprunk>, "Stephen Sprunk" writes: > > Something as serious as changing an IP address can be a 6-12 month project > due to all the testing and validation required. Seems loony, yes, but I've > seen mission-critical servers made inoperable by installing a new printer > driver. Would you bet your job and your pension on renumbering being a > flawless overnight exercise? > > S I fully agree that renumbering should not be expected to be an overnight transition and can take months, even well over a year, depending on the size and administrative entropy of the organization. The purpose of a "renumbering grace period" is to accommodate an address transition is to allow 6-12 months to renumber if that is what an organization needs. Back when RFC1957 was being discussed in the IETF and the idea of address lending discussed I strong advocated that the ISPs agree to provide some minimum grace period for their customers to renumber as a *requirement* for the IPS to get the number space. An organization can have 2 number spaces for a long period of time while parts of the organization under separate administration are notified of the transition and given sufficient time to complete the transition of their systems. Absent this cooperation among ISPs, a customer wishing to switch service providers must contract from two providers during the renumbering transition period. This puts a great deal of pressure on the staff to complete the renumbering in under a month which in many cases is difficult or impossible. If we are to learn from our mistakes, we should not only put a burden on end customers, giving them non-portable addresses, but we must put a burden on the ISPs with manditory minimum renumbering grace periods in order for the ISPs to get address allocations. What the ISPs have to do is punch a temporary hole in their aggregate for the duration of the grace period and accept that advertisement from other providers. This will increase the number of routes but only to the extent that their are unsatisfied customers in the midst of this sort of transition. Failure to provide a manditory renumbering grace period was a major contributor to the trend toward requesting PI addresses and to a lesser extent toward NATs. If these are things we want to avoid in IPv6, we should consider a requirement for manditory renumbering grace period enforced by the address registries. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From mailnull@www1.ietf.org Fri Mar 28 14:44:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14250 for ; Fri, 28 Mar 2003 14:44:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SK6gn01728 for routing-discussion-archive@odin.ietf.org; Fri, 28 Mar 2003 15:06:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJoRO00812; Fri, 28 Mar 2003 14:50:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SJfjO00417 for ; Fri, 28 Mar 2003 14:41:45 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13120 for ; Fri, 28 Mar 2003 14:19:19 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA37114; Thu, 27 Mar 2003 10:10:42 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303271510.KAA37114@workhorse.fictitious.org> To: "Stephen Sprunk" cc: "Eliot Lear" , "David Conrad" , curtis@fictitious.org, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: renumbering transition (was Re: whining .. (was: Re: ..site-locals..)) In-reply-to: Your message of "Wed, 26 Mar 2003 19:40:16 CST." <011201c2f403$32f743e0$93b58742@ssprunk> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Mar 2003 10:10:42 -0500 In message <011201c2f403$32f743e0$93b58742@ssprunk>, "Stephen Sprunk" writes: > > Something as serious as changing an IP address can be a 6-12 month project > due to all the testing and validation required. Seems loony, yes, but I've > seen mission-critical servers made inoperable by installing a new printer > driver. Would you bet your job and your pension on renumbering being a > flawless overnight exercise? > > S I fully agree that renumbering should not be expected to be an overnight transition and can take months, even well over a year, depending on the size and administrative entropy of the organization. The purpose of a "renumbering grace period" is to accommodate an address transition is to allow 6-12 months to renumber if that is what an organization needs. Back when RFC1957 was being discussed in the IETF and the idea of address lending discussed I strong advocated that the ISPs agree to provide some minimum grace period for their customers to renumber as a *requirement* for the IPS to get the number space. An organization can have 2 number spaces for a long period of time while parts of the organization under separate administration are notified of the transition and given sufficient time to complete the transition of their systems. Absent this cooperation among ISPs, a customer wishing to switch service providers must contract from two providers during the renumbering transition period. This puts a great deal of pressure on the staff to complete the renumbering in under a month which in many cases is difficult or impossible. If we are to learn from our mistakes, we should not only put a burden on end customers, giving them non-portable addresses, but we must put a burden on the ISPs with manditory minimum renumbering grace periods in order for the ISPs to get address allocations. What the ISPs have to do is punch a temporary hole in their aggregate for the duration of the grace period and accept that advertisement from other providers. This will increase the number of routes but only to the extent that their are unsatisfied customers in the midst of this sort of transition. Failure to provide a manditory renumbering grace period was a major contributor to the trend toward requesting PI addresses and to a lesser extent toward NATs. If these are things we want to avoid in IPv6, we should consider a requirement for manditory renumbering grace period enforced by the address registries. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion