From owner-multi6@ops.ietf.org Sat Feb 1 01:45:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29982 for ; Sat, 1 Feb 2003 01:45:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18erP9-00087q-00 for multi6-data@psg.com; Fri, 31 Jan 2003 22:45:31 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18erP5-00087d-00 for multi6@ops.ietf.org; Fri, 31 Jan 2003 22:45:28 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h116iFF31285; Sat, 1 Feb 2003 08:44:15 +0200 Date: Sat, 1 Feb 2003 08:44:15 +0200 (EET) From: Pekka Savola To: Michel Py cc: Michael Lambert , Subject: RE: Draft: PI addressing derived from AS numbers In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B97@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 31 Jan 2003, Michel Py wrote: > > Would it make sense to push Pekka's draft along the experimental > > track in the spirit of RFC 1797 (the 39/8 subnet experiment)? > > It may not be an optimal solution, but it would give the > > community some breathing room while better methods are developed. > > I concur with Pekka that sunset provisions are important. > > If a sunset is required, then requesting a "special" 6bone pTLA would be > the way to go. I don't see what that would buy though, and here's the > rationale: Tying this to 6bone is an interesting idea, but the death of 6bone may be too soon.. > The idea behind Pekka's draft is that deployment of IPv6 is being > hindered because organizations that currently have an ASN are waiting > for some kind of PI to deploy. Why are they waiting? Because they don't > want to renumber. Giving these guys a prefix that sunsets does not do > them any good. Note that there are other motivations for multihoming than wanting not to renumber. Renumbering _once_, when the mechanism is retired in 5 years (or whatever) could be entirely acceptable. But what they mainly want, as far as I can see is independence and redundancy; load sharing, performance and policy are just likely secondary objectives (partially because due to more speficic routes not allowed, they may be more difficult to do anyway). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sat Feb 1 12:52:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12554 for ; Sat, 1 Feb 2003 12:52:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18f1nM-000PzA-00 for multi6-data@psg.com; Sat, 01 Feb 2003 09:51:12 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18f1nJ-000Pyy-00 for multi6@ops.ietf.org; Sat, 01 Feb 2003 09:51:10 -0800 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 h11Hp7MY017883; Sat, 1 Feb 2003 12:51:07 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h11Hp6P7017880; Sat, 1 Feb 2003 12:51:07 -0500 Date: Sat, 1 Feb 2003 12:51:07 -0500 From: "J. Noel Chiappa" Message-Id: <200302011751.h11Hp6P7017880@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Draft: PI addressing derived from AS numbers Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Pekka Savola > But what they mainly want, as far as I can see is independence If people wanted a namespace that was independent of topology, they should have put one into the architecture when it was first designed. Routing-names in a global-scale network will *always* depend on network location. The only namespace IPv6 has (other than DNS names) are addresses, which are routing-names. If an architecture without a namespace which is independent of topology in unacceptable, then people have to either i) radically modify IPv6, or ii) junk it. Is a namespace with independence really absolutely required? If so, saying tbat is equivalent to saying you have to either radically modify IPv6 (so it supports that), or junk it (since it doesn't). "We are a lighthouse. Your call." Noel From owner-multi6@ops.ietf.org Sat Feb 1 14:41:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15073 for ; Sat, 1 Feb 2003 14:41:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18f3UJ-0003AR-00 for multi6-data@psg.com; Sat, 01 Feb 2003 11:39:39 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18f3UH-0003AF-00 for multi6@ops.ietf.org; Sat, 01 Feb 2003 11:39:37 -0800 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 h11JdYMY018385; Sat, 1 Feb 2003 14:39:34 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h11JdXI5018382; Sat, 1 Feb 2003 14:39:33 -0500 Date: Sat, 1 Feb 2003 14:39:33 -0500 From: "J. Noel Chiappa" Message-Id: <200302011939.h11JdXI5018382@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Draft: PI addressing derived from AS numbers Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "J. Noel Chiappa" > If an architecture without a namespace which is independent of topology > is unacceptable, then people have to either i) radically modify IPv6, > or ii) junk it. Ah, to make it quite plain what I meant here: by "IPv6" I meant the entire stack, not just the internetwork level protocol; and by "radically modify IPv6" I mean to include schemes like 8+8, 16+16, HIP, etc - a system using one of these is not going to interoperate with one which does not have it (although I dunno about 16+16). Noel From owner-multi6@ops.ietf.org Sat Feb 1 15:23:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15472 for ; Sat, 1 Feb 2003 15:23:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18f4Bz-0004Xh-00 for multi6-data@psg.com; Sat, 01 Feb 2003 12:24:47 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18f4Bv-0004XJ-00 for multi6@ops.ietf.org; Sat, 01 Feb 2003 12:24:44 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h11KOQJ02633; Sat, 1 Feb 2003 22:24:26 +0200 Date: Sat, 1 Feb 2003 22:24:25 +0200 (EET) From: Pekka Savola To: "J. Noel Chiappa" cc: multi6@ops.ietf.org Subject: RE: Draft: PI addressing derived from AS numbers In-Reply-To: <200302011751.h11Hp6P7017880@ginger.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 1 Feb 2003, J. Noel Chiappa wrote: > > From: Pekka Savola > > > But what they mainly want, as far as I can see is independence > > If people wanted a namespace that was independent of topology, they should > have put one into the architecture when it was first designed. > > Routing-names in a global-scale network will *always* depend on network > location. > > The only namespace IPv6 has (other than DNS names) are addresses, which are > routing-names. > > If an architecture without a namespace which is independent of topology in > unacceptable, then people have to either i) radically modify IPv6, or ii) > junk it. > > Is a namespace with independence really absolutely required? If so, saying > tbat is equivalent to saying you have to either radically modify IPv6 (so > it supports that), or junk it (since it doesn't). In the long term, i'm rather convinced that an architectural change will be required. I can't see other scalable alternatives. But it's not all-or-nothing. Current common practises require independence already -- at "largish ISP" level. This is deemed acceptable, in contrast to late aggregatable global unicast addressing (RFC2374) with hard limits. So, independence is OK to some degree.. but we must not get that degree get too far unless we have measures to provide for it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sat Feb 1 19:01:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17746 for ; Sat, 1 Feb 2003 19:01:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18f7Xk-000D2K-00 for multi6-data@psg.com; Sat, 01 Feb 2003 15:59:28 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18f7Xg-000D1d-00 for multi6@ops.ietf.org; Sat, 01 Feb 2003 15:59:24 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18f7Xd-0004dg-00; Sat, 01 Feb 2003 15:59:22 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pekka Savola Cc: multi6@ops.ietf.org Subject: RE: Draft: PI addressing derived from AS numbers References: <200302011751.h11Hp6P7017880@ginger.lcs.mit.edu> Message-Id: Date: Sat, 01 Feb 2003 15:59:22 -0800 X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In the long term, i'm rather convinced that an architectural change will > be required. I can't see other scalable alternatives. this is also what i see, though i am anxiously awaiting enlightenment. randy From owner-multi6@ops.ietf.org Sun Feb 2 02:38:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02664 for ; Sun, 2 Feb 2003 02:38:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fEhu-0008Mf-00 for multi6-data@psg.com; Sat, 01 Feb 2003 23:38:26 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18fEhq-0008Lz-00; Sat, 01 Feb 2003 23:38:23 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h127cGa12956; Sun, 2 Feb 2003 09:38:17 +0200 Date: Sun, 2 Feb 2003 09:38:16 +0200 (EET) From: Pekka Savola To: Randy Bush cc: multi6@ops.ietf.org Subject: RE: Draft: PI addressing derived from AS numbers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 1 Feb 2003, Randy Bush wrote: > > In the long term, i'm rather convinced that an architectural change will > > be required. I can't see other scalable alternatives. > > this is also what i see, though i am anxiously awaiting enlightenment. Well, speaking of enlightenment, I've had a few ideas lately. I'm pretty sure someone has thought along the same lines at some point, but here goes anyway. The current multihoming practises seem to have an impact on the global routing table on two different axels: 1) the absolute number of routes 2) the number of changes in the routing tables due to the large number of routes, required processing and update propagation etc. For example, consider (in future) 10,000 routes coming behind a next-to-the-origin-AS ISP. If something bad happens to the ISP, all 10,000 routes will be withdrawn, and a secondary path will be selected (perhaps 3,000 will go to ISP X, 3,000 will go to ISP Y, and 4,000 go nowhere, simplifying). The absolute numbers _might_ be manageable if changes were manageable: I'm fairly certain of that at least to the degree of O(10^6) -- memory is cheap. A way to make changes manageable could be to change how BGP works with regard to nested routes from multiple sources. Or really, devise another protocol. Here's a raw thought: When BGP is used for multihoming, all the paths are advertised throughout, not only the current best paths. There has to be a marking on which ones aren't the best paths of course. When a transit AS becomes unreachable, instead of withdrawing the routes and waiting for updates, the only thing that is signalled is "ASX went down, switch to alternative path(s) if any". So, changes would not be processed per prefix, but mainly per (transit) AS, in an "aggregated" fashion. In that way, convergence could be near-instantaneuous and the amount of processing for BGP updates (at the cost of about N extra routes in RIB) needed when multihoming minimal. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sun Feb 2 07:31:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04995 for ; Sun, 2 Feb 2003 07:31:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fJI0-000FAp-00 for multi6-data@psg.com; Sun, 02 Feb 2003 04:32:00 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18fJHx-000FAd-00 for multi6@ops.ietf.org; Sun, 02 Feb 2003 04:31:58 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h12CVF477034; Sun, 2 Feb 2003 13:31:15 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 2 Feb 2003 13:31:15 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Savola cc: Subject: RE: Draft: PI addressing derived from AS numbers In-Reply-To: Message-ID: <20030202130528.X61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 2 Feb 2003, Pekka Savola wrote: > For example, consider (in future) 10,000 routes coming behind a > next-to-the-origin-AS ISP. If something bad happens to the ISP, all > 10,000 routes will be withdrawn, and a secondary path will be selected > (perhaps 3,000 will go to ISP X, 3,000 will go to ISP Y, and 4,000 go > nowhere, simplifying). > The absolute numbers _might_ be manageable if changes were manageable: I'm > fairly certain of that at least to the degree of O(10^6) -- memory is > cheap. I assume you mean 10^6 number of routes? Cisco's CEF seems to take something like 300 bytes for a single route. That makes for 300 MB worth of fowarding tables, which wouldn't stress current technology too much. BGP and routing table entries also seem to be something like 300 bytes each, so for the main route processor the amount of memory could be somewhat more problematic. But 4 copies of each route in the BGP table + 1 in the routing table would make for 1500 MB, also still doable. > A way to make changes manageable could be to change how BGP works with > regard to nested routes from multiple sources. Or really, devise another > protocol. Here's a raw thought: > When BGP is used for multihoming, all the paths are advertised throughout, > not only the current best paths. There has to be a marking on which ones > aren't the best paths of course. When a transit AS becomes unreachable, > instead of withdrawing the routes and waiting for updates, the only thing > that is signalled is "ASX went down, switch to alternative path(s) if > any". So, changes would not be processed per prefix, but mainly per > (transit) AS, in an "aggregated" fashion. In that way, convergence could > be near-instantaneuous and the amount of processing for BGP updates (at > the cost of about N extra routes in RIB) needed when multihoming minimal. We can do better than that. A new interdomain routing protocol should separate the topology information from the NLRI. The AS <-> prefix mapping can then be nearly static. Note that this would also be very helpful in addressing the security concerns that currently exist about BGP. It would be logical to make such an idr protocol a link state protocol, but I'm not sure if it is possible to make a link state routing protocol that can function even if the full state of the network isn't always completely known. Essentially, you'd want to know the state of what's going on close to your AS in great detail, but more and more information should be aggegated away as the distance increases. Of course this aggregation should be based on geography for multihomers. :-) From owner-multi6@ops.ietf.org Sun Feb 2 12:20:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09061 for ; Sun, 2 Feb 2003 12:20:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fNmd-000M68-00 for multi6-data@psg.com; Sun, 02 Feb 2003 09:19:55 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18fNmZ-000M5v-00 for multi6@ops.ietf.org; Sun, 02 Feb 2003 09:19:52 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h12HJmN15664 for ; Sun, 2 Feb 2003 19:19:48 +0200 Date: Sun, 2 Feb 2003 19:19:47 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: "architectural change" [RE: Draft: PI addressing derived from AS numbers] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 1 Feb 2003, Randy Bush wrote: > > In the long term, i'm rather convinced that an architectural change will > > be required. I can't see other scalable alternatives. > > this is also what i see, though i am anxiously awaiting enlightenment. Perhaps it was not clear what I meant with an "architectural change", and I should try to clarify. I didn't mean we need IPv7; rather, that the model of solving a problem of locator/identifier problem and dumb end-hosts with a global routing solution. For example, I consider models where multihomed hosts make a much more active role in the current "multihoming routing" problem an architectural change, as well as separating identifiers and locators as in LIN6 (or even more so, HIP), etc. as architectural changes. Certainly, there are ways to do multihoming with IPv6 today. And there will be ways. But one point many, myself included, have tried to make is that doing it the way most have done it with IPv4 -- that is using BGP with "PI addresses" -- is not scalable. That is likely the only solution for a long time to satisfy all those requirements. For example, I personally have great faith in "multiple addresses from multiple providers" -approach (though there are some small ways it will have to be improved): it should give a sufficient amount of multihoming to most sites. Also, multiple connections to a single ISP are also a way to get redundancy. The major things I see missing are: - ways to get upstream _independence_ - scalable ways to protect against your upstream ISP failures (if multiple addresses per node approach is not sufficient) .. but I'm not sure whether solutions for these are really even required: people just want them because they've always had them. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sun Feb 2 12:31:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09248 for ; Sun, 2 Feb 2003 12:31:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fNzN-000MLr-00 for multi6-data@psg.com; Sun, 02 Feb 2003 09:33:05 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #1) id 18fNzK-000MLT-00 for multi6@ops.ietf.org; Sun, 02 Feb 2003 09:33:02 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 2 Feb 2003 09:28:26 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 02 Feb 2003 09:28:26 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 2 Feb 2003 09:28:26 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 2 Feb 2003 09:28:26 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Sun, 2 Feb 2003 09:28:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Draft: PI addressing derived from AS numbers Date: Sun, 2 Feb 2003 09:28:24 -0800 Message-ID: Thread-Topic: Draft: PI addressing derived from AS numbers thread-index: AcLKK7IzW1yixMPsTqegulGGrHgcagAsgYm/ From: "Christian Huitema" To: "J. Noel Chiappa" , Cc: X-OriginalArrivalTime: 02 Feb 2003 17:28:25.0941 (UTC) FILETIME=[7E401850:01C2CAE0] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09248 > > If an architecture without a namespace which is independent of topology > > is unacceptable, then people have to either i) radically modify IPv6, > > or ii) junk it. > > Ah, to make it quite plain what I meant here: by "IPv6" I meant the entire > stack, not just the internetwork level protocol; and by "radically modify > IPv6" I mean to include schemes like 8+8, 16+16, HIP, etc - a system using > one of these is not going to interoperate with one which does not have it > (although I dunno about 16+16). You are quite right to point out that this is a global stack issue, not necessarily an IP layer issue. A number of the locality independence attributes could be achieved by having a name service independent of the IP layer. Indeed, a number of these attributes are achieved today with the DNS, and more could be obtained if we had a system that was "faster, better" than DNS. A big problem with solutions like 16+16 is that they place the name resolution service in the IP layer, and thus make it practically impossible to change later. The current architecture allows cooperating nodes or sites to pick a different name resolution system, which may have different trade-offs than the DNS. Indeed, the DNS was only introduced in 1988, and there are currently many experiments with various peer-to-peer schemes. Many of what we call addressing issue are really transport level issues, using an address to identify a transport association, or management issues, using an address rather than a name in access control lists. I would argue that if we wanted to resolve these issues, we could: Mobile IP technology can be used to solve the transport issue; IP security can be used to associate actual credentials to addresses and then perform access control based on these credentials. -- Christian Huitema -- Christian Huitema From owner-multi6@ops.ietf.org Sun Feb 2 12:59:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09659 for ; Sun, 2 Feb 2003 12:59:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fOPX-000Muc-00 for multi6-data@psg.com; Sun, 02 Feb 2003 10:00:07 -0800 Received: from vador.skynet.be ([195.238.3.236]) by psg.com with esmtp (Exim 3.36 #1) id 18fOPV-000MuC-00 for multi6@ops.ietf.org; Sun, 02 Feb 2003 10:00:05 -0800 Received: from tsn (230.179-200-80.adsl.skynet.be [80.200.179.230]) by vador.skynet.be (8.12.7/8.12.7/Skynet-OUT-2.21) with ESMTP id h12HxuPT009850 for ; Sun, 2 Feb 2003 18:59:56 +0100 (MET) (envelope-from ) Message-Id: <200302021759.h12HxuPT009850@vador.skynet.be> From: "Mario Goebbels" To: Subject: PI addressing and routing tables Date: Sun, 2 Feb 2003 18:59:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 11.0.4523 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3718.0 X-Spam-Status: No, hits=2.4 required=5.0 tests=RCVD_IN_MULTIHOP_DSBL,RCVD_IN_UNCONFIRMED_DSBL, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm not a specialist in routing technologies, but would keeping two (virtual) routing tables maybe improve the performance a bit? This could maybe be achieved by allocating PI addresses using another FP? So normal PA routes would go in the primary table, and all PI routes in a secondary table. Personally I think it's sad that the Internets performance and future is threatened by business stuff. Thanks for any feedback. -mg From owner-multi6@ops.ietf.org Sun Feb 2 19:39:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14141 for ; Sun, 2 Feb 2003 19:39:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fUcj-0007aE-00 for multi6-data@psg.com; Sun, 02 Feb 2003 16:38:09 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18fUcd-0007a2-00 for multi6@ops.ietf.org; Sun, 02 Feb 2003 16:38:04 -0800 Subject: RE: Draft: PI addressing derived from AS numbers Date: Sun, 2 Feb 2003 16:38:01 -0800 Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BA5@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Thread-Topic: Draft: PI addressing derived from AS numbers Content-class: urn:content-classes:message Thread-Index: AcLJvVeiZb6UjtXdRV6QrhQ/uxTBlgBXiKCQ From: "Michel Py" X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 To: "Pekka Savola" Cc: X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA14141 Pekka, >> Michel Py wrote: >> If a sunset is required, then requesting a "special" 6bone pTLA >> would be the way to go. > Pekka Savola wrote: > Tying this to 6bone is an interesting idea, but the death of > bone may be too soon.. Which is why I am on the side that says the 6bone beginning to shut down in 2004 is too early. If it is an experiment and/or needs a sunset, why would NOT it be in the 6bone? > Note that there are other motivations for multihoming than > wanting not to renumber. Of course. > Renumbering _once_, when the mechanism is retired in 5 years > (or whatever) could be entirely acceptable. I am not convinced. If part of the 6bone, then there are reasonable guarantees that the prefix would indeed be withdrawn. If this was to be a one-of-a-kind thing, you can be sure that the people that were all for a sunset will sing another song 5 years later facing renumbering and will strongly lobby to transform the temporary allocation into a permanent one. In other words, I'm all for it if it's part of the 6bone, otherwise I'll fight it because it will be impossible to sunset. Michel. From owner-multi6@ops.ietf.org Mon Feb 3 10:32:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10484 for ; Mon, 3 Feb 2003 10:32:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fia6-000BuW-00 for multi6-data@psg.com; Mon, 03 Feb 2003 07:32:22 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 18fia2-000BuB-00 for multi6@ops.ietf.org; Mon, 03 Feb 2003 07:32:18 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h13FWBbt036328 for ; Mon, 3 Feb 2003 16:32:11 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h13FUrJ3023972 for ; Mon, 3 Feb 2003 16:30:54 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA22668 from ; Mon, 3 Feb 2003 16:30:52 +0100 Message-Id: <3E3E8AFE.27B2C585@hursley.ibm.com> Date: Mon, 03 Feb 2003 16:30:06 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers References: <963621801C6D3E4A9CF454A1972AE8F54B9A@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Py wrote: > > > Michael Richardson wrote: > > The AS proposal certainly results in a much smaller DFZ than if > > we handed every holder of PI IPv4 space PI space in IPv6. > > Absolutely, the point I was making is not that it would be bigger, as I > do like the idea, but that it would likely not be possible to stick to > it: If we give PI to ASN holders, you can be sure that the lobbying of > swamp space holders to get the same thing is going to be a freight train > that nobody will be able to stop. Let's do a little thought experiment. Everybody who has an AS has at least one globally routeable IPv4 address. So they already have an IPv6 prefix from RFC 3056. It's only a /48, but they have one of those for every IPv4 address they own, so that's fine. Hmm, now they can just announce those /48 prefixes for their AS; problem solved without Pekka's document. Hmmm, now anyone who is in the IPv4 swamp can do the same thing, even without an AS number. Hmmmm, now we have imported the entire IPv4 DFZ into the IPv6 DFZ. Exactly what the rules in RFC 3056 say is forbidden, but they can't be enforced. The point of the thought experiment is that this would also happen with Pekka's proposal, I suspect. If we don't invent a good alternative to importing the swamp, we'll end up importing it. Brian From owner-multi6@ops.ietf.org Mon Feb 3 10:39:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10662 for ; Mon, 3 Feb 2003 10:39:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fijF-000CBf-00 for multi6-data@psg.com; Mon, 03 Feb 2003 07:41:49 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 18fijA-000CB6-00 for multi6@ops.ietf.org; Mon, 03 Feb 2003 07:41:44 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h13FfPH3055214; Mon, 3 Feb 2003 16:41:26 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h13FfOAl211548; Mon, 3 Feb 2003 16:41:24 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54052 from ; Mon, 3 Feb 2003 16:41:23 +0100 Message-Id: <3E3E8D74.C8CDAC94@hursley.ibm.com> Date: Mon, 03 Feb 2003 16:40:36 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Christian Huitema Cc: "J. Noel Chiappa" , multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.2 required=5.0 tests=NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01,SUPERLONG_LINE, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I feel that the challenge is actually not in the Internet Protocol address at all. IPv6 *unmodified* is entirely capable of supporting a namespace independent of topology; that needs a relatively simple IANA action plus a rather boring registry to run. The architectural issue is elsewhere - in routing, DNS, or as Christian says in transport. I also suspect that several of the alternatives can perfectly coexist with RFC 2460 (current IPv6) so I don't think that we are facing such a steep cliff as Noel implies. But that is a very detailed question. Brian Christian Huitema wrote: > > > > If an architecture without a namespace which is independent of topology > > > is unacceptable, then people have to either i) radically modify IPv6, > > > or ii) junk it. > > > > Ah, to make it quite plain what I meant here: by "IPv6" I meant the entire > > stack, not just the internetwork level protocol; and by "radically modify > > IPv6" I mean to include schemes like 8+8, 16+16, HIP, etc - a system using > > one of these is not going to interoperate with one which does not have it > > (although I dunno about 16+16). > > You are quite right to point out that this is a global stack issue, not necessarily an IP layer issue. A number of the locality independence attributes could be achieved by having a name service independent of the IP layer. Indeed, a number of these attributes are achieved today with the DNS, and more could be obtained if we had a system that was "faster, better" than DNS. > > A big problem with solutions like 16+16 is that they place the name resolution service in the IP layer, and thus make it practically impossible to change later. The current architecture allows cooperating nodes or sites to pick a different name resolution system, which may have different trade-offs than the DNS. Indeed, the DNS was only introduced in 1988, and there are currently many experiments with various peer-to-peer schemes. > > Many of what we call addressing issue are really transport level issues, using an address to identify a transport association, or management issues, using an address rather than a name in access control lists. I would argue that if we wanted to resolve these issues, we could: Mobile IP technology can be used to solve the transport issue; IP security can be used to associate actual credentials to addresses and then perform access control based on these credentials. > > -- Christian Huitema From owner-multi6@ops.ietf.org Mon Feb 3 10:47:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10962 for ; Mon, 3 Feb 2003 10:47:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fiq3-000CPb-00 for multi6-data@psg.com; Mon, 03 Feb 2003 07:48:51 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 18fipy-000COb-00 for multi6@ops.ietf.org; Mon, 03 Feb 2003 07:48:48 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h13FmTbt037040; Mon, 3 Feb 2003 16:48:31 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h13FmSJ3155548; Mon, 3 Feb 2003 16:48:29 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA19156 from ; Mon, 3 Feb 2003 16:48:28 +0100 Message-Id: <3E3E8F1D.C5F3D99D@hursley.ibm.com> Date: Mon, 03 Feb 2003 16:47:41 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: multi6@ops.ietf.org Subject: Re: "architectural change" [RE: Draft: PI addressing derived from ASnumbers] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit OK, maybe we need IPv6++ (although as Christian's message points out, the changes mainly wouldn't be in IPv6 itself). But that is R&D, and it will be some years before it ships in product. Over here, can we get on with something shorter term? What is an I6SP supposed to say to a customer who asks for IPv6 multihoming next week? Brian Pekka Savola wrote: > > On Sat, 1 Feb 2003, Randy Bush wrote: > > > In the long term, i'm rather convinced that an architectural change will > > > be required. I can't see other scalable alternatives. > > > > this is also what i see, though i am anxiously awaiting enlightenment. > > Perhaps it was not clear what I meant with an "architectural change", and > I should try to clarify. > > I didn't mean we need IPv7; rather, that the model of solving a problem of > locator/identifier problem and dumb end-hosts with a global routing > solution. > > For example, I consider models where multihomed hosts make a much more > active role in the current "multihoming routing" problem an architectural > change, as well as separating identifiers and locators as in LIN6 (or even > more so, HIP), etc. as architectural changes. > > Certainly, there are ways to do multihoming with IPv6 today. And there > will be ways. But one point many, myself included, have tried to make is > that doing it the way most have done it with IPv4 -- that is using BGP > with "PI addresses" -- is not scalable. That is likely the only solution > for a long time to satisfy all those requirements. > > For example, I personally have great faith in "multiple addresses from > multiple providers" -approach (though there are some small ways it will > have to be improved): it should give a sufficient amount of multihoming to > most sites. Also, multiple connections to a single ISP are also a way to > get redundancy. > > The major things I see missing are: > - ways to get upstream _independence_ > - scalable ways to protect against your upstream ISP failures (if > multiple addresses per node approach is not sufficient) > > .. but I'm not sure whether solutions for these are really even required: > people just want them because they've always had them. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Feb 3 10:54:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11149 for ; Mon, 3 Feb 2003 10:54:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fixJ-000Cdt-00 for multi6-data@psg.com; Mon, 03 Feb 2003 07:56:21 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18fixG-000Cdf-00 for multi6@ops.ietf.org; Mon, 03 Feb 2003 07:56:18 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h13FtaT79348; Mon, 3 Feb 2003 16:55:36 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 3 Feb 2003 16:55:36 +0100 (CET) From: Iljitsch van Beijnum To: Brian E Carpenter cc: Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: <3E3E8AFE.27B2C585@hursley.ibm.com> Message-ID: <20030203164946.V61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 3 Feb 2003, Brian E Carpenter wrote: > The point of the thought experiment is that this would also happen > with Pekka's proposal, I suspect. If we don't invent a good > alternative to importing the swamp, we'll end up importing it. Inventing is not the problem. At some point, we need to start adopting some inventions. From owner-multi6@ops.ietf.org Mon Feb 3 10:55:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11177 for ; Mon, 3 Feb 2003 10:55:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fiyD-000CfT-00 for multi6-data@psg.com; Mon, 03 Feb 2003 07:57:17 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18fiy9-000CfD-00 for multi6@ops.ietf.org; Mon, 03 Feb 2003 07:57:14 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h13Fv6B22908; Mon, 3 Feb 2003 17:57:06 +0200 Date: Mon, 3 Feb 2003 17:57:06 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: multi6@ops.ietf.org Subject: Re: "architectural change" [RE: Draft: PI addressing derived from ASnumbers] In-Reply-To: <3E3E8F1D.C5F3D99D@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_05_08,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 3 Feb 2003, Brian E Carpenter wrote: > Over here, can we get on with something shorter term? What is an I6SP > supposed to say to a customer who asks for IPv6 multihoming next week? Ask the customer what he really wants. Really. If the customer wants redundancy, use multiconnecting to connect him to two of the ISP's PoP's. Problem (99%) solved. If the customer wants independence, advise them to use multiple addresses. (This needs a bit tuning yet.) RFC3178 will also help you there, if you want a more complicated setup. If the customer wants both short-lived redundancy and independence, do both of the above. Note that you really don't want to try to solve short-lived redundancy problems with multiple addresses, it's just way too painful. That should cope with most customers' needs. With some roadmap like this, we could actually get some solutions out of the door, I think. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Feb 3 12:24:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14043 for ; Mon, 3 Feb 2003 12:24:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fkLY-000FZq-00 for multi6-data@psg.com; Mon, 03 Feb 2003 09:25:28 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18fkLK-000FZO-00 for multi6@ops.ietf.org; Mon, 03 Feb 2003 09:25:14 -0800 Subject: RE: Draft: PI addressing derived from AS numbers Date: Mon, 3 Feb 2003 09:25:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BA8@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLLmznP9bTb95gPRiarVZcqjgd5PgACjPrQ From: "Michel Py" To: "Brian Carpenter" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14043 > Brian E Carpenter wrote: > Hmmm, now anyone who is in the IPv4 swamp can do the same > thing, even without an AS number. > Hmmmm, now we have imported the entire IPv4 DFZ into the > IPv6 DFZ. > Exactly what the rules in RFC 3056 say is forbidden, but > they can't be enforced. > The point of the thought experiment is that this would > also happen with Pekka's proposal, I suspect. If we don't > invent a good alternative to importing the swamp, we'll > end up importing it. Exactly, but that's not the worst part. Let's continue the thought experiment. Hmmmm, I'm a newcomer but that should not limit me so I want the same stuff as the old-timers, and now we have 100 million /48s in the global routing table and we're in deep doodoo. Michel. From owner-multi6@ops.ietf.org Mon Feb 3 13:25:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16116 for ; Mon, 3 Feb 2003 13:25:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18flGs-000Hdx-00 for multi6-data@psg.com; Mon, 03 Feb 2003 10:24:42 -0800 Received: from [63.125.5.183] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18flGp-000Hdi-00 for multi6@ops.ietf.org; Mon, 03 Feb 2003 10:24:39 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18flGm-00009V-00; Mon, 03 Feb 2003 13:24:36 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian E Carpenter Cc: Pekka Savola , multi6@ops.ietf.org Subject: Re: "architectural change" [RE: Draft: PI addressing derived from ASnumbers] References: <3E3E8F1D.C5F3D99D@hursley.ibm.com> Message-Id: Date: Mon, 03 Feb 2003 13:24:36 -0500 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > But that is R&D, and it will be some years before it ships in product. > Over here, can we get on with something shorter term? What is an I6SP > supposed to say to a customer who asks for IPv6 multihoming next week? ipv4 style From owner-multi6@ops.ietf.org Mon Feb 3 13:28:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16250 for ; Mon, 3 Feb 2003 13:28:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18flKc-000HpP-00 for multi6-data@psg.com; Mon, 03 Feb 2003 10:28:34 -0800 Received: from [63.125.5.183] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18flKa-000HpA-00; Mon, 03 Feb 2003 10:28:32 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18flKa-00009u-00; Mon, 03 Feb 2003 13:28:32 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian E Carpenter Cc: Pekka Savola , multi6@ops.ietf.org Subject: Re: "architectural change" [RE: Draft: PI addressing derived from ASnumbers] References: <3E3E8F1D.C5F3D99D@hursley.ibm.com> Message-Id: Date: Mon, 03 Feb 2003 13:28:32 -0500 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > But that is R&D, and it will be some years before it ships in product. > Over here, can we get on with something shorter term? What is an I6SP > supposed to say to a customer who asks for IPv6 multihoming next week? ipv4 style From owner-multi6@ops.ietf.org Mon Feb 3 13:31:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16367 for ; Mon, 3 Feb 2003 13:31:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18flNn-000Hxu-00 for multi6-data@psg.com; Mon, 03 Feb 2003 10:31:51 -0800 Received: from riker.skynet.be ([195.238.3.89]) by psg.com with esmtp (Exim 3.36 #1) id 18flNk-000Hxf-00 for multi6@ops.ietf.org; Mon, 03 Feb 2003 10:31:48 -0800 Received: from ZAWMPCJC05 ([212.166.47.10]) by riker.skynet.be (8.12.7/8.12.7/Skynet-OUT-2.21) with SMTP id h13IVV2n024114; Mon, 3 Feb 2003 19:31:32 +0100 (MET) (envelope-from ) Message-ID: <000c01c2cbb2$658000a0$6901a8c0@ZAWMPCJC05> From: "Mario Goebbels" To: "Brian E Carpenter" , "Pekka Savola" Cc: References: <3E3E8F1D.C5F3D99D@hursley.ibm.com> Subject: Re: "architectural change" [RE: Draft: PI addressing derived from ASnumbers] Date: Mon, 3 Feb 2003 19:30:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_OE version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have some general ideas about how someone could able routing -from/to PI networks over the regular IPv6 network, using some additional logical data structure (I tagged it Locator Cache in my idea), some extension header and requires exchange of PI network information over some routing protocol to fill that Locator Cache on routers. Clients are also supposed to make use of that locator cache too in my idea. Due the fact I'm no expert the idea might be pretty general, but maybe some aspects in it are worth a dime. If you don't mind, I could write it down in some human readable form and post it onto this mailing list. -mg > OK, maybe we need IPv6++ (although as Christian's message points > out, the changes mainly wouldn't be in IPv6 itself). > > But that is R&D, and it will be some years before it ships in product. > Over here, can we get on with something shorter term? What is an I6SP > supposed to say to a customer who asks for IPv6 multihoming next week? > > Brian > > Pekka Savola wrote: > > > > On Sat, 1 Feb 2003, Randy Bush wrote: > > > > In the long term, i'm rather convinced that an architectural change will > > > > be required. I can't see other scalable alternatives. > > > > > > this is also what i see, though i am anxiously awaiting enlightenment. > > > > Perhaps it was not clear what I meant with an "architectural change", and > > I should try to clarify. > > > > I didn't mean we need IPv7; rather, that the model of solving a problem of > > locator/identifier problem and dumb end-hosts with a global routing > > solution. > > > > For example, I consider models where multihomed hosts make a much more > > active role in the current "multihoming routing" problem an architectural > > change, as well as separating identifiers and locators as in LIN6 (or even > > more so, HIP), etc. as architectural changes. > > > > Certainly, there are ways to do multihoming with IPv6 today. And there > > will be ways. But one point many, myself included, have tried to make is > > that doing it the way most have done it with IPv4 -- that is using BGP > > with "PI addresses" -- is not scalable. That is likely the only solution > > for a long time to satisfy all those requirements. > > > > For example, I personally have great faith in "multiple addresses from > > multiple providers" -approach (though there are some small ways it will > > have to be improved): it should give a sufficient amount of multihoming to > > most sites. Also, multiple connections to a single ISP are also a way to > > get redundancy. > > > > The major things I see missing are: > > - ways to get upstream _independence_ > > - scalable ways to protect against your upstream ISP failures (if > > multiple addresses per node approach is not sufficient) > > > > .. but I'm not sure whether solutions for these are really even required: > > people just want them because they've always had them. From owner-multi6@ops.ietf.org Mon Feb 3 13:48:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17083 for ; Mon, 3 Feb 2003 13:48:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18flfk-000IpC-00 for multi6-data@psg.com; Mon, 03 Feb 2003 10:50:24 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18flfd-000IoH-00; Mon, 03 Feb 2003 10:50:18 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h13IoEb24222; Mon, 3 Feb 2003 20:50:14 +0200 Date: Mon, 3 Feb 2003 20:50:13 +0200 (EET) From: Pekka Savola To: Randy Bush cc: Brian E Carpenter , Subject: Re: "architectural change" [RE: Draft: PI addressing derived from ASnumbers] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 3 Feb 2003, Randy Bush wrote: > > But that is R&D, and it will be some years before it ships in product. > > Over here, can we get on with something shorter term? What is an I6SP > > supposed to say to a customer who asks for IPv6 multihoming next week? > > ipv4 style did you mean: ipv4 ? Seems like a good suggestion to me ! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Feb 3 20:01:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26366 for ; Mon, 3 Feb 2003 20:01:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18frTI-0009Up-00 for multi6-data@psg.com; Mon, 03 Feb 2003 17:01:56 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18frTE-0009Uc-00 for multi6@ops.ietf.org; Mon, 03 Feb 2003 17:01:53 -0800 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 h1411oMY002737; Mon, 3 Feb 2003 20:01:50 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1411nap002734; Mon, 3 Feb 2003 20:01:49 -0500 Date: Mon, 3 Feb 2003 20:01:49 -0500 From: "J. Noel Chiappa" Message-Id: <200302040101.h1411nap002734@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: "architectural change" [RE: Draft: PI addressing derived from ASnumbers] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Pekka Savola >>> What is an I6SP supposed to say to a customer who asks for IPv6 >>> multihoming next week? >> ipv4 style > did you mean: > ipv4 > Seems like a good suggestion to me ! You know, I was gonna say something like that, but I decided it would be mean. Sigh... Noel From owner-multi6@ops.ietf.org Mon Feb 3 20:13:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26525 for ; Mon, 3 Feb 2003 20:13:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18frgQ-000A90-00 for multi6-data@psg.com; Mon, 03 Feb 2003 17:15:30 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18frgO-000A8N-00 for multi6@ops.ietf.org; Mon, 03 Feb 2003 17:15:28 -0800 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 h141FPMY002927; Mon, 3 Feb 2003 20:15:25 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h141FOXC002924; Mon, 3 Feb 2003 20:15:24 -0500 Date: Mon, 3 Feb 2003 20:15:24 -0500 From: "J. Noel Chiappa" Message-Id: <200302040115.h141FOXC002924@ginger.lcs.mit.edu> To: brian@hursley.ibm.com, multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter > I feel that the challenge is actually not in the Internet Protocol > address at all. IPv6 *unmodified* is entirely capable of supporting a > namespace independent of topology Syntax != Semantics. Just because you have a single namespace that you can allocate both "where" and "who" names from doesn't mean you're done. Unless you start using multiple headers (which is sort of already specified, which is why I like 16+16, although it has all the obvious "source routing" security bugs), there's only a single IPv6 address field in "IPv6 *unmodified*", so it's kind of hard to do both with one field. Noel From owner-multi6@ops.ietf.org Tue Feb 4 03:15:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13681 for ; Tue, 4 Feb 2003 03:15:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fyEo-0004WK-00 for multi6-data@psg.com; Tue, 04 Feb 2003 00:15:26 -0800 Received: from pop-ls-09-1-dialup-179.freesurf.ch ([194.230.235.179] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18fyEk-0004W8-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 00:15:23 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h148GGhE022968; Tue, 4 Feb 2003 09:16:18 +0100 (CET) Date: Mon, 3 Feb 2003 17:29:52 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.7 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I've sent a short draft (7 pages) to Internet-Drafts for publication. Which I have not yet read but will do in a short while. > I propose an automatic allocation of /48, /40 or /32 (based on how the > community feels) of PI addresses if you have an AS number. > > A 16-bit AS number in the range 1 - 2^15, that is. This is just to > enable > IPv6 multihoming temporarily, until another mechanism is devised, to > those > end-sites that already do it today. This is kind of a "stop those lame > excuses now, please" -solution. Just on the brief description here I like the idea. This would require my draft of allowing longer prefixes as well though. Perhaps merging the two is a good idea. > > Note: personally, I think ASN-PI like this is not a good idea, but > it's at > least better than some others, like breaking aggregates or doing stuff > like that -- this is controlled, after a fashion. Agreed. - kurtis - From owner-multi6@ops.ietf.org Tue Feb 4 03:15:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13695 for ; Tue, 4 Feb 2003 03:15:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fyFI-0004XI-00 for multi6-data@psg.com; Tue, 04 Feb 2003 00:15:56 -0800 Received: from pop-ls-09-1-dialup-179.freesurf.ch ([194.230.235.179] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18fyFE-0004Ww-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 00:15:53 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h148GYhE022983; Tue, 4 Feb 2003 09:16:36 +0100 (CET) Date: Tue, 4 Feb 2003 07:44:12 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Pekka Savola" , , "Iljitsch van Beijnum" To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54B89@server2000.arneill-py.sacramento.ca.us> Message-Id: <120FA42D-380C-11D7-A9E5-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This would create a terrible precedent. In the long run, we can expect: > - People that have swamp space lobbying for v6 PI also, on the grounds > that if people that have an ASN get v6 PI space they should get it too. > Actually, swamp space holders have on paper a better reason than ASN > holders to get v6 PI space. Why? They still need an AS to get it announced. Either by themselves or through someone else. > - AS numbers being extended to 32 bits. Then people that get ASNs above > 64k will also strongly lobby to get PI on the grounds that it's not > fair > that early adopters only get it. It's still a size we can handle. > If we had no other choice, I would support this as being not as bad as > unrestricted PI. But it's still unaggregatable, and we do have a better > choice: GAPI. It's fast and it works. Go for it. - kurtis - From owner-multi6@ops.ietf.org Tue Feb 4 04:34:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14481 for ; Tue, 4 Feb 2003 04:34:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fzUW-0006W2-00 for multi6-data@psg.com; Tue, 04 Feb 2003 01:35:44 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18fzUT-0006Vq-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 01:35:41 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h149YqD80983; Tue, 4 Feb 2003 10:34:52 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 4 Feb 2003 10:34:52 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: <120FA42D-380C-11D7-A9E5-000393AB1404@kurtis.pp.se> Message-ID: <20030204102330.L61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Feb 2003, Kurt Erik Lindqvist wrote: > > - AS numbers being extended to 32 bits. Then people that get ASNs above > > 64k will also strongly lobby to get PI on the grounds that it's not > > fair that early adopters only get it. > It's still a size we can handle. 32 bits??? I don't think so... > > If we had no other choice, I would support this as being not as bad as > > unrestricted PI. But it's still unaggregatable, and we do have a better > > choice: GAPI. > It's fast and it works. Go for it. I hope you're talking about GAPI here. The whole ASN == PI thing doesn't work because every multihomer can get an AS number so every multihomer can get PI space so we're right back at square one. A much better way to do this would be to take the globally unique site local addresses for this. We can give two blocks of globally unique site local addresses to each organization that wants them: one that is guaranteed to be non-routable, and one that may or may not be routable. Then we agree to all carry the first X 10k worth of those globally unique potentially routable site local address blocks (GUPRSLABs?). When the number of those prefixes in the v6 table hits 20k, 40k, 60k or whatever, all bets are off and either we have built some MHAP-like mechanism to map from these PI addresses to PA addresses or we admit failure and go back to v4. Or we assign these addresses geographically and start doing geographical aggregation if we can't come up with anything better before the v6 table explodes. From owner-multi6@ops.ietf.org Tue Feb 4 04:48:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14687 for ; Tue, 4 Feb 2003 04:48:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fzi2-0006vQ-00 for multi6-data@psg.com; Tue, 04 Feb 2003 01:49:42 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18fzhy-0006vB-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 01:49:39 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h149nTG29329; Tue, 4 Feb 2003 11:49:29 +0200 Date: Tue, 4 Feb 2003 11:49:29 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: Kurt Erik Lindqvist , Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: <20030204102330.L61596-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Feb 2003, Iljitsch van Beijnum wrote: > The whole ASN == PI thing doesn't work because every multihomer can get > an AS number so every multihomer can get PI space so we're right back at > square one. The point of the model, as far as I thought it, at least was that: - those who already have an AS number, fine-- go for it (these would possibly contribute to some 1,000+ routes in IPv6 DFZ, the absolute number is peanuts, but of course there may be some layer 8 (and up) avalanche effects) - those who don't, forget about it, use other mechanisms ASN-PI model extended to 32 bits seems like a wrong thing to me: instead of a sunset, it just increases the need for otherwise perhaps an unnecessary technology change (as4bytes), and depletes the current AS number space. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Feb 4 05:26:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15229 for ; Tue, 4 Feb 2003 05:26:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g0JO-0008Xs-00 for multi6-data@psg.com; Tue, 04 Feb 2003 02:28:18 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18g0JL-0008XY-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 02:28:15 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h14ARYr81057; Tue, 4 Feb 2003 11:27:34 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 4 Feb 2003 11:27:34 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Savola cc: Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: Message-ID: <20030204111833.A61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NO_COST,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Feb 2003, Pekka Savola wrote: > - those who already have an AS number, fine-- go for it (these would > possibly contribute to some 1,000+ routes in IPv6 DFZ, the absolute number > is peanuts, but of course there may be some layer 8 (and up) avalanche > effects) Where do you get this? There are more than 25000 AS numbers out there. At some point, most of those networks will want to run IPv6. > - those who don't, forget about it, use other mechanisms It is very easy to get an AS number: if you want to multihome, you qualify. It's not even very expensive: $500 in the ARIN and APNIC regions last time I checked and no charge from RIPE if requested through a RIPE member. The hard part about multihoming in IPv4 is the address space. But if an AS number automatically means IPv6 PI space, that part won't be a problem either. This is what we in Dutch call an "open einde regeling" (open end arrangement): you know where it starts, but you can't know where it ends and thus how expensive it will be. > ASN-PI model extended to 32 bits seems like a wrong thing to me: instead > of a sunset, it just increases the need for otherwise perhaps an > unnecessary technology change (as4bytes), and depletes the current AS > number space. What's the alternative? Say to the 64511th person to request an AS number we're all out? From owner-multi6@ops.ietf.org Tue Feb 4 05:33:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15399 for ; Tue, 4 Feb 2003 05:32:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g0Pq-0008i7-00 for multi6-data@psg.com; Tue, 04 Feb 2003 02:34:58 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18g0Pm-0008hu-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 02:34:55 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h14AYmj29611; Tue, 4 Feb 2003 12:34:48 +0200 Date: Tue, 4 Feb 2003 12:34:48 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: <20030204111833.A61596-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,NO_COST,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Feb 2003, Iljitsch van Beijnum wrote: > On Tue, 4 Feb 2003, Pekka Savola wrote: > > > - those who already have an AS number, fine-- go for it (these would > > possibly contribute to some 1,000+ routes in IPv6 DFZ, the absolute number > > is peanuts, but of course there may be some layer 8 (and up) avalanche > > effects) > > Where do you get this? There are more than 25000 AS numbers out there. > At some point, most of those networks will want to run IPv6. Ok, my rough estimate was off a bit, but I was considering those parties that could be running v6 in about 3 years or so. As for the rest, e.g. http://bgp.potaroo.net/1221/bgp-active.html lists 10305 origin-only AS's. A little less than that, say 9000, is the current number we're talking about. Note that the mechanism is only applicable to origin-only AS's, and some of those can get addresses from sTLA space too. Not so bad in paper, IMO.. > > - those who don't, forget about it, use other mechanisms > > It is very easy to get an AS number: if you want to multihome, you > qualify. It's not even very expensive: $500 in the ARIN and APNIC > regions last time I checked and no charge from RIPE if requested through > a RIPE member. The hard part about multihoming in IPv4 is the address > space. But if an AS number automatically means IPv6 PI space, that part > won't be a problem either. > > This is what we in Dutch call an "open einde regeling" (open end > arrangement): you know where it starts, but you can't know where it ends > and thus how expensive it will be. It ends at AS32768. > > ASN-PI model extended to 32 bits seems like a wrong thing to me: instead > > of a sunset, it just increases the need for otherwise perhaps an > > unnecessary technology change (as4bytes), and depletes the current AS > > number space. > > What's the alternative? Say to the 64511th person to request an AS > number we're all out? There are still over 2^15 AS numbers to waste. Considerably more, less than a half of about 29K AS numbers are actually even being used.. Long-term solution: make a better policy for doling them out; avoid advocating situations where you (unnecessarily) need one. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Feb 4 05:53:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15657 for ; Tue, 4 Feb 2003 05:53:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g0jA-0009PK-00 for multi6-data@psg.com; Tue, 04 Feb 2003 02:54:56 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18g0j8-0009P2-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 02:54:54 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h14AsDt81108; Tue, 4 Feb 2003 11:54:13 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 4 Feb 2003 11:54:13 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Savola cc: Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: Message-ID: <20030204114445.D61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Feb 2003, Pekka Savola wrote: > It ends at AS32768. Any particular reason why we should leave 31744 perfectly good AS numbers unused? > > What's the alternative? Say to the 64511th person to request an AS > > number we're all out? > There are still over 2^15 AS numbers to waste. Considerably more, less > than a half of about 29K AS numbers are actually even being used.. Try to reclaim them... That's very hard. > Long-term solution: make a better policy for doling them out; avoid > advocating situations where you (unnecessarily) need one. This is not "the internet way"! Paying people to go through complex request procedures and then paying other people to review those request means wasting money twice. If we're going to waste money anyway, let's waste it on bigger hardware and smarter protocols, not on bureaucracy. BTW, the fact that you don't see an ASN in your tables doesn't mean it isn't legitimately used. For instance, most of you will not see AS12945. It is used to peer over the AMS-IX, but in order not to contribute to the global routing table unnecessarily we have our stuff aggregated by the upstream. From owner-multi6@ops.ietf.org Tue Feb 4 06:24:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16234 for ; Tue, 4 Feb 2003 06:24:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g1DY-000Ah9-00 for multi6-data@psg.com; Tue, 04 Feb 2003 03:26:20 -0800 Received: from pop-ls-09-1-dialup-131.freesurf.ch ([194.230.235.131] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18g1DT-000Agx-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 03:26:16 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h14BRJhE023093 for ; Tue, 4 Feb 2003 12:27:21 +0100 (CET) Date: Tue, 4 Feb 2003 10:46:23 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Comments on draft-van-beijnum-multi6-isp-int-aggr-00.txt From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <858127D7-3825-11D7-A9E5-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.3 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have finally read Iljitsch draft above. (yes, the slopes are closed due to the heavy snow fall so I have nothing better to do..:) ) What first strikes me is the complexity of the iBGP and keeping this up to date. I am not convinced that this is workable from a ISP point of view, but I want to think that over more. I am also not sure how "extras" in BGP (which I am not sure should be there in the first place) such as multicast and VPN information, would work. Another problem I see is that this requires networks that logically map fairly well into the physical topology, or even small networks gets complicated. This means that the MPLS crowd will have a problem (hey - maybe I do like this proposal! :) ), but so will also corporations that have few branch offices across the world connected with a IP-VPN or slow speed links. Something else that I haven't really figured out, but how will path loop prevention be done? If I understood the draft correct, as there is not full view, you can only look if a AS is present twice, but you could still see the route twice, no? Last, what worries me the most is the security considerations. A failure on filtering, or in routing configuration will make the AS7777 incident seem like trivial. This is not even in the security considerations section. It should be. - kurtis - From owner-multi6@ops.ietf.org Tue Feb 4 06:24:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16248 for ; Tue, 4 Feb 2003 06:24:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g1DC-000Ago-00 for multi6-data@psg.com; Tue, 04 Feb 2003 03:25:58 -0800 Received: from pop-ls-09-1-dialup-131.freesurf.ch ([194.230.235.131] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18g1D9-000AgY-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 03:25:55 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h14BQxhE023084 for ; Tue, 4 Feb 2003 12:27:02 +0100 (CET) Date: Tue, 4 Feb 2003 09:59:35 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: comments on draft-py-multi6-gapi-00.txt From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.0 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have gone through the above draft again and started thinking. Although the draft as such does not give any solution in itself to mulithoming it is part of other solutions. I am not convinced it scales though. I somehow have the feeling it is no different than the TLA/NLA/SLA model that was abandoned. Mainly my concerns are that this is based on statistics. The draft says that the options that are available to base this on is geography or population. I would add Geopolicy and economics. If we take Sweden or Switzerland as examples, these are countries with relatively small populations but with a high number of large multinationals per capita. Multinationals will have a higher burn rate of addresses, especially in multihoming than "ordinary" users will. With the GAPI addresses, instead large countries that might have a lower order of multihoming is gaining advantage. You can also argue that address consumption will most likely NOT follow geographic boundaries. If I take Stockholm, Ericsson for example have their HQ in a relatively unpopulated area. Also the "swedish silicon valley" have a high number of multinationals that will want to mulithome, but relatively small population. The more I think on this, the more I think that any model that tries to align address usage / availability to Geopolitics, economics, address usage, etc - will not scale. We will end up just adding more and more allocation blocks and the situation will be similar to todays. - kurtis - From owner-multi6@ops.ietf.org Tue Feb 4 07:30:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19827 for ; Tue, 4 Feb 2003 07:30:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g2EJ-000DKE-00 for multi6-data@psg.com; Tue, 04 Feb 2003 04:31:11 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18g2EF-000DJv-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 04:31:07 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h14CV2l30518; Tue, 4 Feb 2003 14:31:02 +0200 Date: Tue, 4 Feb 2003 14:31:02 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: <20030204114445.D61596-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Feb 2003, Iljitsch van Beijnum wrote: > On Tue, 4 Feb 2003, Pekka Savola wrote: > > > It ends at AS32768. > > Any particular reason why we should leave 31744 perfectly good AS > numbers unused? Because I don't want a proposal like this exhaust the 16bit AS number space. > > > What's the alternative? Say to the 64511th person to request an AS > > > number we're all out? > > > There are still over 2^15 AS numbers to waste. Considerably more, less > > than a half of about 29K AS numbers are actually even being used.. > > Try to reclaim them... That's very hard. Agreed, but that's what should be done before declaring loss. > > Long-term solution: make a better policy for doling them out; avoid > > advocating situations where you (unnecessarily) need one. > > This is not "the internet way"! Paying people to go through complex > request procedures and then paying other people to review those request > means wasting money twice. If we're going to waste money anyway, let's > waste it on bigger hardware and smarter protocols, not on bureaucracy. The question is where an AS number would be used. If the 16bit number was too low for all ISP's etc., sure .. but I'm not really convinced that's the case, especially if v4 multihoming is eliminated. Also, sometimes using ASN's seems to be unnecessary, something you could very well avoid altogether or replace with private AS numbers. > BTW, the fact that you don't see an ASN in your tables doesn't mean it > isn't legitimately used. For instance, most of you will not see AS12945. > It is used to peer over the AMS-IX, but in order not to contribute to > the global routing table unnecessarily we have our stuff aggregated by > the upstream. Yes, there are cases like this.. but often these are also ones where a (public) AS number would not really be strictly necessary. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Feb 4 08:39:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22269 for ; Tue, 4 Feb 2003 08:39:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g3JI-000G8P-00 for multi6-data@psg.com; Tue, 04 Feb 2003 05:40:24 -0800 Received: from tele2-1-1-dialup-191.freesurf.ch ([194.230.196.191] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18g3J8-000G83-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 05:40:17 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h14BRlhE023105; Tue, 4 Feb 2003 12:27:48 +0100 (CET) Date: Tue, 4 Feb 2003 11:09:36 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Tim Chown" , , Philip Smith To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5B94D@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I don't think so, it more a matter of creating the precedent then real > savings on the routing table size. > BGP routing table entries examined: 120000 Prefixes after maximum aggregation: 76659 Unique aggregates announced to Internet: 57689 Total ASes present in the Internet Routing Table: 14519 Origin-only ASes present in the Internet Routing Table: 12614 Origin ASes announcing only one prefix: 5690 Transit ASes present in the Internet Routing Table: 1905 Transit-only ASes present in the Internet Routing Table: 65 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 17 Illegal AS announcements present in the Routing Table: 12 Non-routable prefixes present in the Routing Table: 0 Prefixes being announced from the IANA Reserved Address blocks: 24 Number of addresses announced to Internet: 1181077033 Equivalent to 70 /8s, 101 /16s and 206 /24s Percentage of available address space announced: 31.9 Percentage of allocated address space announced: 57.9 Percentage of available address space allocated: 55.0 Total number of prefixes smaller than registry allocations: 55671 So, if all had a IPv6 delegation, we would have 14519 routes, of which 12614 would be multihomed. Compared to 120k. What are are missing is the number of prefixes announced by origin-only AS:es. Philip, are you lurking here? Can that be added? - kurtis - From owner-multi6@ops.ietf.org Tue Feb 4 08:39:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22299 for ; Tue, 4 Feb 2003 08:39:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g3IB-000G3k-00 for multi6-data@psg.com; Tue, 04 Feb 2003 05:39:15 -0800 Received: from tele2-1-1-dialup-191.freesurf.ch ([194.230.196.191] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18g3Hw-000G3G-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 05:39:06 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h14BRqhE023108; Tue, 4 Feb 2003 12:27:54 +0100 (CET) Date: Tue, 4 Feb 2003 11:12:00 +0100 Subject: Re: Comment on draft-ietf-multi6-v4-multihoming-00 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <19843ACC-3829-11D7-A9E5-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I'd like to propose an additional item, "3.0 Independence". What about "3.0.1 Coolness"? :) > It's only implicitly included under Policy, and technically (mostly) > included under redundancy.. but it seems to me that it is a major > reason > for certain solutions, and a critical reason why many IPv6 site > multihoming solutions are not considered adequate. > > Is there some flaw in my thinking? Are there other missing pieces in > the > old document? Any other references to documenting IPv4 practises? > I think you are right. I think the two main reasons for multihoming / PI space (that normally go hand in hand) is redundancy and independence. - kurtis - From owner-multi6@ops.ietf.org Tue Feb 4 08:54:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22515 for ; Tue, 4 Feb 2003 08:54:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g3YS-000GpI-00 for multi6-data@psg.com; Tue, 04 Feb 2003 05:56:04 -0800 Received: from elle.sprintlink.net ([199.0.234.34] helo=iscserv1.res.sprintlink.net) by psg.com with esmtp (Exim 3.36 #1) id 18g3YQ-000Gp3-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 05:56:02 -0800 Received: from localhost (rrockell@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id IAA09573 for ; Tue, 4 Feb 2003 08:58:48 -0500 (EST) X-Authentication-Warning: iscserv1.res.sprintlink.net: rrockell owned process doing -bs Date: Tue, 4 Feb 2003 08:58:48 -0500 (EST) From: "Robert J. Rockell" X-X-Sender: To: Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,SPAM_PHRASE_00_01,USER_AGENT_PINE, X_AUTH_WARNING version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk this is my favorite line: Percentage of available address space announced: 31.9 call back when multihoming works to SCALE. The sky may not be falling (as fast as people say). Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- On Tue, 4 Feb 2003, Kurt Erik Lindqvist wrote: ->> I don't think so, it more a matter of creating the precedent then real ->> savings on the routing table size. ->> -> -> ->BGP routing table entries examined: 120000 -> Prefixes after maximum aggregation: 76659 -> Unique aggregates announced to Internet: 57689 ->Total ASes present in the Internet Routing Table: 14519 ->Origin-only ASes present in the Internet Routing Table: 12614 ->Origin ASes announcing only one prefix: 5690 ->Transit ASes present in the Internet Routing Table: 1905 ->Transit-only ASes present in the Internet Routing Table: 65 ->Average AS path length visible in the Internet Routing Table: 5.3 -> Max AS path length visible: 17 ->Illegal AS announcements present in the Routing Table: 12 ->Non-routable prefixes present in the Routing Table: 0 ->Prefixes being announced from the IANA Reserved Address blocks: 24 ->Number of addresses announced to Internet: 1181077033 -> Equivalent to 70 /8s, 101 /16s and 206 /24s -> Percentage of available address space announced: 31.9 -> Percentage of allocated address space announced: 57.9 -> Percentage of available address space allocated: 55.0 ->Total number of prefixes smaller than registry allocations: 55671 -> -> ->So, if all had a IPv6 delegation, we would have 14519 routes, of which ->12614 would be multihomed. Compared to 120k. What are are missing is ->the number of prefixes announced by origin-only AS:es. Philip, are you ->lurking here? Can that be added? -> ->- kurtis - -> -> From owner-multi6@ops.ietf.org Tue Feb 4 09:07:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22815 for ; Tue, 4 Feb 2003 09:07:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g3lZ-000HYL-00 for multi6-data@psg.com; Tue, 04 Feb 2003 06:09:37 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #1) id 18g3lW-000HWi-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 06:09:34 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h14E8Q89082388; Tue, 4 Feb 2003 15:08:46 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h14E8G7Q235292; Tue, 4 Feb 2003 15:08:17 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55222 from ; Tue, 4 Feb 2003 15:08:15 +0100 Message-Id: <3E3FC920.123E9FA8@hursley.ibm.com> Date: Tue, 04 Feb 2003 15:07:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "J. Noel Chiappa" Cc: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers References: <200302040115.h141FOXC002924@ginger.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "J. Noel Chiappa" wrote: > > > From: Brian E Carpenter > > > I feel that the challenge is actually not in the Internet Protocol > > address at all. IPv6 *unmodified* is entirely capable of supporting a > > namespace independent of topology > > Syntax != Semantics. > > Just because you have a single namespace that you can allocate both "where" > and "who" names from doesn't mean you're done. Of course, I didn't mean to imply otherwise. > > Unless you start using multiple headers (which is sort of already specified, > which is why I like 16+16, although it has all the obvious "source routing" > security bugs), there's only a single IPv6 address field in "IPv6 > *unmodified*", so it's kind of hard to do both with one field. I'm not sure I've seen the 16+16 draft. But it is my assumption that any solution is going to involve an additional mapping stage that we don't have today. Brian From owner-multi6@ops.ietf.org Tue Feb 4 11:03:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26341 for ; Tue, 4 Feb 2003 11:03:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g5YQ-000N3I-00 for multi6-data@psg.com; Tue, 04 Feb 2003 08:04:10 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18g5YO-000N36-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 08:04:08 -0800 Subject: RE: Draft: PI addressing derived from AS numbers Date: Tue, 4 Feb 2003 08:04:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5B982@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLMNBAqO15NSXz9S4KXiRP9VG4EZwAMqcRA From: "Michel Py" To: "Pekka Savola" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA26341 > Pekka Savola wrote: > The point of the model, as far as I thought it, at > least was that: > - those who already have an AS number, fine-- go for it > (these would possibly contribute to some 1,000+ routes > in IPv6 DFZ, the absolute number is peanuts, but of > course there may be some layer 8 (and up) avalanche > effects) I think this resumes it well. If it was not for the avalanche effects (including a land rush to get ASNs) it could be workable. Michel. From owner-multi6@ops.ietf.org Tue Feb 4 11:11:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26540 for ; Tue, 4 Feb 2003 11:11:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g5hX-000NRQ-00 for multi6-data@psg.com; Tue, 04 Feb 2003 08:13:35 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18g5hU-000NR4-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 08:13:32 -0800 Subject: RE: Draft: PI addressing derived from AS numbers Date: Tue, 4 Feb 2003 08:13:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BAF@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLMOXhOKkzq8dR3TwSibJ7O1yz1dwALbxCA From: "Michel Py" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA26540 > Iljitsch van Beijnum > It is very easy to get an AS number: if you want to > multihome, you qualify. It's not even very expensive: > $500 This is very true, and won't be denied by the multiple people that I know on this list that have ASNs for their _homes_, coming either from recycled ASNs from mergers or even from flat out requests perverting the 6bone. Michel. From owner-multi6@ops.ietf.org Tue Feb 4 20:52:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10742 for ; Tue, 4 Feb 2003 20:52:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gEk1-0004Ut-00 for multi6-data@psg.com; Tue, 04 Feb 2003 17:52:45 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18gEjz-0004UM-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 17:52:43 -0800 Subject: RE: Draft: PI addressing derived from AS numbers Date: Tue, 4 Feb 2003 17:52:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5B98B@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLMQE1fF2BPFUxvSTKWxZITuN1GigAeKQ/w From: "Michel Py" To: "Kurt Erik Lindqvist" Cc: X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA10742 Kurtis, > Kurt Erik Lindqvist > So, if all had a IPv6 delegation, we would have 14519 routes, > of which 12614 would be multihomed. Compared to 120k. I agree that 12k routes is nothing we have to care about, but this is not the point. The point is that if we start this, it will be impossible to stop. No to the IPv6 swamp! Michel. From owner-multi6@ops.ietf.org Tue Feb 4 22:05:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12788 for ; Tue, 4 Feb 2003 22:05:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gFtz-0009Mq-00 for multi6-data@psg.com; Tue, 04 Feb 2003 19:07:07 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18gFtx-0009Md-00 for multi6@ops.ietf.org; Tue, 04 Feb 2003 19:07:05 -0800 Subject: RE: comments on draft-py-multi6-gapi-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 4 Feb 2003 19:07:04 -0800 Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BB8@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: comments on draft-py-multi6-gapi-00.txt Thread-Index: AcLMQTKznrZI6yKkQiej7MYFGdXXVgAea/oA From: "Michel Py" To: "Kurt Erik Lindqvist" , X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA12788 Kurtis, > Kurt Erik Lindqvist > I have gone through the above draft again and started > thinking. Although the draft as such does not give any > solution in itself to mulithoming it is part of other > solutions. I am not convinced it scales though. This is irrelevant to the draft, as the scalability comes from the aggregation model and not from the addressing allocation plan. Out of the two aggregation schemes that currently use GAPI (MHAP and isp-int-aggr"GFN"), we know that the aggregation provided by GFN does not scale that good, but MHAP does (MHAP is a dual-space system and the GAPI address is the identifier). > Mainly my concerns are that this is based on statistics. The draft > says that the options that are available to base this on is geography > or population. It's mostly population. The geography part (such as promoting Hawaii to the status of "country") is baseline or optimization only. > I would add Geopolicy and economics. Certainly not, because this will get us into politics. Maybe China will be capitalist tomorrow, who knows. When I was a young man, the enemy was the Soviet Union and people in Berlin were being shot trying to jump the wall. Go to Berlin now, it's fortunate that the remains of the wall are documented because otherwise you would not find them. Gee, maybe in 3 years the largest concentration of multihomed oil companies will be in Iraq and the Russians will make their space shuttle fly after they are done inspecting the heat shield. Who are we to predict the future? In Tony Hain's drafts, a square foot in Kabul gets the same number of IPv6 addresses than a square foot in Palo Alto; we do the same except that we do it for people. No politics. If you're not happy with the numbers, talk to the United Nations Statistics division. > If we take Sweden or Switzerland as examples, these are countries > with relatively small populations but with a high number of large > multinationals per capita. Multinationals will have a higher burn > rate of addresses, especially in multihoming than "ordinary" users > will. With the GAPI addresses, instead large countries that might > have a lower order of multihoming is gaining advantage. This is true, but we addressed it by having slack at three different levels. In the absolute, it does not make a difference anyway, because our base allocation gives an address for four people, and multinationals are typically way larger than 4 people. > You can also argue that address consumption will most likely NOT > follow geographic boundaries. If I take Stockholm, Ericsson for > example have their HQ in a relatively unpopulated area. Also the > "swedish silicon valley" have a high number of multinationals that > will want to mulithome, but relatively small population. I don't see what the problem is. The slack for Sweden is 93.75%, allocating a /32 for the Swedish silicon valley is perfectly in line with the draft, after you guys have cornered a little piece of the 128k multihomed sites already allocated to Stockholm that is. And if it's still not enough, the Western Europe zone has a 45.59% slack to allocate from. > The more I think on this, the more I think that any model that tries > to align address usage / availability to Geopolitics, economics, > address usage, etc - will not scale. Again, there is no relation. The scalability is provided by the aggregation mechanism, not by the allocation plan. Michel. From owner-multi6@ops.ietf.org Wed Feb 5 03:20:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14047 for ; Wed, 5 Feb 2003 03:20:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gKnY-0003eP-00 for multi6-data@psg.com; Wed, 05 Feb 2003 00:20:48 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18gKnU-0003dX-00 for multi6@ops.ietf.org; Wed, 05 Feb 2003 00:20:45 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h158Kbw10104; Wed, 5 Feb 2003 10:20:37 +0200 Date: Wed, 5 Feb 2003 10:20:37 +0200 (EET) From: Pekka Savola To: Michel Py cc: multi6@ops.ietf.org Subject: RE: Draft: PI addressing derived from AS numbers In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5B982@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Feb 2003, Michel Py wrote: > > Pekka Savola wrote: > > The point of the model, as far as I thought it, at > > least was that: > > - those who already have an AS number, fine-- go for it > > (these would possibly contribute to some 1,000+ routes > > in IPv6 DFZ, the absolute number is peanuts, but of > > course there may be some layer 8 (and up) avalanche > > effects) > > I think this resumes it well. If it was not for the avalanche effects > (including a land rush to get ASNs) it could be workable. There should _not_ be a land rush to get ASN's.. as those gold miners should realize that the specification as written will give them _nothing_. (Well, except for the 2,000-3,000 first ones or so, until we reach 32K, but I don't see that as a big problem.) What I'd be more worried is Layer 8 (and up) effects, crying about unfairness of the world, pushing to extend the limits, etc.etc. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Feb 5 04:46:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15449 for ; Wed, 5 Feb 2003 04:46:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gMA6-0006MC-00 for multi6-data@psg.com; Wed, 05 Feb 2003 01:48:10 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18gMA3-0006Lz-00 for multi6@ops.ietf.org; Wed, 05 Feb 2003 01:48:07 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h159lMC83468; Wed, 5 Feb 2003 10:47:22 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 5 Feb 2003 10:47:22 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: Comments on draft-van-beijnum-multi6-isp-int-aggr-00.txt In-Reply-To: <858127D7-3825-11D7-A9E5-000393AB1404@kurtis.pp.se> Message-ID: <20030205103321.Y61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Feb 2003, Kurt Erik Lindqvist wrote: > I have finally read Iljitsch draft above. Thanks for taking the time to provide feedback! > What first strikes me is the complexity of the iBGP and keeping this up > to date. > I am not convinced that this is workable from a ISP point of view, I agree that it's a hassle, but it's not all that complex. It is basically similar to running OSPF with area aggregation. Larger ISPs already have complex BGP setups with route reflectors and/or confederations and redistribution. This proposal is on the same level of complexity. What do you mean by keeping it up to date? > but > I want to think that over more. I am also not sure how "extras" in BGP > (which I am not sure should be there in the first place) such as > multicast and VPN information, would work. Multicast uses a separate routing table so there shouldn't be any impact. VPN is not a part of regular BGP. > Another problem I see is that this requires networks that logically map > fairly well into the physical topology, or even small networks gets > complicated. Small networks are unlikely to use internal aggregation: it's more likely they'll just send traffic for certain regions (where they are not present themselves) to their upstream ISPs. > This means that the MPLS crowd will have a problem (hey - > maybe I do like this proposal! :) ), but so will also corporations that > have few branch offices across the world connected with a IP-VPN or > slow speed links. I'm not sure what kind of problem you see here. I am unfamiliar with the way MPLS is really deployed in networks so I can't say anything about that except that if the worst part about this protocol is that it makes it impossible to provide integrated IP and MPLS services I can live with that: just de-integrate them. > Something else that I haven't really figured out, but how will path > loop prevention be done? If I understood the draft correct, as there is > not full view, you can only look if a AS is present twice, but you > could still see the route twice, no? This is still regular BGP so no special loop prevention magic. There is a section in the draft that warns about routing loops if there are network partitions. This can happen with any kind of aggregation. The answer is always: build your network so that it doesn't partition. > Last, what worries me the most is the security considerations. A > failure on filtering, or in routing configuration will make the AS7777 > incident seem like trivial. No. > This is not even in the security considerations section. It should be. No. Iljitsch From owner-multi6@ops.ietf.org Wed Feb 5 05:07:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15857 for ; Wed, 5 Feb 2003 05:07:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gMUx-0007DC-00 for multi6-data@psg.com; Wed, 05 Feb 2003 02:09:43 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18gMUu-0007D0-00 for multi6@ops.ietf.org; Wed, 05 Feb 2003 02:09:40 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h15A90t83500; Wed, 5 Feb 2003 11:09:00 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 5 Feb 2003 11:09:00 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: comments on draft-py-multi6-gapi-00.txt In-Reply-To: Message-ID: <20030205104746.D61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Feb 2003, Kurt Erik Lindqvist wrote: > You can also argue that address consumption will most likely NOT follow > geographic boundaries. If I take Stockholm, Ericsson for example have > their HQ in a relatively unpopulated area. Also the "swedish silicon > valley" have a high number of multinationals that will want to > mulithome, but relatively small population. I'm sure address consumption won't follow the population spread. However, there is only one other objective way of pre-allocating address space: on geography. This both wastes a lot of address space and fails to provide enough of it. In the end, it all comes down to people: they own/operate equipment that needs to be connected over multiple lines. I'm sure many more people own or run a multihomed network in the Swedish silicon valley than in a rural province of China, but the gain you get from allocating less for China is much smaller than the hassle of having to manually look at it and justify your decision. If we are generous there are 25000 multihomers at this moment, spread over the US/Canada and Europe. That's around 600 million / 25 thousand = 1 multihomed network per 24000 inabitants. The current GAPI figures provide for a /26 for Sweden. So that's 8833000 inhabitants / 4194304 multihomed /48s = 1 multihomed network per 2.1 inhabitants. Obviously at these levels of multihoming the number of multinational organizations becomes irrelevant. Please note that although the address allocation mechanism supports these levels of multihoming, that doesn't mean my other draft does. If you get 4 million multihomers in Sweden and a router can only take a 250k routing table, you need to interconnect with 16 or 32 different routers in Sweden. That's not good. (But at least this way the problem has moved from "unsolvable" meaning loss of connectivity to "solvable by throwing money at it" meaning we get to make an economic tradeoff.) From owner-multi6@ops.ietf.org Wed Feb 5 11:01:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29501 for ; Wed, 5 Feb 2003 11:01:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gS0K-000Luq-00 for multi6-data@psg.com; Wed, 05 Feb 2003 08:02:28 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18gS0H-000Lue-00 for multi6@ops.ietf.org; Wed, 05 Feb 2003 08:02:25 -0800 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 h15G2FMY013036; Wed, 5 Feb 2003 11:02:15 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h15G2FxE013035; Wed, 5 Feb 2003 11:02:15 -0500 Date: Wed, 5 Feb 2003 11:02:15 -0500 From: "J. Noel Chiappa" Message-Id: <200302051602.h15G2FxE013035@ginger.lcs.mit.edu> To: iljitsch@muada.com, multi6@ops.ietf.org Subject: Re: comments on draft-py-multi6-gapi-00.txt Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > there is only one other objective way of pre-allocating address space: > on geography. Pre-allocating routing-names in a global-scale network without controlled connectivity is an idea so broken I won't even bother to say anything more about it. If you want to pre-allocate some other kind of name (say an identifier). that's reasonable. Noel From owner-multi6@ops.ietf.org Wed Feb 5 11:39:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00873 for ; Wed, 5 Feb 2003 11:39:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gSbC-000Ng8-00 for multi6-data@psg.com; Wed, 05 Feb 2003 08:40:34 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18gSb8-000Nfv-00 for multi6@ops.ietf.org; Wed, 05 Feb 2003 08:40:30 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h15Gdma84000; Wed, 5 Feb 2003 17:39:48 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 5 Feb 2003 17:39:48 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: comments on draft-py-multi6-gapi-00.txt In-Reply-To: <200302051602.h15G2FxE013035@ginger.lcs.mit.edu> Message-ID: <20030205173621.G61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 5 Feb 2003, J. Noel Chiappa wrote: > > there is only one other objective way of pre-allocating address space: > > on geography. > Pre-allocating routing-names in a global-scale network without controlled > connectivity is an idea so broken I won't even bother to say anything more > about it. Without pre-allocation there can't be any successful aggregation. We can see this in IPv4 today: the RIRs (pre-) allocate blocks that are too small to ISPs so these ISPs end up with lots of relatively small blocks. From owner-multi6@ops.ietf.org Wed Feb 5 11:42:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01018 for ; Wed, 5 Feb 2003 11:42:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gSfJ-000Nt1-00 for multi6-data@psg.com; Wed, 05 Feb 2003 08:44:49 -0800 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18gSfE-000NsT-00 for multi6@ops.ietf.org; Wed, 05 Feb 2003 08:44:44 -0800 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 584BA431E6; Wed, 5 Feb 2003 17:44:41 +0100 (CET) Received: from localhost.localdomain (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id C141099F49; Wed, 5 Feb 2003 17:44:40 +0100 (CET) Subject: Re: comments on draft-py-multi6-gapi-00.txt From: marcelo bagnulo To: "J. Noel Chiappa" Cc: iljitsch@muada.com, multi6@ops.ietf.org In-Reply-To: <200302051602.h15G2FxE013035@ginger.lcs.mit.edu> References: <200302051602.h15G2FxE013035@ginger.lcs.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 05 Feb 2003 17:44:36 +0100 Message-Id: <1044463479.797.6.camel@presto> Mime-Version: 1.0 X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-05 at 17:02, J. Noel Chiappa wrote: > > From: Iljitsch van Beijnum > > > there is only one other objective way of pre-allocating address space: > > on geography. > > Pre-allocating routing-names in a global-scale network without controlled > connectivity is an idea so broken I won't even bother to say anything more > about it. > > If you want to pre-allocate some other kind of name (say an identifier). > that's reasonable. I guess this is how MHAP uses GAPI. Geographic Identifiers. Regards, marcelo > > Noel > From owner-multi6@ops.ietf.org Wed Feb 5 13:06:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04586 for ; Wed, 5 Feb 2003 13:06:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gTyb-0002GK-00 for multi6-data@psg.com; Wed, 05 Feb 2003 10:08:49 -0800 Received: from goose.automagic.org ([199.212.90.4]) by psg.com with esmtp (Exim 3.36 #1) id 18gTyX-0002G8-00 for multi6@ops.ietf.org; Wed, 05 Feb 2003 10:08:46 -0800 Received: from automagic.org (dhcp-k-1.automagic.org [199.212.90.17]) by goose.automagic.org (Postfix) with ESMTP id 791CD3541D; Wed, 5 Feb 2003 13:08:34 -0500 (EST) Date: Wed, 5 Feb 2003 13:08:42 -0500 Subject: Re: comments on draft-py-multi6-gapi-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "J. Noel Chiappa" , To: Iljitsch van Beijnum From: Joe Abley In-Reply-To: <20030205173621.G61596-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Feb 5, 2003, at 11:39 Canada/Eastern, Iljitsch van Beijnum wrote: > On Wed, 5 Feb 2003, J. Noel Chiappa wrote: > >>> there is only one other objective way of pre-allocating address >>> space: >>> on geography. > >> Pre-allocating routing-names in a global-scale network without >> controlled >> connectivity is an idea so broken I won't even bother to say anything >> more >> about it. > > Without pre-allocation there can't be any successful aggregation. We > can > see this in IPv4 today: the RIRs (pre-) allocate blocks that are too > small to ISPs so these ISPs end up with lots of relatively small > blocks. Organisations move, merge and split apart. Physical and layer-2 networks can change radically with no impact on layer 3. There are operators today selling wide-area layer-2 transport services in which single subnets span continents. Layer-3 topologies (both intra-AS and inter-AS) change on a daily basis. Given such a turbulent soup of connectedness, what criteria for pre-allocation of routing names stands a chance of not being out-of-date as soon as it is published? [There was no pre-allocation with IPv4, and there is certainly *some* successful aggregation today, despite what you say, and even given the allocation issues you mention.] Joe From owner-multi6@ops.ietf.org Wed Feb 5 15:52:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10317 for ; Wed, 5 Feb 2003 15:52:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gWZi-000BiY-00 for multi6-data@psg.com; Wed, 05 Feb 2003 12:55:18 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18gWZf-000BiG-00 for multi6@ops.ietf.org; Wed, 05 Feb 2003 12:55:15 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h15KrGB84395; Wed, 5 Feb 2003 21:53:16 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 5 Feb 2003 21:53:16 +0100 (CET) From: Iljitsch van Beijnum To: Joe Abley cc: Subject: Re: comments on draft-py-multi6-gapi-00.txt In-Reply-To: Message-ID: <20030205214018.M61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 5 Feb 2003, Joe Abley wrote: > > Without pre-allocation there can't be any successful aggregation. We > > can see this in IPv4 today: the RIRs (pre-) allocate blocks that are too > > small to ISPs so these ISPs end up with lots of relatively small > > blocks. > Organisations move, merge and split apart. Physical and layer-2 > networks can change radically with no impact on layer 3. There are > operators today selling wide-area layer-2 transport services in which > single subnets span continents. Layer-3 topologies (both intra-AS and > inter-AS) change on a daily basis. People keep themselves busy. So? > Given such a turbulent soup of connectedness, what criteria for > pre-allocation of routing names stands a chance of not being > out-of-date as soon as it is published? Let's take the speed of light for this. You can change many things about your network, but not the fact that making packets take a 10000 km detour adds a 50 ms delay. Also, if you're going to physically move your network renumbering is only a minor extra task in addition to everything else that's going on. > [There was no pre-allocation with IPv4, and there is certainly *some* > successful aggregation today, despite what you say, and even given the > allocation issues you mention.] ISPs get /19s, /20s and /16s because it is assumed they'll need more in the future than the single /24 they're requesting today. This is what I mean by pre-allocation. From owner-multi6@ops.ietf.org Wed Feb 5 19:41:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16768 for ; Wed, 5 Feb 2003 19:41:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ga8Q-0000ry-00 for multi6-data@psg.com; Wed, 05 Feb 2003 16:43:22 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18ga8O-0000rm-00 for multi6@ops.ietf.org; Wed, 05 Feb 2003 16:43:20 -0800 Content-class: urn:content-classes:message Subject: RE: comments on draft-py-multi6-gapi-00.txt Date: Wed, 5 Feb 2003 16:43:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5B997@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: comments on draft-py-multi6-gapi-00.txt Thread-Index: AcLNNyDorF0+wlzPSraIn9Wkbj/JPAAQUzsg From: "Michel Py" To: "Marcelo Bagnulo" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA16768 > marcelo bagnulo wrote: > I guess this is how MHAP uses GAPI. Geographic Identifiers. Absolutely, although it is nice to have GFN as a parachute. Michel From owner-multi6@ops.ietf.org Thu Feb 6 01:57:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25732 for ; Thu, 6 Feb 2003 01:57:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gfz4-0002OZ-00 for multi6-data@psg.com; Wed, 05 Feb 2003 22:58:06 -0800 Received: from tele2-1-1-dialup-203.freesurf.ch ([194.230.196.203] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18gfyz-0002KF-00 for multi6@ops.ietf.org; Wed, 05 Feb 2003 22:58:02 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h166wkhE023696; Thu, 6 Feb 2003 07:58:49 +0100 (CET) Date: Wed, 5 Feb 2003 22:08:27 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Brian Carpenter" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54BA8@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.9 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Hmmmm, I'm a newcomer but that should not limit me so I want the same > stuff as the old-timers, and now we have 100 million /48s in the global > routing table and we're in deep doodoo. You then need an AS number and to get that you need to have to upstreams. - kurtis - From owner-multi6@ops.ietf.org Thu Feb 6 06:00:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12597 for ; Thu, 6 Feb 2003 06:00:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gjn0-000CzN-00 for multi6-data@psg.com; Thu, 06 Feb 2003 03:01:54 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 18gjmw-000CzB-00 for multi6@ops.ietf.org; Thu, 06 Feb 2003 03:01:51 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h16B0vlo071158; Thu, 6 Feb 2003 12:01:03 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h16B0kmR281500; Thu, 6 Feb 2003 12:00:47 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA33476 from ; Thu, 6 Feb 2003 12:00:38 +0100 Message-Id: <3E424027.AD4CEA8@hursley.ibm.com> Date: Thu, 06 Feb 2003 11:59:51 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: Joe Abley , multi6@ops.ietf.org Subject: Re: comments on draft-py-multi6-gapi-00.txt References: <20030205214018.M61596-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit below... Iljitsch van Beijnum wrote: > > On Wed, 5 Feb 2003, Joe Abley wrote: > > > > Without pre-allocation there can't be any successful aggregation. We > > > can see this in IPv4 today: the RIRs (pre-) allocate blocks that are too > > > small to ISPs so these ISPs end up with lots of relatively small > > > blocks. > > > Organisations move, merge and split apart. Physical and layer-2 > > networks can change radically with no impact on layer 3. There are > > operators today selling wide-area layer-2 transport services in which > > single subnets span continents. Layer-3 topologies (both intra-AS and > > inter-AS) change on a daily basis. > > People keep themselves busy. So? > > > Given such a turbulent soup of connectedness, what criteria for > > pre-allocation of routing names stands a chance of not being > > out-of-date as soon as it is published? > > Let's take the speed of light for this. You can change many things about > your network, but not the fact that making packets take a 10000 km > detour adds a 50 ms delay. Also, if you're going to physically move your > network renumbering is only a minor extra task in addition to everything > else that's going on. > > > [There was no pre-allocation with IPv4, and there is certainly *some* > > successful aggregation today, despite what you say, and even given the > > allocation issues you mention.] > > ISPs get /19s, /20s and /16s because it is assumed they'll need more in > the future than the single /24 they're requesting today. This is what I > mean by pre-allocation. Yes, but that is in a CIDR context with *topological* aggregation. You seem to imagine that geographical allocation will somehow match up with topology and therefore cause aggregation. All historical evidence suggests otherwise. If we could pass a law that every local government in the world had to set up a monopoly IXP for its area, we might be able to obtain enough congruence between geography and topology. But I don't expect that any time soon. Can't we just accept that only a two-layer solution that separates identfier-addresses from locator-addresses can solve this puzzle, and move on to figure out the two-layer solution? Brian From owner-multi6@ops.ietf.org Thu Feb 6 08:03:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16516 for ; Thu, 6 Feb 2003 08:03:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18glja-000I05-00 for multi6-data@psg.com; Thu, 06 Feb 2003 05:06:30 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18gljY-000Hzm-00 for multi6@ops.ietf.org; Thu, 06 Feb 2003 05:06:28 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h16D5k685834; Thu, 6 Feb 2003 14:05:46 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 6 Feb 2003 14:05:46 +0100 (CET) From: Iljitsch van Beijnum To: Brian E Carpenter cc: Subject: Re: comments on draft-py-multi6-gapi-00.txt In-Reply-To: <3E424027.AD4CEA8@hursley.ibm.com> Message-ID: <20030206130146.I61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Feb 2003, Brian E Carpenter wrote: > You seem to imagine that geographical allocation will somehow > match up with topology and therefore cause aggregation. All > historical evidence suggests otherwise. Historical evidence shows a trend of interconnection getting denser (but slowly). I don't see why we shouldn't take advantage of that where possible. If we use geographic addressing for multihomers there is the potential that we can later aggregate on geography if there is some level (not necessarily a very high level) of interconnection within regions. If we use another mechanism to allocate address space for multihomers we don't have this option. As there doesn't seem to be any other way to allocate address space for multihomers that has other benefits (other than being slightly simpler) I can't see any justification to NOT allocate them geographically. > If we could pass a law that every local government in the world > had to set up a monopoly IXP for its area, we might be able to > obtain enough congruence between geography and topology. But I > don't expect that any time soon. 100% interconnection within regions is not required: if there is interconnection, fine, we can aggregate. If there isn't, also fine, but no aggregation for multihomers in that region. This is a numbers game: most of the large networks interconnect in enough locations to be able to aggregate to a usable degree. And presumably, this will get better rather than worse over time. At some point it may even make business sense to interconnect more rather than buy bigger hardware. > Can't we just accept that only a two-layer solution that separates > identfier-addresses from locator-addresses can solve this puzzle, > and move on to figure out the two-layer solution? I'm all for that but I think we need something short-term as well. From owner-multi6@ops.ietf.org Thu Feb 6 09:00:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18071 for ; Thu, 6 Feb 2003 09:00:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gmcf-000KqS-00 for multi6-data@psg.com; Thu, 06 Feb 2003 06:03:25 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18gmcc-000KqF-00 for multi6@ops.ietf.org; Thu, 06 Feb 2003 06:03:22 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h16E2QK20851; Thu, 6 Feb 2003 16:02:26 +0200 Date: Thu, 6 Feb 2003 16:02:26 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Iljitsch van Beijnum , Joe Abley , Subject: Re: comments on draft-py-multi6-gapi-00.txt In-Reply-To: <3E424027.AD4CEA8@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk I'd like to expand on one particular point: On Thu, 6 Feb 2003, Brian E Carpenter wrote: > If we could pass a law that every local government in the world > had to set up a monopoly IXP for its area, we might be able to > obtain enough congruence between geography and topology. But I > don't expect that any time soon. .. IXP does not have to have a monopoly AFAICS, more specifics can be advertised in every IXP. What is more troublesome is that the IXP business model must be so that it has upstream connectivity, and advertises the aggregate to the Internet. And that the IXP has sufficient redundancy so people would not have to work around its back.. "Neutral" IXP's without even AS numbers are not sufficient. I'm not sure how it is out there, but here in Finland that's the only model for IXP's. The only way to make it "work" without IXP's would be building a billing model like the telephone transit (AFAIK) for these PI aggregate advertisements (paid by those who connect the organizations and have the more specifics).. and we know how well billing models work in the Internet..... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Feb 6 09:33:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19268 for ; Thu, 6 Feb 2003 09:33:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gn8C-000MVI-00 for multi6-data@psg.com; Thu, 06 Feb 2003 06:36:00 -0800 Received: from goose.automagic.org ([199.212.90.4]) by psg.com with esmtp (Exim 3.36 #1) id 18gn8A-000MUz-00 for multi6@ops.ietf.org; Thu, 06 Feb 2003 06:35:58 -0800 Received: from automagic.org (dhcp-k-1.automagic.org [199.212.90.17]) by goose.automagic.org (Postfix) with ESMTP id 6CA83355D4; Thu, 6 Feb 2003 09:35:56 -0500 (EST) Date: Thu, 6 Feb 2003 09:36:04 -0500 Subject: Re: comments on draft-py-multi6-gapi-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Brian E Carpenter , Iljitsch van Beijnum , To: Pekka Savola From: Joe Abley In-Reply-To: Message-Id: <526841CD-39E0-11D7-B4A4-00039312C852@automagic.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, Feb 6, 2003, at 09:02 Canada/Eastern, Pekka Savola wrote: > I'd like to expand on one particular point: > > On Thu, 6 Feb 2003, Brian E Carpenter wrote: >> If we could pass a law that every local government in the world >> had to set up a monopoly IXP for its area, we might be able to >> obtain enough congruence between geography and topology. But I >> don't expect that any time soon. > > .. IXP does not have to have a monopoly AFAICS, more specifics can be > advertised in every IXP. This assumes there will always be IXPs. Today, the "IXP business model" is a concept of the developed world, and even there it is not relevant when we consider the largest ISPs, for whom peering is most definitely a business decision rather than a technical one. From Kathmandu, Nepal, traffic to India travels to Singapore by satellite, across the pacific to the US, across the US, across the Atlantic, up to another satellite, and down to India. Packets go round the world once and into space twice, despite the fact that Nepal and India share a geopolitical border. Interconnecting countries in South Asia and other developing regions is most definitely a governmental policy issue, and not a technical issue (the technical case for direct interconnection is trivial, and yet there is no direct interconnection). It might take governments twenty years to decide that fibre across the land border is a good idea, or they might not decide to do it at all. Any routing system that relies on (geopolitically) local interconnection better be able to accommodate frequent departures from that model. There are a lot of people in South Asia, and the infrastructure is growing a lot faster than governments are able to think, never mind legislate. Joe From owner-multi6@ops.ietf.org Thu Feb 6 10:47:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23071 for ; Thu, 6 Feb 2003 10:47:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18goH2-0000oP-00 for multi6-data@psg.com; Thu, 06 Feb 2003 07:49:12 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18goGz-0000o8-00 for multi6@ops.ietf.org; Thu, 06 Feb 2003 07:49:09 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h16FmRO86166; Thu, 6 Feb 2003 16:48:27 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 6 Feb 2003 16:48:27 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Savola cc: Subject: Re: comments on draft-py-multi6-gapi-00.txt In-Reply-To: Message-ID: <20030206164708.I61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Feb 2003, Pekka Savola wrote: > What is more troublesome is that the IXP business model must be so that it > has upstream connectivity, and advertises the aggregate to the Internet. What are you talking about??? This statement is incorrect both when applied to the current situation (at least in the parts of the world I'm familiar with) and also when applied to my draft. From owner-multi6@ops.ietf.org Thu Feb 6 11:14:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24132 for ; Thu, 6 Feb 2003 11:14:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18goiS-0002M6-00 for multi6-data@psg.com; Thu, 06 Feb 2003 08:17:32 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18goiO-0002LR-00 for multi6@ops.ietf.org; Thu, 06 Feb 2003 08:17:28 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h16GFUR86215; Thu, 6 Feb 2003 17:15:31 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 6 Feb 2003 17:15:30 +0100 (CET) From: Iljitsch van Beijnum To: Joe Abley cc: Subject: Re: comments on draft-py-multi6-gapi-00.txt In-Reply-To: <526841CD-39E0-11D7-B4A4-00039312C852@automagic.org> Message-ID: <20030206164905.A61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Feb 2003, Joe Abley wrote: > Interconnecting countries in South Asia and other developing regions is > most definitely a governmental policy issue, and not a technical issue > (the technical case for direct interconnection is trivial, and yet > there is no direct interconnection). It might take governments twenty > years to decide that fibre across the land border is a good idea, or > they might not decide to do it at all. Both goverments and business make bad decisions at times. Only governments usually need more time to make them. However, there may not be a technical case for interconnection. Here in the Netherlands around 45% of all traffic is to the US (this includes stuff that is only reachable through the US), 45% is domestic and 10% to the rest of Europe. Obviously these aren't very hard figures, but each time I checked it was pretty close. Under these circumstances it doesn't make much sense for non-huge networks to have direct connections to neighboring countries: reserving some extra capacity on the US link makes much more sense as it is virtually free, no extra effort and better burstability. Now recompute with much higher costs for links to neighboring countries and lots of government intervention. > Any routing system that relies on (geopolitically) local > interconnection better be able to accommodate frequent departures from > that model. There are a lot of people in South Asia, and the > infrastructure is growing a lot faster than governments are able to > think, never mind legislate. In the US there isn't much local interconnection as not much traffic stays local. In most other countries, much more traffic stays local because the countries are usually simply smaller and because of language barriers. So now we have examples with little local interconnection and examples with little regional interconnection. I'm still waiting for examples of significant internet use with no local OR regional interconnection. Not that any of this is of practical importance with regard to the decisions we are facing. From owner-multi6@ops.ietf.org Thu Feb 6 14:27:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01118 for ; Thu, 6 Feb 2003 14:27:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18grhG-000Des-00 for multi6-data@psg.com; Thu, 06 Feb 2003 11:28:30 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18grhF-000Deg-00 for multi6@ops.ietf.org; Thu, 06 Feb 2003 11:28:29 -0800 Subject: RE: Draft: PI addressing derived from AS numbers Date: Thu, 6 Feb 2003 11:28:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BC7@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Draft: PI addressing derived from AS numbers Thread-Index: AcLNrSHZYFU3x8rTTPOQcmMkT6LHZwAaFD5g From: "Michel Py" To: "Kurt Erik Lindqvist" Cc: X-Spam-Status: No, hits=0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA01118 Kurtis, >> Michel Py wrote: >> Hmmmm, I'm a newcomer but that should not limit me so I want >> the same stuff as the old-timers, and now we have 100 million >> /48s in the global routing table and we're in deep doodoo. > Kurt Erik Lindqvist wrote: > You then need an AS number and to get that you need to have > to upstreams. http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-06.txt This draft is a -06 already. If there is enough lobbying, it will happen. Michel. From owner-multi6@ops.ietf.org Thu Feb 6 14:45:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01731 for ; Thu, 6 Feb 2003 14:45:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gs0z-000Evd-00 for multi6-data@psg.com; Thu, 06 Feb 2003 11:48:53 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18gs0w-000EvF-00 for multi6@ops.ietf.org; Thu, 06 Feb 2003 11:48:50 -0800 Subject: RE: comments on draft-py-multi6-gapi-00.txt Date: Thu, 6 Feb 2003 11:48:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BC9@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: comments on draft-py-multi6-gapi-00.txt Thread-Index: AcLN7dRSPFqucefHRNCR83Dh9niesgAKUO4w From: "Michel Py" To: "Joe Abley" Cc: X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA01731 Joe, > Joe Abley wrote: > From Kathmandu, Nepal, traffic to India travels to Singapore > by satellite, across the pacific to the US, across the US, > across the Atlantic, up to another satellite, and down to > India. Packets go round the world once and into space twice, > despite the fact that Nepal and India share a geopolitical > border. "Scenic routing" is what we call it. This is very true, but the draft does not make any assumptions on fiber plant or backbone topology, nor about where IXs are located nor what the aggregation mechanism is (or if it does, please quote specifics). Michel. From owner-multi6@ops.ietf.org Thu Feb 6 15:24:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02948 for ; Thu, 6 Feb 2003 15:24:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gsck-000HeK-00 for multi6-data@psg.com; Thu, 06 Feb 2003 12:27:54 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18gsce-000He6-00 for multi6@ops.ietf.org; Thu, 06 Feb 2003 12:27:49 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h16KRjY23444; Thu, 6 Feb 2003 22:27:45 +0200 Date: Thu, 6 Feb 2003 22:27:44 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: comments on draft-py-multi6-gapi-00.txt In-Reply-To: <20030206164708.I61596-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Feb 2003, Iljitsch van Beijnum wrote: > On Thu, 6 Feb 2003, Pekka Savola wrote: > > What is more troublesome is that the IXP business model must be so that it > > has upstream connectivity, and advertises the aggregate to the Internet. > > What are you talking about??? > > This statement is incorrect both when applied to the current situation > (at least in the parts of the world I'm familiar with) and also when > applied to my draft. Who will advertise the aggregate for e.g. a country if not the IXP? Why would any ISP do it an attract traffic it gets zero payment for? The only possibility seems to be leaking all the more specifics or the IXP having upstream connectivity? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Feb 6 16:16:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04585 for ; Thu, 6 Feb 2003 16:16:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gtQR-000L85-00 for multi6-data@psg.com; Thu, 06 Feb 2003 13:19:15 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18gtQN-000L7r-00 for multi6@ops.ietf.org; Thu, 06 Feb 2003 13:19:11 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h16LIRo86623; Thu, 6 Feb 2003 22:18:27 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 6 Feb 2003 22:18:27 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Savola cc: Subject: Re: comments on draft-py-multi6-gapi-00.txt In-Reply-To: Message-ID: <20030206220117.A61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Feb 2003, Pekka Savola wrote: > > On Thu, 6 Feb 2003, Pekka Savola wrote: > > > What is more troublesome is that the IXP business model must be so that it > > > has upstream connectivity, and advertises the aggregate to the Internet. > > What are you talking about??? > Who will advertise the aggregate for e.g. a country if not the IXP? Why > would any ISP do it an attract traffic it gets zero payment for? Excellent point. From the draft: "Note that this behavior is completely hidden from the peer: the aggregates are only used within the local network, they are not announced to peers. To avoid confusion with regular provider aggregatable routes, the term "pilot routes" will be used for this type of private aggregates." Simply reading the draft will clear up most (all?) of this confusion. It's 10 pages, so this should be doable: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-00.txt (Note that the term IX doesn't even appear in the draft.) From owner-multi6@ops.ietf.org Fri Feb 7 08:02:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08426 for ; Fri, 7 Feb 2003 08:02:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18h8An-0006nf-00 for multi6-data@psg.com; Fri, 07 Feb 2003 05:04:05 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 18h8Ah-0006nJ-00 for multi6@ops.ietf.org; Fri, 07 Feb 2003 05:03:59 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h17D3tlo025294 for ; Fri, 7 Feb 2003 14:03:56 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h17D3t4e132750 for ; Fri, 7 Feb 2003 14:03:55 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48136 from ; Fri, 7 Feb 2003 14:03:55 +0100 Message-Id: <3E43AE8B.B187DF6A@hursley.ibm.com> Date: Fri, 07 Feb 2003 14:03:07 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 Cc: multi6@ops.ietf.org Subject: Re: comments on draft-py-multi6-gapi-00.txt References: <20030206164905.A61596-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=MISSING_HEADERS,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On Thu, 6 Feb 2003, Joe Abley wrote: > > > Interconnecting countries in South Asia and other developing regions is > > most definitely a governmental policy issue, and not a technical issue > > (the technical case for direct interconnection is trivial, and yet > > there is no direct interconnection). It might take governments twenty > > years to decide that fibre across the land border is a good idea, or > > they might not decide to do it at all. > > Both goverments and business make bad decisions at times. Only > governments usually need more time to make them. > > However, there may not be a technical case for interconnection. Here in > the Netherlands around 45% of all traffic is to the US (this includes > stuff that is only reachable through the US), 45% is domestic and 10% to > the rest of Europe. Obviously these aren't very hard figures, but each > time I checked it was pretty close. Under these circumstances it doesn't > make much sense for non-huge networks to have direct connections to > neighboring countries: reserving some extra capacity on the US link > makes much more sense as it is virtually free, no extra effort and > better burstability. Now recompute with much higher costs for links to > neighboring countries and lots of government intervention. > > > Any routing system that relies on (geopolitically) local > > interconnection better be able to accommodate frequent departures from > > that model. There are a lot of people in South Asia, and the > > infrastructure is growing a lot faster than governments are able to > > think, never mind legislate. > > In the US there isn't much local interconnection as not much traffic > stays local. In most other countries, much more traffic stays local > because the countries are usually simply smaller and because of language > barriers. So now we have examples with little local interconnection and > examples with little regional interconnection. I'm still waiting for > examples of significant internet use with no local OR regional > interconnection. > > Not that any of this is of practical importance with regard to the > decisions we are facing. On the contrary, it all illustrates that there are very limited economic forces driving the topology towards geographically-based interconnects. In fact, we basically don't understand what caused the various kinks in the bgp.potaroo.net curve, except for the one at 20k announcements (i.e. the BGP4 switch on). I can't disagree with the assertion that *if* we start handing out PI prefixes, a loosely geographical or metro-based solution is probably better than random numbers. But until we actually know how PI prefixes are going to become routeable without creating a swamp, I'd rather sit on my hands. Brian From owner-multi6@ops.ietf.org Fri Feb 7 12:46:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16468 for ; Fri, 7 Feb 2003 12:46:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hCb6-000K10-00 for multi6-data@psg.com; Fri, 07 Feb 2003 09:47:32 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18hCb2-000K0o-00 for multi6@ops.ietf.org; Fri, 07 Feb 2003 09:47:28 -0800 Subject: RE: comments on draft-py-multi6-gapi-00.txt Date: Fri, 7 Feb 2003 09:47:25 -0800 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5B9B0@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: comments on draft-py-multi6-gapi-00.txt Thread-Index: AcLOquVRLoASkSTYTUO6WMyDu2MW1wAIx1zQ From: "Michel Py" To: "Brian Carpenter" Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16468 > Brian E Carpenter wrote: > I can't disagree with the assertion that *if* we start > handing out PI prefixes, a loosely geographical or > metro-based solution is probably better than random > numbers. Anything is better than random numbers. Even if the geographical aggregation brings only a reduction in half of the routing table, that would be a gain. And *if* we need to go that way, it would then make sense to limit the initial allocation to ASN holders as per Pekka's idea, but out of an addressing plan that has some aggregation potential. > But until we actually know how PI prefixes are going > to become routeable without creating a swamp, I'd > rather sit on my hands. Agree. Michel. From owner-multi6@ops.ietf.org Fri Feb 7 21:58:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28930 for ; Fri, 7 Feb 2003 21:58:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hLEq-000NWW-00 for multi6-data@psg.com; Fri, 07 Feb 2003 19:01:08 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18hLEm-000NWJ-00 for multi6@ops.ietf.org; Fri, 07 Feb 2003 19:01:04 -0800 Subject: RE: comments on draft-py-multi6-gapi-00.txt Date: Fri, 7 Feb 2003 19:01:03 -0800 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5B9B9@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: comments on draft-py-multi6-gapi-00.txt Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Index: AcLN0JWhzG0qZ4luRbCvbD/zRGV/PAARMDVg From: "Michel Py" To: "Brian Carpenter" Cc: X-Spam-Status: No, hits=1.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA28930 Brian, > Brian E Carpenter wrote: > Can't we just accept that only a two-layer solution that > separates identfier-addresses from locator-addresses can > solve this puzzle, and move on to figure out the two-layer > solution? I would not mind at all! 8-))))) However, looking pragmatically at the situation may put a grain of salt into this. First, I will point out that this WG has not produced jack since its inception. A year ago, when I was whining about deadlines and asking how many YEARS behind schedule we needed to be before someone finally sticks their head out of their @55, I was labeled "hysteric". Well, 12 more months have passed and we still are nowhere. Kudos to Joe Abley for trying, but no cigar for the WG. AS of today, this WG is not even looking at solutions; I don't see how it could make the decision to move on studying ID/LOC solutions out of the blue. I think this is beside the point anyway. When, less than a year ago, out of frustration about this WG not going anywhere, I founded ipv6mh, the temptation of making it a MHAP-only list was great. Instead, I chose the path to open it to host solutions and to solutions close to PI such as GFN. In the past year, I have mostly worked on anything but my own draft, and I don't regret it. We have produced GAPI and there are ideas in it that came from the GFN part that will benefit MHAP. The way ipv6mh works is that we look at multiple solutions, cannibalize the parts we like and try to do something with them. Not including some solutions might make us miss something. Michel. From owner-multi6@ops.ietf.org Sat Feb 8 18:45:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03688 for ; Sat, 8 Feb 2003 18:45:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hefN-000OvK-00 for multi6-data@psg.com; Sat, 08 Feb 2003 15:45:49 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18hefI-000Ov8-00 for multi6@ops.ietf.org; Sat, 08 Feb 2003 15:45:45 -0800 Received: from muada.com (torreya.muada.com [213.156.3.174]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h18Nj2E92861 for ; Sun, 9 Feb 2003 00:45:02 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 9 Feb 2003 00:35:43 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v551) Subject: Re: comments on draft-py-multi6-gapi-00.txt From: Iljitsch van Beijnum To: Brian E Carpenter Message-Id: <424713AE-3BBF-11D7-8E31-000393C52D28@muada.com> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-3.6 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, feb 7, 2003, at 14:03 Europe/Amsterdam, Brian E Carpenter wrote: >> I'm still waiting for examples of significant internet use with no >> local OR regional interconnection. >> Not that any of this is of practical importance with regard to the >> decisions we are facing. > On the contrary, it all illustrates that there are very limited > economic forces driving the topology towards geographically-based > interconnects. Ok. Suppose the unthinkable happens and all major networks decide to interconnect in just a single location. Let's also suppose the number of multihomers has inflated the routing table to about 10 times the size a router can handle. This can still be solved as per the provider-internal aggregation draft by simply installing 10 routers that all handle 1/10th of the routing table. In this case, the geographic component buys us nothing. But it doesn't hurt, either. From owner-multi6@ops.ietf.org Mon Feb 10 02:22:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28008 for ; Mon, 10 Feb 2003 02:22:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18i8Hy-000GlF-00 for multi6-data@psg.com; Sun, 09 Feb 2003 23:23:38 -0800 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18i8Fs-000GiQ-00 for multi6@ops.ietf.org; Sun, 09 Feb 2003 23:23:35 -0800 Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h181CcL20693 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 7 Feb 2003 20:12:39 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h181CaFZ013110 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 7 Feb 2003 20:12:38 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h181Caao013106; Fri, 7 Feb 2003 20:12:36 -0500 Message-Id: <200302080112.h181Caao013106@marajade.sandelman.ottawa.on.ca> To: Pekka Savola CC: multi6@ops.ietf.org Subject: Re: comments on draft-py-multi6-gapi-00.txt In-reply-to: Your message of "Thu, 06 Feb 2003 16:02:26 +0200." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 20:12:35 -0500 From: Michael Richardson X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Savola writes: Pekka> I'd like to expand on one particular point: Pekka> On Thu, 6 Feb 2003, Brian E Carpenter wrote: >> If we could pass a law that every local government in the world had to >> set up a monopoly IXP for its area, we might be able to obtain enough >> congruence between geography and topology. But I don't expect that any >> time soon. Pekka> .. IXP does not have to have a monopoly AFAICS, more specifics can Pekka> be advertised in every IXP. Pekka> What is more troublesome is that the IXP business model must be so Pekka> that it has upstream connectivity, and advertises the aggregate to Pekka> the Internet. And that the IXP has sufficient redundancy so Pekka> people would not have to work around its back.. Yes. The key is that the amount of bandwidth can be limited if the traffic has to move to a PA address. The ideal way is that every ISP that peers at such an IXP advertises this aggregate. The potential to abuse such an advertisement must be dealt with. Maybe by making the MTU very low... 90 bytes maybe, and rate limiting by destination address. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkRZgYqHRg3pndX9AQHOxQP+K77Hf5EfqKwncCahwlWVnq1abHmp8oim 7Ctytj0fMU2VCWl4kgDf2GVyqlxH6tTtHDBH6fyn5EWHTbp0coJjOdXi2eaWYMvA baifbSnb7J4O14c6I+Pdz4sIkcJVDZ3ycCXsDcV1X32E1oHjJA1/zoyeF+QgJWll lcH34nORdVw= =Eu4o -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 10 02:24:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28060 for ; Mon, 10 Feb 2003 02:24:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18i8M9-000Gtp-00 for multi6-data@psg.com; Sun, 09 Feb 2003 23:27:57 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18i8M6-000GtD-00 for multi6@ops.ietf.org; Sun, 09 Feb 2003 23:27:54 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1A7Rjw22805; Mon, 10 Feb 2003 09:27:46 +0200 Date: Mon, 10 Feb 2003 09:27:45 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: comments on draft-py-multi6-gapi-00.txt In-Reply-To: <20030206220117.A61596-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Feb 2003, Iljitsch van Beijnum wrote: > On Thu, 6 Feb 2003, Pekka Savola wrote: > > > > On Thu, 6 Feb 2003, Pekka Savola wrote: > > > > What is more troublesome is that the IXP business model must be so that it > > > > has upstream connectivity, and advertises the aggregate to the Internet. > > > > What are you talking about??? > > > Who will advertise the aggregate for e.g. a country if not the IXP? Why > > would any ISP do it an attract traffic it gets zero payment for? > > Excellent point. From the draft: "Note that this > behavior is completely hidden from the peer: the aggregates are only > used within the local network, they are not announced to peers. To avoid > confusion with regular provider aggregatable routes, the term "pilot > routes" will be used for this type of private aggregates." > > Simply reading the draft will clear up most (all?) of this confusion. > It's 10 pages, so this should be doable: > > http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-00.txt I'd read it before, but I did not understand certain unstated assumptions. I've glanced through it again. This seems to solve a non-problem, that is, how PI addresses are handled inside an ISP or between its peers. The real problem this does not seem to take a stance on is (but there is some text in section 10, not sure if related), who is advertising the PI routes to the default free zone (or upstreams, in any case)? If these are not aggregates, would explode. If these are aggregates, the upstream and the ISP will have handle traffic that does not belong to it, because by the definition of geoPI addressing, it is not completely aggregatable -- else it would not be useful at all for multihoming etc. purposes. I guess the goal(s) of the draft should be stated as clearly as possible, in the abstract or the introduction section. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Feb 10 03:29:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00093 for ; Mon, 10 Feb 2003 03:29:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18i9MH-000I43-00 for multi6-data@psg.com; Mon, 10 Feb 2003 00:32:09 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18i9MD-000I3r-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 00:32:05 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1A8VLh95498; Mon, 10 Feb 2003 09:31:21 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 10 Feb 2003 09:31:20 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Savola cc: Subject: Re: comments on draft-py-multi6-gapi-00.txt In-Reply-To: Message-ID: <20030210090440.P61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 10 Feb 2003, Pekka Savola wrote: > This seems to solve a non-problem, that is, how PI addresses are handled > inside an ISP or between its peers. > The real problem this does not seem to take a stance on is (but there is > some text in section 10, not sure if related), who is advertising the PI > routes to the default free zone (or upstreams, in any case)? If these are > not aggregates, would explode. I think this point was made clear enough but apparently not. In principle everyone announces all their customer routes to everyone. From a router perspective it is more efficient to decide at the source which routes are announced where, but this assumes that a network always knows where a peer needs this information. This means that if you monitor the global routing table using some kind of route collector you'll see a huge routing table. This can work because networks simply filter out routing information they have no use for at this location. So a router in London ignores routing information for US destinations. Packet for those destinations are sent to a router in the US that in turn has no use for European routes. (Note that this other router belongs to the same AS or a transit ISP.) In other words: because there are no aggregates announced to other networks and more specific routes are ignored to keep the routing tables manageable, networks must transport the traffic to a place in their network where more specific information is known. From owner-multi6@ops.ietf.org Mon Feb 10 08:59:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09155 for ; Mon, 10 Feb 2003 08:59:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iEV2-000PAi-00 for multi6-data@psg.com; Mon, 10 Feb 2003 06:01:32 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iEUz-000PAO-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 06:01:29 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AE2ahE024068; Mon, 10 Feb 2003 15:02:37 +0100 (CET) Date: Mon, 10 Feb 2003 08:07:44 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Pekka Savola , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030204111833.A61596-100000@sequoia.muada.com> Message-Id: <5A4AF4FE-3CC6-11D7-B9E6-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.5 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> - those who already have an AS number, fine-- go for it (these would >> possibly contribute to some 1,000+ routes in IPv6 DFZ, the absolute >> number >> is peanuts, but of course there may be some layer 8 (and up) avalanche >> effects) > > Where do you get this? There are more than 25000 AS numbers out there. > At some point, most of those networks will want to run IPv6. > Just look in Philip Smiths routing summary that are also in my slides from RIPE i Amsterdam and also posted by me here a while ago. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 08:59:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09185 for ; Mon, 10 Feb 2003 08:59:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iEVA-000PB0-00 for multi6-data@psg.com; Mon, 10 Feb 2003 06:01:40 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iEUz-000PAP-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 06:01:29 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AE2chE024071; Mon, 10 Feb 2003 15:02:38 +0100 (CET) Date: Mon, 10 Feb 2003 08:12:05 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Pekka Savola , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030204114445.D61596-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.2 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> There are still over 2^15 AS numbers to waste. Considerably more, >> less >> than a half of about 29K AS numbers are actually even being used.. > > Try to reclaim them... That's very hard. > Nope. And this has been discussed in RIPE over the last year (to do this more effectively ) and is already in place in APNIC I think. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 08:59:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09199 for ; Mon, 10 Feb 2003 08:59:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iEVr-000PCR-00 for multi6-data@psg.com; Mon, 10 Feb 2003 06:02:23 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iEVp-000PCD-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 06:02:21 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AE3LhE024077; Mon, 10 Feb 2003 15:03:25 +0100 (CET) Date: Mon, 10 Feb 2003 09:15:45 +0100 Subject: Re: comments on draft-py-multi6-gapi-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54BB8@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I have gone through the above draft again and started >> thinking. Although the draft as such does not give any >> solution in itself to mulithoming it is part of other >> solutions. I am not convinced it scales though. > > This is irrelevant to the draft, as the scalability comes from the > aggregation model and not from the addressing allocation plan. Out of > the two aggregation schemes that currently use GAPI (MHAP and > isp-int-aggr"GFN"), we know that the aggregation provided by GFN does > not scale that good, but MHAP does (MHAP is a dual-space system and the > GAPI address is the identifier). Well, that is from the point of scaling in number of routes. I am not sure the model as such will work. >> Mainly my concerns are that this is based on statistics. The draft >> says that the options that are available to base this on is geography >> or population. > > It's mostly population. The geography part (such as promoting Hawaii to > the status of "country") is baseline or optimization only. Yes, but there are other alternatives to base this on as well. >> I would add Geopolicy and economics. > > Certainly not, because this will get us into politics. Maybe China will > be capitalist tomorrow, who knows. When I was a young man, the enemy > was > the Soviet Union and people in Berlin were being shot trying to jump > the > wall. Go to Berlin now, it's fortunate that the remains of the wall are > documented because otherwise you would not find them. Gee, maybe in 3 > years the largest concentration of multihomed oil companies will be in > Iraq and the Russians will make their space shuttle fly after they are > done inspecting the heat shield. Who are we to predict the future? And this is the problem. The current model to me does not allocate addresses to where they are used. > In Tony Hain's drafts, a square foot in Kabul gets the same number of > IPv6 addresses than a square foot in Palo Alto; we do the same except > that we do it for people. No politics. If you're not happy with the > numbers, talk to the United Nations Statistics division. Even Tonys allocation would then be better. My problem is not with the population numbers. My problem is that I am not convinced address useage follow population patterns. >> If we take Sweden or Switzerland as examples, these are countries >> with relatively small populations but with a high number of large >> multinationals per capita. Multinationals will have a higher burn >> rate of addresses, especially in multihoming than "ordinary" users >> will. With the GAPI addresses, instead large countries that might >> have a lower order of multihoming is gaining advantage. > > This is true, but we addressed it by having slack at three different > levels. In the absolute, it does not make a difference anyway, because > our base allocation gives an address for four people, and > multinationals > are typically way larger than 4 people. True, but you are then more or less starting to punch holes in the aggregates. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 08:59:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09213 for ; Mon, 10 Feb 2003 08:59:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iEWr-000PEt-00 for multi6-data@psg.com; Mon, 10 Feb 2003 06:03:25 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iEWm-000PEM-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 06:03:21 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AE4UhE024083; Mon, 10 Feb 2003 15:04:31 +0100 (CET) Date: Mon, 10 Feb 2003 09:34:44 +0100 Subject: Re: Comments on draft-van-beijnum-multi6-isp-int-aggr-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030205103321.Y61596-100000@sequoia.muada.com> Message-Id: <817D994B-3CD2-11D7-B9E6-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.3 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> What first strikes me is the complexity of the iBGP and keeping this >> up >> to date. > >> I am not convinced that this is workable from a ISP point of view, > > I agree that it's a hassle, but it's not all that complex. It is > basically similar to running OSPF with area aggregation. Larger ISPs > already have complex BGP setups with route reflectors and/or > confederations and redistribution. This proposal is on the same level > of > complexity. > > What do you mean by keeping it up to date? Well, ISPs and large enterprises normally use some form of policy routing, even if it being hot-potato. With this, I would most likely need to maintain my iBGP to send traffic to the "right" prefix, via the right exit. Especially if I span several areas. Today this is per peer which is somewhat simpler. >> but >> I want to think that over more. I am also not sure how "extras" in BGP >> (which I am not sure should be there in the first place) such as >> multicast and VPN information, would work. > > Multicast uses a separate routing table so there shouldn't be any > impact. VPN is not a part of regular BGP. True, but it is still in use. As for multicast you still need to find the next-hop information for PIM you need to do the RPF. >> Another problem I see is that this requires networks that logically >> map >> fairly well into the physical topology, or even small networks gets >> complicated. > > Small networks are unlikely to use internal aggregation: it's more > likely they'll just send traffic for certain regions (where they are > not > present themselves) to their upstream ISPs. Yes, but what if I cover several regions? I.e I am not a small network? >> This means that the MPLS crowd will have a problem (hey - >> maybe I do like this proposal! :) ), but so will also corporations >> that >> have few branch offices across the world connected with a IP-VPN or >> slow speed links. > > I'm not sure what kind of problem you see here. I am unfamiliar with > the > way MPLS is really deployed in networks so I can't say anything about > that except that if the worst part about this protocol is that it makes > it impossible to provide integrated IP and MPLS services I can live > with that: just de-integrate them. Agreed. From what I know many people have deployed more or less full meshed networks with MPLS. >> Last, what worries me the most is the security considerations. A >> failure on filtering, or in routing configuration will make the AS7777 >> incident seem like trivial. > > No. Uhm, why not? > >> This is not even in the security considerations section. It should be. > > No. > Why not? - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 09:00:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09229 for ; Mon, 10 Feb 2003 08:59:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iEUl-000PAL-00 for multi6-data@psg.com; Mon, 10 Feb 2003 06:01:15 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iEUh-000PA6-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 06:01:12 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AE2DhE024062; Mon, 10 Feb 2003 15:02:13 +0100 (CET) Date: Mon, 10 Feb 2003 08:01:36 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030204102330.L61596-100000@sequoia.muada.com> Message-Id: <7EB70FF1-3CC5-11D7-B9E6-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.2 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> - AS numbers being extended to 32 bits. Then people that get ASNs >>> above >>> 64k will also strongly lobby to get PI on the grounds that it's not >>> fair that early adopters only get it. > >> It's still a size we can handle. > > 32 bits??? I don't think so... This again depends on the timeline. As there is also a cost involved I still don't believe that we will have a billion multihomed networks tomorrow. sorry, >>> If we had no other choice, I would support this as being not as bad >>> as >>> unrestricted PI. But it's still unaggregatable, and we do have a >>> better >>> choice: GAPI. > >> It's fast and it works. Go for it. > > I hope you're talking about GAPI here. I am not. > The whole ASN == PI thing doesn't work because every multihomer can get > an AS number so every multihomer can get PI space so we're right back > at > square one. Yes. But it works. We know the dangers. And we can control it. > A much better way to do this would be to take the globally unique site > local addresses for this. We can give two blocks of globally unique > site ...which breaks a lot of current applications. > whatever, all bets are off and either we have built some MHAP-like > mechanism to map from these PI addresses to PA addresses or we admit > failure and go back to v4. Or we assign these addresses geographically > Currently we won't get to v6 because it is broken and does not provide the functionality needed. We need time and a new design. There, I have said the magic word :). Global aggregation etc to me is starting to feel like a lot of ductape. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 09:00:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09261 for ; Mon, 10 Feb 2003 09:00:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iEWr-000PF0-00 for multi6-data@psg.com; Mon, 10 Feb 2003 06:03:25 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iEWo-000PEf-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 06:03:23 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AE4XhE024086; Mon, 10 Feb 2003 15:04:33 +0100 (CET) Date: Mon, 10 Feb 2003 09:37:27 +0100 Subject: Re: comments on draft-py-multi6-gapi-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030205104746.D61596-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.3 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> You can also argue that address consumption will most likely NOT >> follow >> geographic boundaries. If I take Stockholm, Ericsson for example have >> their HQ in a relatively unpopulated area. Also the "swedish silicon >> valley" have a high number of multinationals that will want to >> mulithome, but relatively small population. > > I'm sure address consumption won't follow the population spread. > However, there is only one other objective way of pre-allocating > address > space: on geography. This both wastes a lot of address space and fails > to provide enough of it. In the end, it all comes down to people: they > own/operate equipment that needs to be connected over multiple lines. > I'm sure many more people own or run a multihomed network in the > Swedish silicon valley than in a rural province of China, but the gain > you get from allocating less for China is much smaller than the hassle > of having to manually look at it and justify your decision. The problem is how you make sure you get enough addresses where they are needed, without having to reallocate space. > - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 09:01:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09308 for ; Mon, 10 Feb 2003 09:01:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iEYO-000PIR-00 for multi6-data@psg.com; Mon, 10 Feb 2003 06:05:00 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iEYL-000PID-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 06:04:57 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AE65hE024103; Mon, 10 Feb 2003 15:06:05 +0100 (CET) Date: Mon, 10 Feb 2003 11:57:51 +0100 Subject: Re: comments on draft-py-multi6-gapi-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Joe Abley , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030205214018.M61596-100000@sequoia.muada.com> Message-Id: <7FA2816F-3CE6-11D7-B9E6-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.3 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Given such a turbulent soup of connectedness, what criteria for >> pre-allocation of routing names stands a chance of not being >> out-of-date as soon as it is published? > > Let's take the speed of light for this. You can change many things > about > your network, but not the fact that making packets take a 10000 km > detour adds a 50 ms delay. Also, if you're going to physically move > your > network renumbering is only a minor extra task in addition to > everything > else that's going on. I was part of doing one of the largest network mergers ever. I am glad we didn't have to worry more about renumbering that what we already had. You don't want to renumber as well as merge routing. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 09:02:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09381 for ; Mon, 10 Feb 2003 09:02:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iEZO-000PMG-00 for multi6-data@psg.com; Mon, 10 Feb 2003 06:06:02 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iEZJ-000PM0-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 06:05:58 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AE73hE024124; Mon, 10 Feb 2003 15:07:04 +0100 (CET) Date: Mon, 10 Feb 2003 12:41:48 +0100 Subject: Re: comments on draft-py-multi6-gapi-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Joe Abley , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030206164905.A61596-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > However, there may not be a technical case for interconnection. Here in > the Netherlands around 45% of all traffic is to the US (this includes > stuff that is only reachable through the US), 45% is domestic and 10% > to > the rest of Europe. Obviously these aren't very hard figures, but each From KPNQwest we saw traffic that was 50% national, 30% regional and the rest US based. At least for the larger language regions, CH, AT & DE + NO, SE & DK. BE + FR showed similar patterns. > time I checked it was pretty close. Under these circumstances it > doesn't > make much sense for non-huge networks to have direct connections to > neighboring countries: reserving some extra capacity on the US link > makes much more sense as it is virtually free, no extra effort and > better burstability. Now recompute with much higher costs for links to > neighboring countries and lots of government intervention. Actually this is most likely the largest network mistakes made. KQ was one of few operators who actually could move traffic on the same DWDM systems inside a language region in Europe. This helped us a lot with designing our IP network. I know other carriers that had to send traffic from Stockholm to Oslo via Amsterdam. That does not scale. > In the US there isn't much local interconnection as not much traffic > stays local. In most other countries, much more traffic stays local Huh? > because the countries are usually simply smaller and because of > language > barriers. So now we have examples with little local interconnection and > examples with little regional interconnection. I'm still waiting for > examples of significant internet use with no local OR regional > interconnection See Joes India/Nepal example. > Not that any of this is of practical importance with regard to the > decisions we are facing. > It will/might impact routing models. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 09:02:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09397 for ; Mon, 10 Feb 2003 09:02:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iEZZ-000PN4-00 for multi6-data@psg.com; Mon, 10 Feb 2003 06:06:13 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iEZX-000PMe-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 06:06:11 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AE7JhE024127; Mon, 10 Feb 2003 15:07:20 +0100 (CET) Date: Mon, 10 Feb 2003 12:45:22 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54BC7@server2000.arneill-py.sacramento.ca.us> Message-Id: <22DC86E5-3CED-11D7-B9E6-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Hmmmm, I'm a newcomer but that should not limit me so I want >>> the same stuff as the old-timers, and now we have 100 million >>> /48s in the global routing table and we're in deep doodoo. > >> Kurt Erik Lindqvist wrote: >> You then need an AS number and to get that you need to have >> to upstreams. > > http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-06.txt > > This draft is a -06 already. If there is enough lobbying, it will > happen. You still need two upstreams == money. Just because we increase the number of ASes available doesn't mean that we will get lower transit prices. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 09:05:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09510 for ; Mon, 10 Feb 2003 09:04:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iEbk-000PSy-00 for multi6-data@psg.com; Mon, 10 Feb 2003 06:08:28 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iEbh-000PSc-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 06:08:25 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AE9YhE024147; Mon, 10 Feb 2003 15:09:34 +0100 (CET) Date: Mon, 10 Feb 2003 09:08:34 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5B98B@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> So, if all had a IPv6 delegation, we would have 14519 routes, >> of which 12614 would be multihomed. Compared to 120k. > > I agree that 12k routes is nothing we have to care about, but this is > not the point. The point is that if we start this, it will be > impossible > to stop. I disagree. We know how it works and we have learnt how to control it. But we need a solution that is quick. > No to the IPv6 swamp! I will start to worry when we hit 1k routes in IPv6. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 09:57:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11167 for ; Mon, 10 Feb 2003 09:57:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iFPh-0000vf-00 for multi6-data@psg.com; Mon, 10 Feb 2003 07:00:05 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #1) id 18iFPa-0000uk-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 07:00:00 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1AEx389040634; Mon, 10 Feb 2003 15:59:04 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1AEwvYe028820; Mon, 10 Feb 2003 15:58:58 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA24946 from ; Mon, 10 Feb 2003 15:58:52 +0100 Message-Id: <3E47BDFC.64D82B03@hursley.ibm.com> Date: Mon, 10 Feb 2003 15:58:04 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Kurt Erik Lindqvist Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers References: <7EB70FF1-3CC5-11D7-B9E6-000393AB1404@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist wrote: > ... > > > whatever, all bets are off and either we have built some MHAP-like > > mechanism to map from these PI addresses to PA addresses or we admit > > failure and go back to v4. Or we assign these addresses geographically > > > > Currently we won't get to v6 because it is broken and does not provide > the functionality needed. Think carefully before you write things that the IPv6-haters might misuse. The reason we have this WG is to work towards solutions for one thing that IPv6 with PA addresses doesn't fix in the IPv4 model. For whatever reason, we can't get past the problem statement stage, but it really isn't going to advance things to say that IPv6 is "broken" when the reality is much deeper than any of the specifics of IPv6. > > We need time and a new design. There, I have said the magic word :). We need, probably, a two layer approach. That has been proposed often enough. We just need to work out which version to use and see how to add it to IPv6. > > Global aggregation etc to me is starting to feel like a lot of ductape. Nobody has explained how we can have log scale tables and real time convergence times without aggregation. Brian From owner-multi6@ops.ietf.org Mon Feb 10 10:31:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12366 for ; Mon, 10 Feb 2003 10:31:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iFwx-0001qI-00 for multi6-data@psg.com; Mon, 10 Feb 2003 07:34:27 -0800 Received: from smtp1.extremenetworks.com ([216.52.8.6]) by psg.com with esmtp (Exim 3.36 #1) id 18iFwu-0001q6-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 07:34:24 -0800 Received: from extremenetworks.com (unknown [10.18.3.100]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 1D0107940; Mon, 10 Feb 2003 07:34:22 -0800 (PST) Date: Mon, 10 Feb 2003 10:34:22 -0500 Subject: Architectural limitations of our routing architecture Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: RJ Atkinson In-Reply-To: <3E47BDFC.64D82B03@hursley.ibm.com> Message-Id: <20A1CD7A-3D0D-11D7-BD0E-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Feb 10, 2003, at 09:58 America/Montreal, Brian E Carpenter wrote: > Kurt Erik Lindqvist wrote: >> Currently we won't get to v6 because it is broken and does not provide >> the functionality needed. > > Think carefully before you write things that the IPv6-haters might > misuse. > > The reason we have this WG is to work towards solutions for one > thing that IPv6 with PA addresses doesn't fix in the IPv4 model. > For whatever reason, we can't get past the problem statement stage, > but it really isn't going to advance things to say that IPv6 > is "broken" when the reality is much deeper than any of the > specifics of IPv6. I'll try an alternate phrasing, which is one I happen to believe: The routing architecture shared by IPv4 and IPv6 is broken at least with respect to mobility and to multi-homing. Mobility needs to be to be a first-order property of the routing architecture, not an awkward hack add-on with limited deployability. Multi-homing also needs to be supported as a first-order property of the routing architecture. This means that multi-homing needs to be supported in a manner that scales to global IP network sizes well beyond the size of today's deployed Internet. Multihoming a given site ought not need to be known or visible in the default-free-zone of an ISP that is not directly connected to that multi-homed site. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Mon Feb 10 11:12:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13851 for ; Mon, 10 Feb 2003 11:12:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iGaD-0002vu-00 for multi6-data@psg.com; Mon, 10 Feb 2003 08:15:01 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18iGaA-0002vL-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 08:14:58 -0800 Subject: RE: comments on draft-py-multi6-gapi-00.txt Date: Mon, 10 Feb 2003 08:14:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54BDC@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message Thread-Topic: comments on draft-py-multi6-gapi-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Index: AcLRDQbeLVlrrmsjSpaCa+sDRnmdDQADgzng From: "Michel Py" To: "Kurt Erik Lindqvist" Cc: X-Spam-Status: No, hits=0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA13851 Kurtis, >> Kurt Erik Lindqvist >> It's mostly population. The geography part (such as >> promoting Hawaii to the status of "country") is baseline >> or optimization only. > Yes, but there are other alternatives to base this on as well. Such as? > My problem is not with the population numbers. My problem is > that I am not convinced address useage follow population patterns. It does not follow GPS coordinates either, especially when 70% of the surface of the earth is oceans. Have any better idea? A scalable one, I mean. We want to hear it. > Even Tonys allocation would then be better. Sure, with 12 bits more I can do a lot better too. >> .. having slack at three different levels. In the absolute, >> it does not make a difference anyway, because our base >> allocation gives an address for four people, and >> multinationals are typically way larger than 4 people. > True, but you are then more or less starting to punch holes > in the aggregates. It does not matter to MHAP. It would matter to GFN but when reaching this kind of numbers, MHAP would have been rolled out and GFN phased out anyway. > You still need two upstreams == money. > Just because we increase the number of ASes available doesn't > mean that we will get lower transit prices. Transit is dirt cheap already. I have plenty of small customers that don't even have a T1 that would pay $200 more per month to be multihomed, because they are running their credit card over the internet. 1 hour of downtime pays for it, a no-brainer. >> I agree that 12k routes is nothing we have to care about, but >> this is not the point. The point is that if we start this, it >> will be impossible to stop. > I disagree. We know how it works and we have learnt how to control > it. But we need a solution that is quick. I have one for you: IPv4. Michel. From owner-multi6@ops.ietf.org Mon Feb 10 11:19:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14138 for ; Mon, 10 Feb 2003 11:19:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iGhW-0003AU-00 for multi6-data@psg.com; Mon, 10 Feb 2003 08:22:34 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18iGhS-0003AB-00; Mon, 10 Feb 2003 08:22:31 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18iGhQ-000A4Y-00; Mon, 10 Feb 2003 11:22:28 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 10 Feb 2003 11:22:27 -0500 To: RJ Atkinson Cc: Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Architectural limitations of our routing architecture References: <3E47BDFC.64D82B03@hursley.ibm.com> <20A1CD7A-3D0D-11D7-BD0E-00039357A82A@extremenetworks.com> Message-Id: X-Spam-Status: No, hits=-0.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The routing architecture shared by IPv4 and IPv6 is broken at least with > respect to mobility and to multi-homing. perhaps these consderations were not taken into account in the original designs, and hence may deserve a kinder phrasing than "broken" > Multihoming a given site ought not need to be known or visible in the > default-free-zone of an ISP that is not directly connected to that > multi-homed site. as this is not intuitively obvious, it needs motivation/justification randy From owner-multi6@ops.ietf.org Mon Feb 10 11:38:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14824 for ; Mon, 10 Feb 2003 11:38:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iGzY-0003pz-00 for multi6-data@psg.com; Mon, 10 Feb 2003 08:41:12 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iGzU-0003pg-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 08:41:08 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AGgJhE024246; Mon, 10 Feb 2003 17:42:19 +0100 (CET) Date: Mon, 10 Feb 2003 17:42:18 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3E47BDFC.64D82B03@hursley.ibm.com> Message-Id: <9E36071E-3D16-11D7-874A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> whatever, all bets are off and either we have built some MHAP-like >>> mechanism to map from these PI addresses to PA addresses or we admit >>> failure and go back to v4. Or we assign these addresses >>> geographically >>> >> >> Currently we won't get to v6 because it is broken and does not provide >> the functionality needed. > > Think carefully before you write things that the IPv6-haters might > misuse. Well, unless we fixes the problems at hand - they will be right. And unless we starting "facing the truth" - they will be right. > The reason we have this WG is to work towards solutions for one > thing that IPv6 with PA addresses doesn't fix in the IPv4 model. > For whatever reason, we can't get past the problem statement stage, > but it really isn't going to advance things to say that IPv6 Well, unless we soon get forward, the IPv6 effort will have been wasted. You won't get enterprises to IPv6 without a solution to multi6, and with no enterprises there is no revenue for the ISPs, with no revenue for the ISPs they won't deploy IPv6. It's as simple as that. > is "broken" when the reality is much deeper than any of the > specifics of IPv6. Agreed. >> We need time and a new design. There, I have said the magic word :). > > We need, probably, a two layer approach. That has been proposed > often enough. We just need to work out which version to use > and see how to add it to IPv6. Agreed. >> Global aggregation etc to me is starting to feel like a lot of >> ductape. > > Nobody has explained how we can have log scale tables and real time > convergence times without aggregation. > I miswrote the above. I meant Geo aggregation. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 11:57:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15585 for ; Mon, 10 Feb 2003 11:57:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iHIo-0004Xp-00 for multi6-data@psg.com; Mon, 10 Feb 2003 09:01:06 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iHIk-0004XE-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 09:01:02 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AH29hE024249; Mon, 10 Feb 2003 18:02:10 +0100 (CET) Date: Mon, 10 Feb 2003 18:02:08 +0100 Subject: Re: comments on draft-py-multi6-gapi-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54BDC@server2000.arneill-py.sacramento.ca.us> Message-Id: <6371028D-3D19-11D7-874A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Kurt Erik Lindqvist >>> It's mostly population. The geography part (such as >>> promoting Hawaii to the status of "country") is baseline >>> or optimization only. > >> Yes, but there are other alternatives to base this on as well. > > Such as? Current useage? I would ofcourse rather go for the new routing model and just go for swap space in the mean time. >>> I agree that 12k routes is nothing we have to care about, but >>> this is not the point. The point is that if we start this, it >>> will be impossible to stop. > >> I disagree. We know how it works and we have learnt how to control >> it. But we need a solution that is quick. > > I have one for you: IPv4. > ...and that is what people are doing. Ever thought why there is 350 routes in the IPv6 DFZ and 120k in the IPv4 DFZ? I say go for something we knows how it works and what the limitations are while we work out a solution with layers. Best regards, - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 12:00:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15697 for ; Mon, 10 Feb 2003 12:00:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iHLp-0004e3-00 for multi6-data@psg.com; Mon, 10 Feb 2003 09:04:13 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18iHLk-0004dJ-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 09:04:08 -0800 Subject: RE: comments on draft-py-multi6-gapi-00.txt Date: Mon, 10 Feb 2003 09:04:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5B9D5@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message Thread-Topic: comments on draft-py-multi6-gapi-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Index: AcLRJf0jtoH3lxmvQGOrK9wZSwLLKwAABvPQ From: "Michel Py" To: "Kurt Erik Lindqvist" Cc: X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA15697 >>> Yes, but there are other alternatives to base this on as well. >> Such as? > Current useage? Completely meaningless. In another window, I am discussing teaching arrangements in China. If you base on current usage, China would get 1/100th of what they need at some point. This is not the right thing to do. Michel. From owner-multi6@ops.ietf.org Mon Feb 10 12:14:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16264 for ; Mon, 10 Feb 2003 12:14:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iHZE-0005Gw-00 for multi6-data@psg.com; Mon, 10 Feb 2003 09:18:04 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18iHZB-0005Gg-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 09:18:02 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1AHJBhE024257; Mon, 10 Feb 2003 18:19:11 +0100 (CET) Date: Mon, 10 Feb 2003 18:19:11 +0100 Subject: Re: comments on draft-py-multi6-gapi-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5B9D5@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>> Yes, but there are other alternatives to base this on as well. > >>> Such as? > >> Current useage? > > Completely meaningless. In another window, I am discussing teaching > arrangements in China. If you base on current usage, China would get > 1/100th of what they need at some point. This is not the right thing to > do. > so give them more? - kurtis - From owner-multi6@ops.ietf.org Mon Feb 10 12:16:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16336 for ; Mon, 10 Feb 2003 12:16:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iHan-0005It-00 for multi6-data@psg.com; Mon, 10 Feb 2003 09:19:41 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18iHak-0005If-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 09:19:38 -0800 Subject: RE: comments on draft-py-multi6-gapi-00.txt Date: Mon, 10 Feb 2003 09:19:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5B9D7@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message Thread-Topic: comments on draft-py-multi6-gapi-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Index: AcLRKFzIsYmwdzkhTV2P87mSlIo1PAAADJmA From: "Michel Py" To: "Kurt Erik Lindqvist" Cc: X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16336 >> Kurt Erik Lindqvist wrote: >> Current useage? > Michel Py wrote: > Completely meaningless. In another window, I am discussing > teaching arrangements in China. If you base on current usage, > China would get 1/100th of what they need at some point. This > is not the right thing to do. Based on what? Population, maybe? Michel. From owner-multi6@ops.ietf.org Mon Feb 10 14:43:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22320 for ; Mon, 10 Feb 2003 14:43:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iJs5-000B9r-00 for multi6-data@psg.com; Mon, 10 Feb 2003 11:45:41 -0800 Received: from smtp1.extremenetworks.com ([216.52.8.6]) by psg.com with esmtp (Exim 3.36 #1) id 18iJs1-000B9f-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 11:45:37 -0800 Received: from extremenetworks.com (unknown [10.18.3.100]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 50CC37940 for ; Mon, 10 Feb 2003 11:45:36 -0800 (PST) Date: Mon, 10 Feb 2003 14:45:37 -0500 Subject: Re: Architectural limitations of our routing architecture Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: RJ Atkinson To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <39EAE960-3D30-11D7-BD0E-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Feb 10, 2003, at 11:22 America/Montreal, Randy Bush wrote: >> The routing architecture shared by IPv4 and IPv6 is broken at least >> with >> respect to mobility and to multi-homing. > > perhaps these consderations were not taken into account in the original > designs, and hence may deserve a kinder phrasing than "broken" Fair. Please substitute "sub-optimal" for broken and accept my apologies for poor wording. >> Multihoming a given site ought not need to be known or visible in the >> default-free-zone of an ISP that is not directly connected to that >> multi-homed site. > > as this is not intuitively obvious, it needs motivation/justification Also fair. RFC-3221 has words on this topic that are far more elegant than my own words could ever be. Thanks, Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Tue Feb 11 00:43:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10059 for ; Tue, 11 Feb 2003 00:43:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iTED-0008Ql-00 for multi6-data@psg.com; Mon, 10 Feb 2003 21:45:09 -0800 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18iTE0-0008Ox-00 for multi6@ops.ietf.org; Mon, 10 Feb 2003 21:45:03 -0800 Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h1818gL20662 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 7 Feb 2003 20:08:43 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h1818eFZ012951 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 7 Feb 2003 20:08:42 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h1818eZM012948 for ; Fri, 7 Feb 2003 20:08:40 -0500 Message-Id: <200302080108.h1818eZM012948@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: comments on draft-py-multi6-gapi-00.txt In-reply-to: Your message of "Thu, 06 Feb 2003 11:59:51 +0100." <3E424027.AD4CEA8@hursley.ibm.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Feb 2003 20:08:39 -0500 From: Michael Richardson X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Brian" == Brian E Carpenter writes: >> ISPs get /19s, /20s and /16s because it is assumed they'll need more >> in the future than the single /24 they're requesting today. This is >> what I mean by pre-allocation. Brian> Yes, but that is in a CIDR context with *topological* aggregation. Brian> You seem to imagine that geographical allocation will somehow Brian> match up with topology and therefore cause aggregation. All Brian> historical evidence suggests otherwise. Brian> If we could pass a law that every local government in the world Brian> had to set up a monopoly IXP for its area, we might be able to For it to be useful, it suffices that *some* local governments will setup such an IXs. Brian> Can't we just accept that only a two-layer solution that separates Brian> identfier-addresses from locator-addresses can solve this puzzle, Brian> and move on to figure out the two-layer solution? I strongly agree with you. I am in favour of a two-layer solution, and am pretty sure that the outer layer will be v6-in-v6 or ESP. GAPI becomes simply *one* way to get a locally controlled number space for the identifier-addresses. MIPv6 can provide a way to map identifiers to locators. If you don't want that, you can use DNS reverse map. (Hey, you can get the nodes' public key along the way and encrypt by default) If not that, then find a new database. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPkRYloqHRg3pndX9AQGUhAP8DLVbE2Sdtiylao7DEuOIZ+rO1fH0KGca kYaIeFUlEMZYhzme+SSqSfYnPjN3i0p1NHP/0KAQf88G2j4YfFZqsU3dGn9vSG4f 3clMRtXt5qyenXqHMQfSGvZqMois7+LGM4dzmL1Ip2rHVSLgOgU1dWRgQ/2h3bII +XYwawdQ5aQ= =MAnP -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Feb 11 06:29:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27782 for ; Tue, 11 Feb 2003 06:29:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iYcm-000LAh-00 for multi6-data@psg.com; Tue, 11 Feb 2003 03:30:52 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18iYcj-000LAR-00 for multi6@ops.ietf.org; Tue, 11 Feb 2003 03:30:49 -0800 Received: from muada.com (torreya.muada.com [213.156.3.174]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1BBU5E98131 for ; Tue, 11 Feb 2003 12:30:06 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 11 Feb 2003 12:29:31 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <16773B63-3DB4-11D7-8427-000393C52D28@muada.com> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, SUBJ_MISSING,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist wrote: > >> It's still a size we can handle. > > > 32 bits??? I don't think so... > > This again depends on the timeline. As there is also a cost involved I > still don't believe that we will have a billion multihomed networks > tomorrow. Your argument here was that the number of available AS numbers would limit the number of multihomed networks to something we can handle. Since 32 bit ASNs can happen fairly easily (in fact I don't undestand what we're waiting for, the draft seems mature better do it now and keep some 16 bit numbers for new transit networks by giving 32 bit ones to leaf networks) the limit here is 4G which I don't believe is a size we can assume to be manageable in the forseeable future. > > A much better way to do this would be to take the globally unique > site > > local addresses for this. > > ...which breaks a lot of current applications. ??? I don't see how? > > Try to reclaim them... That's very hard. > > > Nope. And this has been discussed in RIPE over the last year (to do > > this more effectively ) and is already in place in APNIC I think. > > Where do you get this? There are more than 25000 AS numbers out > there. > > At some point, most of those networks will want to run IPv6. Historically, this issue has been usually dealt with by increasing the number space rather than aggressively reclaim unused numbers. If APNIC thinks they can do this more power to them (hm, how many ASNs are there in the APNIC anyway? Maybe ARIN should do this) but I'm not holding my breath. And even if successful I don't believe this will make 16 bits last forever. > Just look in Philip Smiths routing summary that are also in my slides > from RIPE i Amsterdam and also posted by me here a while ago. I was there, I saw them... Obviously I'm missing your point here, but I don't think it makes much of a difference as extrapolating current trends a few years isn't what we have to deal with here. Remember "we expect to sell one computer for each continent" and "640k should be enough for everyone"? These statements weren't really ridiculous at the time; they were simply based on present knowledge. We can predict future IPv6 deployment today no better than Bill Gates could predict the future of PC deployment in 1983. > >> Last, what worries me the most is the security considerations. A > >> failure on filtering, or in routing configuration will make the > AS7777 > >> incident seem like trivial. > > > No. > > Uhm, why not? You are supposed to use inbound filters to make GFN work. If you don't, you had better have routers with a LOT of memory, but if you don't, that's your problem and not anyone else's. But I think I see a potential problem that may or may not have been your point. Eventually it will become impossible to create filters that specifically allow all "good" routes from peers because the number of routes simply becomes too large. In the security considerations I mention this for ingress packet filtering but not for ingress route filtering. If a peer then screws up it's hard to protect against this. But I think maximum prefix settings per peer will help here. > > I'm sure many more people own or run a multihomed network in the > > Swedish silicon valley than in a rural province of China, but the > gain > > you get from allocating less for China is much smaller than the > hassle > > of having to manually look at it and justify your decision. > > The problem is how you make sure you get enough addresses where they > are needed, without having to reallocate space. Simple: by allocating more than could ever be required. Hence the /26 for Sweden. :-) > > Also, if you're going to physically move your > > network renumbering is only a minor extra task in addition to > > everything else that's going on. > > I was part of doing one of the largest network mergers ever. I am glad > we didn't have to worry more about renumbering that what we already > had. > > You don't want to renumber as well as merge routing. Some years ago we implemented a completely new network with a much better design for one of the large NL networks. However, we needed to switch customers one by one so the interior routing of the new and old networks had to be intimately intertwined so a certain customer address block could reside in either network. This turned out to be the biggest challenge of the entire project. I would have loved to give customers new address space for the transition. :-) > > In the US there isn't much local interconnection as not much traffic > > stays local. In most other countries, much more traffic stays local > > Huh? Local, as within cities or states. For instance, if two people in Boston communicate this will probably be routed through Virginia because there are no interconnects in Massachusetts (that I'm aware of). > > So now we have examples with little local interconnection and > > examples with little regional interconnection. I'm still waiting for > > examples of significant internet use with no local OR regional > > interconnection > > See Joes India/Nepal example. I'm not sure this constitutes "significant" internet use. > My problem is that I am not convinced address useage follow population > patterns. How can it not? Addresses = computers, computers = people. In IPv6 we have the luxury situation that we can allocate address space for all potential users. Potentially, everyone in the world can buy a computer and hook it up to two ISPs. Obviously not everyone actually does this, but the fact that the address allocation plan makes it possible is a good thing. > >> Yes, but there are other alternatives to base this on as well. > > > Such as? > > Current useage? As Michel explained: this will lead to results that are obviously not future-proof. > > No to the IPv6 swamp! > > I will start to worry when we hit 1k routes in IPv6. As engineers we are trained to worry in advance so that when our work is done others don't have to. Iljitsch From owner-multi6@ops.ietf.org Tue Feb 11 07:24:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00965 for ; Tue, 11 Feb 2003 07:24:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iZVs-000NGp-00 for multi6-data@psg.com; Tue, 11 Feb 2003 04:27:48 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18iZVp-000NGa-00; Tue, 11 Feb 2003 04:27:46 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1BCR3698234; Tue, 11 Feb 2003 13:27:03 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 11 Feb 2003 13:27:03 +0100 (CET) From: Iljitsch van Beijnum To: Randy Bush cc: Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: Message-ID: <20030211124204.G61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=EMAIL_ATTRIBUTION,HOT_NASTY,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 10 Feb 2003, Randy Bush wrote: > as we had all lived through > cidr and thought it immensely ill-considered to > think one could do a new addressing design without a *real* new and > scalable routing design. Ok, lets see what can be done in this area then. I'm aware of two ways to make routing scale: 1. Some kind of source routing 2. A hierarchical routing system The identifier/locator seperation thing is basically source routing. Current aggregation mechanisms (CIDR) provide some basic hierarchy. But we should be able to improve on this. The address space is a tree with the default route at the top and individual hosts all the way at the bottom as individual leaves. We're not talking about your basic binary tree here, as many levels are missing in certain parts of the tree. For instance, below ::/0 aren't ::0/1 and 8000::/1 but (conceptually) 2000::/3, the global unicast space (and some other less interesting stuff). Below 2000::/3 there are one or two additional conceptual levels but real routing info starts at xxxx:xxxx::/32, where the "top level aggregators" live. So essentially we're doing flat routing in the first 32 bits (or rather, 29 of the first 32) of the IPv6 address space. Flat routing in a part of the tree is not a problem, except that 29 bits is too many as it leads to a maximum of 512M entries in flat space for this part of the tree. So how do we fix this? If we simply introduce a level of aggregation we could be doing flat routing in a 64k space and then flat routing in another 64k space. That should work well, especially as the entire space isn't populated from the start. The trouble is that someone with a /32 must automatically buy transit service from the service provider that has the /16 this /32 falls in. This means renumbering from time to time. Also, not much multihoming in this scheme. Alternatively, we could align the address hierarchy with something else than the (largely fictional) topological hierarchy. For instance, the /16s could be allocated to internet exchanges. This way, it's possible to multihome and shop for transit as many ISPs can provide a path /to/ the exchange and many ISPs can provide a path /from/ the exchange to the destination network. Now suppose a node somewhere in the hierarchy fails. A smart hierarchical routing protocol would repair such a failure by linking nodes at the level below the failed node to the ones at the level above the failed node. Also, a smart hierarchical routing protocol would converge fast by learning the information it needs to function at the levels it is present quickly, but then optimize routing by adding additional cut-through routing entries that bypass the hierarchy if resources permit and adding this information leads to actual benefits. Iljitsch PS. Please no "IXes suck" flaming; if we are actually going to get into this we can do better but the IX stuff makes for a good example. From owner-multi6@ops.ietf.org Sun Feb 16 17:44:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00602 for ; Sun, 16 Feb 2003 17:44:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kXWm-000KSC-00 for multi6-data@psg.com; Sun, 16 Feb 2003 14:44:52 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18kXWj-000KRz-00 for multi6@ops.ietf.org; Sun, 16 Feb 2003 14:44:50 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1GMk2hE000758 for ; Sun, 16 Feb 2003 23:46:03 +0100 (CET) Date: Sun, 16 Feb 2003 21:51:09 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: GSE From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <609F1A25-41F0-11D7-874A-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.3 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ok, I have re-read Mike O'Dells old draft from 1997. Can someone remind me what the reasons for not going with this was? (Running for cover) - kurtis - From owner-multi6@ops.ietf.org Sun Feb 16 18:06:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00846 for ; Sun, 16 Feb 2003 18:06:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kXuo-000LC7-00 for multi6-data@psg.com; Sun, 16 Feb 2003 15:09:42 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18kXum-000LBv-00 for multi6@ops.ietf.org; Sun, 16 Feb 2003 15:09:40 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1GN8qA11774; Mon, 17 Feb 2003 00:08:52 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Feb 2003 00:08:52 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: GSE In-Reply-To: <609F1A25-41F0-11D7-874A-000393AB1404@kurtis.pp.se> Message-ID: <20030217000659.B61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 16 Feb 2003, Kurt Erik Lindqvist wrote: > Ok, I have re-read Mike O'Dells old draft from 1997. Can someone remind > me what the reasons for not going with this was? > (Running for cover) I wasn't around then, but the two main reasons for not raising it from the dead would be: - the draft as-is doesn't provide any actual multihoming benefits - how can we make the lower 64 bits of the address globally unique From owner-multi6@ops.ietf.org Sun Feb 16 18:11:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00913 for ; Sun, 16 Feb 2003 18:11:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kY06-000LOF-00 for multi6-data@psg.com; Sun, 16 Feb 2003 15:15:10 -0800 Received: from halt-in.cisco.com ([171.70.144.185]) by psg.com with esmtp (Exim 3.36 #1) id 18kY01-000LNd-00 for multi6@ops.ietf.org; Sun, 16 Feb 2003 15:15:05 -0800 Received: from cisco.com (171.70.144.164) by halt-in.cisco.com with ESMTP; 16 Feb 2003 15:15:05 -0800 Received: from cisco.com (sjc-vpn1-152.cisco.com [10.21.96.152]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA04514; Sun, 16 Feb 2003 15:15:04 -0800 (PST) Message-ID: <3E501B78.6090401@cisco.com> Date: Sun, 16 Feb 2003 15:15:04 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: GSE References: <20030217000659.B61596-100000@sequoia.muada.com> In-Reply-To: <20030217000659.B61596-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > - the draft as-is doesn't provide any actual multihoming benefits The point of the draft was that multihomed enterprises wouldn't ever be advertised into the dfz. If a site wanted to multihome it would have address prefixes from two providers, and those would get stamped on packets. > - how can we make the lower 64 bits of the address globally unique The same way we do with 32 bits. Eliot From owner-multi6@ops.ietf.org Sun Feb 16 18:19:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01010 for ; Sun, 16 Feb 2003 18:19:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kY82-000Lfi-00 for multi6-data@psg.com; Sun, 16 Feb 2003 15:23:22 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18kY80-000LfW-00 for multi6@ops.ietf.org; Sun, 16 Feb 2003 15:23:21 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1GNMV511817; Mon, 17 Feb 2003 00:22:31 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Feb 2003 00:22:31 +0100 (CET) From: Iljitsch van Beijnum To: Eliot Lear cc: Kurt Erik Lindqvist , Subject: Re: GSE In-Reply-To: <3E501B78.6090401@cisco.com> Message-ID: <20030217001722.K61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 16 Feb 2003, Eliot Lear wrote: > > - the draft as-is doesn't provide any actual multihoming benefits > The point of the draft was that multihomed enterprises wouldn't ever be > advertised into the dfz. Yes, it does that. But it doesn't give the multihomer transparent failover (or even failover of any kind). I'm sure that once we agree on the requirements GSE can't meet them. :-) > > - how can we make the lower 64 bits of the address globally unique > The same way we do with 32 bits. Exit stateless autoconfig... I'm not even mentioning security. If we want to do something GSE-like we might as well start from scratch. From owner-multi6@ops.ietf.org Mon Feb 17 01:54:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06081 for ; Mon, 17 Feb 2003 01:54:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kfCT-000FLL-00 for multi6-data@psg.com; Sun, 16 Feb 2003 22:56:25 -0800 Received: from halt-in.cisco.com ([171.70.144.185]) by psg.com with esmtp (Exim 3.36 #1) id 18kfCP-000FL9-00 for multi6@ops.ietf.org; Sun, 16 Feb 2003 22:56:21 -0800 Received: from cisco.com (171.70.144.164) by halt-in.cisco.com with ESMTP; 16 Feb 2003 22:56:34 -0800 Received: from cisco.com (sjc-vpn3-513.cisco.com [10.21.66.1]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id WAA21433; Sun, 16 Feb 2003 22:56:20 -0800 (PST) Message-ID: <3E508793.6070600@cisco.com> Date: Sun, 16 Feb 2003 22:56:19 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: GSE References: <20030217001722.K61596-100000@sequoia.muada.com> In-Reply-To: <20030217001722.K61596-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, > Yes, it does that. But it doesn't give the multihomer transparent > failover (or even failover of any kind). I'm sure that once we agree on > the requirements GSE can't meet them. :-) The draft was short on specifics for failover, as I recall, but so long as you had some connectivity between gateways it should have been possible to failover in a stateless way. As to TCP I personally would have only used the lower 64 for the pseudo-header, just as with HIP you would use the HIT. The big deal is that the host implementation would need to understand that the upper half and lower half would have to be processed quite differently. > > >>>- how can we make the lower 64 bits of the address globally unique > > >>The same way we do with 32 bits. > > > Exit stateless autoconfig... I'm not even mentioning security. I suspect we differ substantially on where we think requirements should go. Stateless autoconfig isn't my top feature requirement. Scaling to more robust connectivity is. There was an "analysis" of GSE security. However, Steve Bellovin didn't agree with it. I do not recall the specifics. This is not to say that GSE had all the answers. It needed work. For instance, route selection and failover did need some amount of fleshing out. But I believe it suffered a premature death. Eliot From owner-multi6@ops.ietf.org Mon Feb 17 04:11:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18200 for ; Mon, 17 Feb 2003 04:11:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18khLz-000LSU-00 for multi6-data@psg.com; Mon, 17 Feb 2003 01:14:23 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18khLv-000LSG-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 01:14:19 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1H9FQhE001143; Mon, 17 Feb 2003 10:15:29 +0100 (CET) Date: Mon, 17 Feb 2003 10:15:25 +0100 Subject: Re: GSE Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030217000659.B61596-100000@sequoia.muada.com> Message-Id: <5974DDB6-4258-11D7-874A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Ok, I have re-read Mike O'Dells old draft from 1997. Can someone >> remind >> me what the reasons for not going with this was? > >> (Running for cover) > > I wasn't around then, but the two main reasons for not raising it from > the dead would be: > > - the draft as-is doesn't provide any actual multihoming benefits > - how can we make the lower 64 bits of the address globally unique > Before my mailbox fills up further - I specifically asked why this was killed back in 1997. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 17 04:13:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18227 for ; Mon, 17 Feb 2003 04:13:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18khOh-000LX8-00 for multi6-data@psg.com; Mon, 17 Feb 2003 01:17:11 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18khOf-000LWv-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 01:17:09 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1H9IKhE001168; Mon, 17 Feb 2003 10:18:20 +0100 (CET) Date: Mon, 17 Feb 2003 10:18:19 +0100 Subject: Re: GSE Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Eliot Lear , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030217001722.K61596-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> - the draft as-is doesn't provide any actual multihoming benefits > >> The point of the draft was that multihomed enterprises wouldn't ever >> be >> advertised into the dfz. > > Yes, it does that. But it doesn't give the multihomer transparent > failover (or even failover of any kind). I'm sure that once we agree on > the requirements GSE can't meet them. :-) Why wouldn't it? > If we want to do something GSE-like we might as well start from > scratch. Might not be such a bad idea. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 17 04:33:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18485 for ; Mon, 17 Feb 2003 04:33:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18khi1-000Lyx-00 for multi6-data@psg.com; Mon, 17 Feb 2003 01:37:09 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18khhw-000Lyk-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 01:37:05 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA28298 for ; Mon, 17 Feb 2003 09:37:03 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h1H9axU3026225 for ; Mon, 17 Feb 2003 09:36:59 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h1H9axn18865 for multi6@ops.ietf.org; Mon, 17 Feb 2003 09:36:59 GMT Date: Mon, 17 Feb 2003 09:36:59 +0000 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: GSE Message-ID: <20030217093659.GC18710@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <20030217001722.K61596-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Feb 17, 2003 at 10:18:19AM +0100, Kurt Erik Lindqvist wrote: > >If we want to do something GSE-like we might as well start from > >scratch. > > Might not be such a bad idea. Well, get started on IPv7 and let us know what you have in 2012 :) Tim From owner-multi6@ops.ietf.org Mon Feb 17 04:47:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18681 for ; Mon, 17 Feb 2003 04:47:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18khvs-000MPA-00 for multi6-data@psg.com; Mon, 17 Feb 2003 01:51:28 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18khvm-000MOs-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 01:51:22 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1H9obN12961; Mon, 17 Feb 2003 10:50:37 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Feb 2003 10:50:37 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: GSE In-Reply-To: Message-ID: <20030217104225.P61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_05_08 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Feb 2003, Kurt Erik Lindqvist wrote: > > I'm sure that once we agree on the requirements GSE can't meet them. :-) > Why wouldn't it? No failover. If a host as A::1 and B::1 and I select A::1 but then this path goes down, GSE doesn't tell me what I should do. But I guess if we're going to overhaul TCP anyway (as is needed for GSE) we can fix this too. Another problem: how do I prevent someone from using C::1 and stealing A::1/B::1's sessions? Doing it the MHAP way and replace the addresses in transit makes more sense as it doesn't require changes to higher layers and the explicit search-and-replace operation makes security easier. Or use implicit rather than explicit identifiers so you only have to negotiate some stuff at the start of the session. I can't help you with your original question about GSE as I wasn't around in IETF circles in 1997. :-) From owner-multi6@ops.ietf.org Mon Feb 17 05:41:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19457 for ; Mon, 17 Feb 2003 05:41:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kil8-000Njy-00 for multi6-data@psg.com; Mon, 17 Feb 2003 02:44:26 -0800 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18kil4-000Nje-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 02:44:22 -0800 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id B1F6A43224; Mon, 17 Feb 2003 11:44:20 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id 5FAF999E94; Mon, 17 Feb 2003 11:44:20 +0100 (CET) Subject: Re: GSE From: marcelo bagnulo To: Kurt Erik Lindqvist Cc: multi6@ops.ietf.org In-Reply-To: <609F1A25-41F0-11D7-874A-000393AB1404@kurtis.pp.se> References: <609F1A25-41F0-11D7-874A-000393AB1404@kurtis.pp.se> Content-Type: text/plain Organization: uc3m Message-Id: <1045478659.697.10.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Feb 2003 11:44:20 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kurtis, I guess that the long answer to your question can be found at: draft-ietf-ipngwg-esd-analysis-04 (I can send it if anybody is interested) Regards, marcelo On Sun, 2003-02-16 at 21:51, Kurt Erik Lindqvist wrote: > Ok, I have re-read Mike O'Dells old draft from 1997. Can someone remind > me what the reasons for not going with this was? > > (Running for cover) > > - kurtis - -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Mon Feb 17 06:14:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20056 for ; Mon, 17 Feb 2003 06:14:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kjH0-000OgU-00 for multi6-data@psg.com; Mon, 17 Feb 2003 03:17:22 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 18kjGs-000OfL-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 03:17:15 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1HBFuAN067408; Mon, 17 Feb 2003 12:15:56 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1HBFlkU242506; Mon, 17 Feb 2003 12:15:49 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32088 from ; Mon, 17 Feb 2003 12:15:36 +0100 Message-Id: <3E50C426.3F5C81A8@hursley.ibm.com> Date: Mon, 17 Feb 2003 12:14:46 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Eliot Lear Cc: Iljitsch van Beijnum , Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: GSE References: <20030217000659.B61596-100000@sequoia.muada.com> <3E501B78.6090401@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit However, the main concerns that held it up at the time were about security. You probably want to get hold of draft-ietf-ipngwg-esd-analysis-05.txt (I think -05 was the last version.) Brian Eliot Lear wrote: > > Iljitsch van Beijnum wrote: > > - the draft as-is doesn't provide any actual multihoming benefits > > The point of the draft was that multihomed enterprises wouldn't ever be > advertised into the dfz. If a site wanted to multihome it would have > address prefixes from two providers, and those would get stamped on packets. > > > - how can we make the lower 64 bits of the address globally unique > > The same way we do with 32 bits. > > Eliot -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-multi6@ops.ietf.org Mon Feb 17 07:18:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21154 for ; Mon, 17 Feb 2003 07:18:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kkGN-0000Jv-00 for multi6-data@psg.com; Mon, 17 Feb 2003 04:20:47 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18kkGJ-0000JX-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 04:20:43 -0800 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 h1HCKdTW015846; Mon, 17 Feb 2003 07:20:39 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1HCKcXX015843; Mon, 17 Feb 2003 07:20:38 -0500 Date: Mon, 17 Feb 2003 07:20:38 -0500 From: "J. Noel Chiappa" Message-Id: <200302171220.h1HCKcXX015843@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: GSE Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Kurt Erik Lindqvist > I have re-read Mike O'Dells old draft from 1997. Can someone remind me > what the reasons for not going with this was? The main reason given at the time was that there was a security issue with protecting the binding between the location and the identifier parts. (Duh.) I was pretty irritated by the shallowness of that, because i) it's so obvious, and ii) the possible fixes [too many different ones, with different tradeoffs, to list here] are also so obvious. (I note that Mobile IPv6 has *exactly* the same security problem, but the IPv6 intellegensia isn't down on Mobile IPv6...) The claim is that in classic IPv4/v6, you get a certain amount of security from the fact that your identity and your location are inextricably bound together. Steve Bellovin has written a critique of that claim which shows that in fact the security that provides is not in fact very good at all. Well, so much for all that. Some of the more perceptive critics were uneasy with the way that the routing goop got added and munged around with. It's a potentially complex process, and IIRC it wasn't fully fleshed out. I thought that was a much more valid concern. Noel From owner-multi6@ops.ietf.org Mon Feb 17 07:33:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21290 for ; Mon, 17 Feb 2003 07:33:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kkWF-0000dk-00 for multi6-data@psg.com; Mon, 17 Feb 2003 04:37:11 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18kkWB-0000dP-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 04:37:07 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18kkW8-0009t9-00; Mon, 17 Feb 2003 04:37:04 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 17 Feb 2003 04:37:04 -0800 To: Kurt Erik Lindqvist Cc: multi6@ops.ietf.org Subject: Re: GSE References: <20030217000659.B61596-100000@sequoia.muada.com> <5974DDB6-4258-11D7-874A-000393AB1404@kurtis.pp.se> Message-Id: X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Before my mailbox fills up further - I specifically asked why this was > killed back in 1997. v6 protocol designers claimed, in his absence, that smb said there were security issues. according to smb, he made no such claim. randy From owner-multi6@ops.ietf.org Mon Feb 17 07:34:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21304 for ; Mon, 17 Feb 2003 07:34:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kkXd-0000g5-00 for multi6-data@psg.com; Mon, 17 Feb 2003 04:38:37 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18kkXb-0000ft-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 04:38:35 -0800 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 h1HCcXTW016017; Mon, 17 Feb 2003 07:38:33 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1HCcXZl016014; Mon, 17 Feb 2003 07:38:33 -0500 Date: Mon, 17 Feb 2003 07:38:33 -0500 From: "J. Noel Chiappa" Message-Id: <200302171238.h1HCcXZl016014@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: GSE Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Eliot Lear > As to TCP I personally would have only used the lower 64 for the > pseudo-header .. the host implementation would need to understand that > the upper half and lower half would have to be processed quite > differently. Yeah, but it's too late for that, which is why I now favour 16+16. Not that the semantics or anything would change from 8+8, but simply that mechanistically it's going to be easier (don't have to change TCP, etc, etc). > This is not to say that GSE had all the answers. It needed work. For > instance, route selection and failover did need some amount of fleshing > out. But I believe it suffered a premature death. Agree with all of that. Noel From owner-multi6@ops.ietf.org Mon Feb 17 07:42:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21389 for ; Mon, 17 Feb 2003 07:42:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kkfL-0000s9-00 for multi6-data@psg.com; Mon, 17 Feb 2003 04:46:35 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18kkfJ-0000rw-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 04:46:33 -0800 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 h1HCkVTW016070; Mon, 17 Feb 2003 07:46:31 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1HCkUIR016067; Mon, 17 Feb 2003 07:46:30 -0500 Date: Mon, 17 Feb 2003 07:46:30 -0500 From: "J. Noel Chiappa" Message-Id: <200302171246.h1HCkUIR016067@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: GSE Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=1.6 required=5.0 tests=SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > No failover. If a host as A::1 and B::1 and I select A::1 but then this > path goes down, GSE doesn't tell me what I should do. Right, this was one of the "unfinished" pieces. But it's pretty easy to fix this one: at some point early on (either when you do the DNS lookup, or in the ICP) you get the other viable addresses for the host. So when one stops responding you can try others. But it's more complex, because part of the motivation for GSE was not just failover, but also the ability to do path-selection, and that's more complex. > Another problem: how do I prevent someone from using C::1 and stealing > A::1/B::1's sessions? There are lots of ways that differ in the details, but basically the all use crypto to authenticate; either any binding change, or the individual packets - and you can make up zillions of different variants, depending on what your concerns are. > Doing it the MHAP way and replace the addresses in transit makes more > sense as it doesn't require changes to higher layers Umm, how does this differ from NAT? I guess the difference is that by the time the packet gets to the other end, the original source and destination addresses are back in it? So it's kind of invisble wrapping/unwrapping? My concern about doing that is that now you've got state (those mappings) out in the network - more complex and less robust. Let the hosts manage it. > Or use implicit rather than explicit identifiers so you only have to > negotiate some stuff at the start of the session. If you crypto-secure binding changes, you get basically the same thing - you only have to do anything extra when the prefix changes. > I can't help you with your original question about GSE as I wasn't > around in IETF circles in 1997. :-) Trust me, those of us who were around at the time wish we weren't! It was very painful watching the IPng bus get drive off the cliff.... Noel From owner-multi6@ops.ietf.org Mon Feb 17 08:01:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21553 for ; Mon, 17 Feb 2003 08:01:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kkx8-0001Ar-00 for multi6-data@psg.com; Mon, 17 Feb 2003 05:04:58 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18kkx6-0001Ae-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 05:04:56 -0800 Received: from extremenetworks.com (unknown [10.0.8.131]) by gnat.inet.org (Postfix) with ESMTP id DDDFF67103; Mon, 17 Feb 2003 08:16:59 -0500 (EST) Date: Mon, 17 Feb 2003 08:04:53 -0500 Subject: Re: GSE Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Eliot Lear From: RJ Atkinson In-Reply-To: <3E508793.6070600@cisco.com> Message-Id: <67E9C1AE-4278-11D7-AC71-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Feb 17, 2003, at 01:56 America/Montreal, Eliot Lear wrote: > There was an "analysis" of GSE security. However, Steve Bellovin > didn't agree with it. I do not recall the specifics. Correction: The IAB (at the time, smb and other folks) and the IESG (jis & ml) and several respected Security Directorate folks all agreed that the claimed "analysis" was not factually correct. > This is not to say that GSE had all the answers. It needed work. For > instance, route selection and failover did need some amount of > fleshing out. But I believe it suffered a premature death. Regardless of the history, it would not hurt for folks to study the concepts behind it. I will *beg* that we avoid the usual flame-fest that erupts when the letters "GSE" are mentioned in an IPv6 context. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Mon Feb 17 08:04:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21568 for ; Mon, 17 Feb 2003 08:04:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kkzw-0001G7-00 for multi6-data@psg.com; Mon, 17 Feb 2003 05:07:52 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18kkzu-0001Fv-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 05:07:51 -0800 Received: from extremenetworks.com (unknown [10.0.8.131]) by gnat.inet.org (Postfix) with ESMTP id 7D60067103; Mon, 17 Feb 2003 08:19:54 -0500 (EST) Date: Mon, 17 Feb 2003 08:07:43 -0500 Subject: Re: GSE Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20030217104225.P61596-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Feb 17, 2003, at 04:50 America/Montreal, Iljitsch van Beijnum wrote: > On Mon, 17 Feb 2003, Kurt Erik Lindqvist wrote: >>> I'm sure that once we agree on the requirements GSE can't meet them. >>> :-) >> Why wouldn't it? > > No ... O'Dell's GSE I-D is mostly an architecture document, not a protocol spec. So of course MANY implementation-details are not specified in the old GSE I-Ds. The absence of implementation details in an architecture document doesn't prove anything either way about GSE's suitability for multi-homing in the multi6 context. Ran From owner-multi6@ops.ietf.org Mon Feb 17 08:05:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21582 for ; Mon, 17 Feb 2003 08:05:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kl0t-0001Ha-00 for multi6-data@psg.com; Mon, 17 Feb 2003 05:08:51 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18kl0r-0001HN-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 05:08:49 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1HD7uB13213; Mon, 17 Feb 2003 14:07:56 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Feb 2003 14:07:15 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: GSE In-Reply-To: <200302171246.h1HCkUIR016067@ginger.lcs.mit.edu> Message-ID: <20030217135818.F61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Feb 2003, J. Noel Chiappa wrote: > > No failover. If a host as A::1 and B::1 and I select A::1 but then this > > path goes down, GSE doesn't tell me what I should do. > Right, this was one of the "unfinished" pieces. > But it's pretty easy to fix this one: at some point early on (either when you > do the DNS lookup, or in the ICP) you get the other viable addresses for the > host. So when one stops responding you can try others. Of course. Unfortunately, this is hard to get right unless you have access to the full transport layer state. > > Doing it the MHAP way and replace the addresses in transit makes more > > sense as it doesn't require changes to higher layers > Umm, how does this differ from NAT? I guess the difference is that by the > time the packet gets to the other end, the original source and destination > addresses are back in it? So it's kind of invisble wrapping/unwrapping? Yes. > My concern about doing that is that now you've got state (those mappings) out > in the network - more complex and less robust. Let the hosts manage it. This state is easy to manage as it can be done at the /48 level. However, discovering the right mapping in the first place is harder, especially the way it is currently written down in the MHAP draft. > > Or use implicit rather than explicit identifiers so you only have to > > negotiate some stuff at the start of the session. > If you crypto-secure binding changes, you get basically the same thing - you > only have to do anything extra when the prefix changes. This is what's needed for mobility, but in multihoming we have the advantage that we know all the possible addresses at session start. Doing it then is much cleaner: no double jump problems and so on. Iljitsch From owner-multi6@ops.ietf.org Mon Feb 17 08:08:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21622 for ; Mon, 17 Feb 2003 08:08:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kl3i-0001MM-00 for multi6-data@psg.com; Mon, 17 Feb 2003 05:11:46 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18kl3g-0001MA-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 05:11:44 -0800 Received: from extremenetworks.com (unknown [10.0.8.131]) by gnat.inet.org (Postfix) with ESMTP id 4C09E67103; Mon, 17 Feb 2003 08:23:47 -0500 (EST) Date: Mon, 17 Feb 2003 08:11:40 -0500 Subject: Re: GSE Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Kurt Erik Lindqvist , multi6@ops.ietf.org To: marcelo bagnulo From: RJ Atkinson In-Reply-To: <1045478659.697.10.camel@presto.it.uc3m.es> Message-Id: <5A20A8C2-4279-11D7-AC71-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Feb 17, 2003, at 05:44 America/Montreal, marcelo bagnulo wrote: > Hi Kurtis, > > I guess that the long answer to your question can be found at: > > draft-ietf-ipngwg-esd-analysis-*.txt That draft was never published as an RFC mostly because the IESG, IAB, and several IETF Security Directorate members believed that it was not factually correct. The biggest issue is that it does not describe the actual GSE/8+8 proposal accurately -- so the criticisms are of something not quite the same as GSE/8+8. This is NOT to imply that the IESG, IAB, or other folks thought that GSE/8+8 was without problems -- merely that the above draft was not on-target in its claims. So folks should add a lot of salt when reading that draft. Please lets move forward on multi6, rather than revisiting painful old IPng WG history here. Ran From owner-multi6@ops.ietf.org Mon Feb 17 09:56:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23261 for ; Mon, 17 Feb 2003 09:56:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kmjL-0003ay-00 for multi6-data@psg.com; Mon, 17 Feb 2003 06:58:51 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18kmjH-0003am-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 06:58:47 -0800 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 h1HEwjTW017182; Mon, 17 Feb 2003 09:58:45 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1HEwi1c017181; Mon, 17 Feb 2003 09:58:44 -0500 Date: Mon, 17 Feb 2003 09:58:44 -0500 From: "J. Noel Chiappa" Message-Id: <200302171458.h1HEwi1c017181@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: GSE Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum >>> No failover. If a host as A::1 and B::1 and I select A::1 but then >>> this path goes down, GSE doesn't tell me what I should do. >> it's pretty easy to fix this one: at some point early on .. you get >> the other viable addresses for the host. So when one stops responding >> you can try others. > Unfortunately, this is hard to get right unless you have access to the > full transport layer state. ??? Why do you need the full transport layer state? Which the end-host does have access to, of course - provided you're doing this in the end-host, and not at some border box - another thing GSE alluded to, but which wasn't fully worked out, IIRC. I don't know, I get a little nervous when functionality is spread out across multiple boxes like that; the notion that the binding from identity to location is something taken care of by your border router makes me uneasy. Noel From owner-multi6@ops.ietf.org Mon Feb 17 12:08:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26242 for ; Mon, 17 Feb 2003 12:08:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18konV-0006KS-00 for multi6-data@psg.com; Mon, 17 Feb 2003 09:11:17 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18konT-0006KG-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 09:11:15 -0800 Subject: RE: GSE Date: Mon, 17 Feb 2003 09:11:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5BA14@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: GSE Thread-Index: AcLWDjQlUJYGEOcATny4+0PfQJKjSAAmUqyw From: "Michel Py" To: "Kurt Erik Lindqvist" , X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA26242 > Kurt Erik Lindqvist wrote: > Ok, I have re-read Mike O'Dells old draft from 1997. Can > someone remind me what the reasons for not going with this > was? Go on the ipv6mh web page and look at draft-ietf-ipngwg-esd-analysis-05.txt just below the GSE draft. Been there forever. Michel. From owner-multi6@ops.ietf.org Mon Feb 17 12:15:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26356 for ; Mon, 17 Feb 2003 12:15:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kovC-0006Up-00 for multi6-data@psg.com; Mon, 17 Feb 2003 09:19:14 -0800 Received: from halt-in.cisco.com ([171.70.144.185]) by psg.com with esmtp (Exim 3.36 #1) id 18kov8-0006UY-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 09:19:10 -0800 Received: from cisco.com (171.70.144.164) by halt-in.cisco.com with ESMTP; 17 Feb 2003 09:19:18 -0800 Received: from cisco.com (sjc-vpn3-828.cisco.com [10.21.67.60]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA29153; Mon, 17 Feb 2003 09:19:09 -0800 (PST) Message-ID: <3E51198C.4000502@cisco.com> Date: Mon, 17 Feb 2003 09:19:08 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Iljitsch van Beijnum , Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: GSE References: <20030217000659.B61596-100000@sequoia.muada.com> <3E501B78.6090401@cisco.com> <3E50C426.3F5C81A8@hursley.ibm.com> In-Reply-To: <3E50C426.3F5C81A8@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dr. Bellovin's analysis can be found at the following URL: http://www.research.att.com/~smb/papers/esd-secure.txt From owner-multi6@ops.ietf.org Mon Feb 17 13:58:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28347 for ; Mon, 17 Feb 2003 13:58:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kqUh-0009EZ-00 for multi6-data@psg.com; Mon, 17 Feb 2003 10:59:59 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18kqUc-0009EL-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 10:59:54 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1HIx7c13618; Mon, 17 Feb 2003 19:59:07 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Feb 2003 19:59:07 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: GSE In-Reply-To: <200302171458.h1HEwi1c017181@ginger.lcs.mit.edu> Message-ID: <20030217194012.W61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Feb 2003, J. Noel Chiappa wrote: > > Unfortunately, this is hard to get right unless you have access > > to the full transport layer state. > ??? Why do you need the full transport layer state? You want to switch to another path when the current one becomes available, but there is no easy way to determine when this happens. Reliable transport protocols know whether the other end is still reachable so they can initiate a failover event if this is no longer the case. A box in the middle would have to monitor the session state. Not impossible, but not something you'd want to do in a border router either. The alternative is sending keepalives to every network you're communicating with. (This is what MHAP does.) > Which the end-host does have access to, of course - provided you're doing > this in the end-host, and not at some border box - another thing GSE alluded > to, but which wasn't fully worked out, IIRC. > I don't know, I get a little nervous when functionality is spread out across > multiple boxes like that; the notion that the binding from identity to > location is something taken care of by your border router makes me uneasy. There are good reasons to do it in the hosts and there are good reasons to do it closer to the edge of the network. Ideally, this choice should be the 1user's. What we don't want is changes to both router _and_ hosts for a multihoming solution. From owner-multi6@ops.ietf.org Mon Feb 17 19:59:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05031 for ; Mon, 17 Feb 2003 19:59:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kw7p-000Nhn-00 for multi6-data@psg.com; Mon, 17 Feb 2003 17:00:45 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18kw7j-000NhZ-00 for multi6@ops.ietf.org; Mon, 17 Feb 2003 17:00:39 -0800 Subject: RE: GSE Date: Mon, 17 Feb 2003 17:00:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54C0E@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: GSE Thread-Index: AcLWgyGX1+VvecTDSfe2FurIKlrfWwAY9mFw From: "Michel Py" To: Cc: "J. Noel Chiappa" X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA05031 Noel, >> Iljitsch van Beijnum wrote: >> Doing it the MHAP way and replace the addresses in transit makes more >> sense as it doesn't require changes to higher layers > J. Noel Chiappa wrote: > Umm, how does this differ from NAT? I guess the difference is that by > the time the packet gets to the other end, the original source and > destination addresses are back in it? So it's kind of invisible > wrapping/unwrapping? Yes, it's a simplified form of tunneling. Lots of advantages and one drawback: the original destination address is not available en-route would someone want to decapsulate the packet to figure it out for whatever reasons. This could be solved by an extra header if necessary, which I still have to see a good reason for. > My concern about doing that is that now you've got state (those > mappings) out in the network - more complex and less robust. Let > the hosts manage it. There is no state; a little like 6to4, automatic setup. There is some local state maintained in individual routers for the sake of speed but it's recreated on demand and none of the boxes are aware of the others. MHAP is not like a stateful firewall, for example. In a stateful firewall or NAT box, failover to a different device requires to synchronize state; not MHAP. In a site with multiple egress points, failure of the MHAP router at one of these points will reroute traffic to another one as long as the IGP converges. Michel. From owner-multi6@ops.ietf.org Tue Feb 18 06:37:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25555 for ; Tue, 18 Feb 2003 06:37:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18l65t-0000gt-00 for multi6-data@psg.com; Tue, 18 Feb 2003 03:39:25 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18l65p-0000gh-00 for multi6@ops.ietf.org; Tue, 18 Feb 2003 03:39:21 -0800 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 h1IBdJTW026691; Tue, 18 Feb 2003 06:39:19 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1IBdInV026690; Tue, 18 Feb 2003 06:39:18 -0500 Date: Tue, 18 Feb 2003 06:39:18 -0500 From: "J. Noel Chiappa" Message-Id: <200302181139.h1IBdInV026690@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: GSE Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum >> Why do you need the full transport layer state? Which the end-host >> does have access to, of course - provided you're doing this in the >> end-host, and not at some border box > You want to switch to another path when the current one becomes > available, but there is no easy way to determine when this happens. > Reliable transport protocols know whether the other end is still > reachable so they can initiate a failover event if this is no longer > the case. A box in the middle would have to monitor the session state. Oh, right. I guess I just assumed that the end-host always had the job of detecting when the far end had gone unreachable, since it's clearly such a nightmare for a middle-box to determine that. (The middle box would have to know every application, to recognize when there was a problem, since you can have failure modes that don't show up at the transport level - e.g. a timeout on a reply). So then you have the choice of either i) the end-host picks a new far-end address, or ii) it tells the border router to pick a new one. Noel From owner-multi6@ops.ietf.org Tue Feb 18 06:41:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25618 for ; Tue, 18 Feb 2003 06:41:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18l6BD-0000tB-00 for multi6-data@psg.com; Tue, 18 Feb 2003 03:44:55 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18l6BB-0000sz-00 for multi6@ops.ietf.org; Tue, 18 Feb 2003 03:44:53 -0800 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 h1IBiqTW026734; Tue, 18 Feb 2003 06:44:52 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1IBipwr026733; Tue, 18 Feb 2003 06:44:51 -0500 Date: Tue, 18 Feb 2003 06:44:51 -0500 From: "J. Noel Chiappa" Message-Id: <200302181144.h1IBipwr026733@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: GSE Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Michel Py" Without having read the MHAP spec (which I guess I ought to do, but no time today): > one drawback: the original destination address is not available > en-route would someone want to decapsulate the packet to figure it out > for whatever reasons. > ... > There is no state; a little like 6to4, automatic setup. These two statements are inconsistent. Someone, somewhere, has to have that original destination address, then... Noel From owner-multi6@ops.ietf.org Tue Feb 18 06:57:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25816 for ; Tue, 18 Feb 2003 06:57:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18l6RA-0001Ub-00 for multi6-data@psg.com; Tue, 18 Feb 2003 04:01:24 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18l6R5-0001UO-00 for multi6@ops.ietf.org; Tue, 18 Feb 2003 04:01:19 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1IC2VhE003533; Tue, 18 Feb 2003 13:02:32 +0100 (CET) Date: Tue, 18 Feb 2003 13:02:31 +0100 Subject: Re: GSE Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: Kurt Erik Lindqvist In-Reply-To: <200302181139.h1IBdInV026690@ginger.lcs.mit.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So then you have the choice of either i) the end-host picks a new > far-end > address, or ii) it tells the border router to pick a new one. > Well, to some effect the latter is what we do today already so I don't see that as a major problem. - kurtis - From owner-multi6@ops.ietf.org Thu Feb 20 04:33:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05361 for ; Thu, 20 Feb 2003 04:33:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ln5Y-000KqD-00 for multi6-data@psg.com; Thu, 20 Feb 2003 01:33:56 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18ln5U-000Kpw-00; Thu, 20 Feb 2003 01:33:52 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1K9Wta11788; Thu, 20 Feb 2003 11:32:56 +0200 Date: Thu, 20 Feb 2003 11:32:55 +0200 (EET) From: Pekka Savola To: "Alan E. Beard" cc: Kurt Erik Lindqvist , Tim Chown , , , Subject: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <20030214175244.P43282-100000@amneris.aebeard.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hello, I'll take one particular issue, and Cc: to multi6 as I believe it is a very important thing to consider. On Fri, 14 Feb 2003, Alan E. Beard wrote: > > > Most of the end-user-network managers among my clients now multihome, > > > and > > > will continue to require multihomed service in future. In every case > > > where the user's network is multihomed, the multiple independent > > > connections are seen as crucial for maintenance of high availability of > > > > [Kurtis:] > > I find this funny. A number of studies have shown that if this is what > > you are after, multihoming and BGP is the wrong way to go - but never > > mind. > > > Your comment may be true, but my clients are nonetheless unwilling to risk > the possibility of an extended network outage on a single ISP (while not > frequent, these events are far from unprecedented) rendering their online > customer-support environment unavailable for several hours, much less for > a day. Shorter outages (on the order of minutes in the single digits) are > tolerated, provided that such outages are infrequent. This is a very problematic approach IMO. Need more resiliency? Network outages unacceptable? The right place to fix this is the network service provider, period. Nothing else seems like a scalable approach. Consider a case when many companies _phone_ services would have been changed to VoIP. IP would be a critical service. Do the enterprises protect against failures by getting more ISP's? Unscalable. No, the ISP's _must_ get better. Pick one well when choosing them. When ISP's have SLA's, a lot of customers for which continued service is of utmost importance, the networks *will* work. There is just no other choice. If the mobile phone of CTO, CEO or whatever rings after (1)5 minutes of network outage, things _will_ happen. It just seems the mentality in some networks is that network outages are ok, networks don't have to be designed with multiple connections, etc.etc. That must change if we want to build a mission-critical IP infrastructure. Instead of making every site try to deal with the problems themselves. This is my view as ISP and an end-user. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Feb 20 05:50:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06881 for ; Thu, 20 Feb 2003 05:50:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18loKO-000NUr-00 for multi6-data@psg.com; Thu, 20 Feb 2003 02:53:20 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18loKL-000NUe-00 for multi6@ops.ietf.org; Thu, 20 Feb 2003 02:53:17 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1KAqEA19458; Thu, 20 Feb 2003 11:52:14 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 20 Feb 2003 11:52:14 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Savola cc: "Alan E. Beard" , Tim Chown , , Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: Message-ID: <20030220112127.Q61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 20 Feb 2003, Pekka Savola wrote: > > Your comment may be true, but my clients are nonetheless unwilling to risk > > the possibility of an extended network outage on a single ISP (while not > > frequent, these events are far from unprecedented) rendering their online > > customer-support environment unavailable for several hours, much less for > > a day. Shorter outages (on the order of minutes in the single digits) are > > tolerated, provided that such outages are infrequent. > This is a very problematic approach IMO. > Need more resiliency? Network outages unacceptable? > The right place to fix this is the network service provider, period. > Nothing else seems like a scalable approach. There is no technical reason why a single service provider network can do better than a similar network that consists of several smaller service provider networks. Sure, BGP as-is doesn't provide the seamless failorver some people would like. It annoys me to no end that Cisco uses a 180 second default hold time for BGP, twice the already too conservative value that is is suggested in the RFC. This means that when a circuit goes down BGP takes two or three minutes to notice this. I always recommend configuring a hold time of 15 seconds, but it seems some vendors have designed their stuff in such a way that sessions can fail with this value when the box is busy. But IGPs have the same fundamental problem (although the details may differ). OSPF for instance takes 40 seconds to detect a dead circuit. > Consider a case when many companies _phone_ services would have been > changed to VoIP. IP would be a critical service. Do the enterprises > protect against failures by getting more ISP's? Unscalable. No, the > ISP's _must_ get better. Pick one well when choosing them. We are _very_ far from a situation where even the best ISP provides a service level that is better then the one you get from multihoming even if you consider failover delays. Also, these approaches aren't mutually exclusive. ISPs should get better. Multihoming should get better. At the same time, we should recognize that it is simply impossible to have the same failover delays at layer 3 as at layer 1. > When ISP's have SLA's, a lot of customers for which continued service is > of utmost importance, the networks *will* work. There is just no other > choice. If the mobile phone of CTO, CEO or whatever rings after (1)5 > minutes of network outage, things _will_ happen. My experience with SLAs is that they are a marketing tool and job security for bureaucrats. They don't make the worst case any better, they only make the worst case slightly less frequent. (What makes you think this mobile phone will ring anyway? Speaking of unreliable networks...) And the single service provider thing doesn't scale anyway: the end result would have to be a single global ISP. > It just seems the mentality in some networks is that network outages are > ok, networks don't have to be designed with multiple connections, etc.etc. > That must change if we want to build a mission-critical IP infrastructure. > Instead of making every site try to deal with the problems themselves. Has the end-to-end principle failed to teach us anything? Reliability begins and ends in the end hosts. If each host is connected over two service providers there are four possible paths the hosts can switch between on a per-packet basis. Then the only problem becomes detecting failure. The end hosts are in an excellent position to do this without having to generate keepalive messages; a well designed protocol could switch to an alternate path within a few round trip times when a path failure occurs. Multi6 has been gravitating towards multi-address multihoming solutions for a while now, but unfortunately it seems impossible to move foward. From owner-multi6@ops.ietf.org Thu Feb 20 10:03:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16679 for ; Thu, 20 Feb 2003 10:03:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lsH6-0006QF-00 for multi6-data@psg.com; Thu, 20 Feb 2003 07:06:12 -0800 Received: from sabre.ncc.catchcom.no ([193.75.1.130]) by psg.com with esmtp (Exim 3.36 #1) id 18lsH4-0006Q1-00 for multi6@ops.ietf.org; Thu, 20 Feb 2003 07:06:10 -0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by sabre.ncc.catchcom.no (Postfix) with ESMTP id 245FA55E; Thu, 20 Feb 2003 16:06:08 +0100 (CET) Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] From: Lars Erik Gullerud To: Pekka Savola Cc: "Alan E. Beard" , Kurt Erik Lindqvist , Tim Chown , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org, randy@psg.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1045753567.81330.33.camel@sabre.ncc.catchcom.no> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 20 Feb 2003 16:06:08 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-02-20 at 10:32, Pekka Savola wrote: > This is a very problematic approach IMO. > > Need more resiliency? Network outages unacceptable? > > The right place to fix this is the network service provider, period. > Nothing else seems like a scalable approach. In a perfect world I'm sure I'd agree with you. In real life however, the fact of the matter is that customers want multihoming, and it doesn't matter to the customers if that is a problematic approach that doesn't scale for the SPs. Doesn't even matter if it's technically the best solution for THEM, customers are not known for picking the best solutions, nor listening to their providers suggestions for better ones, half the time. And, the simple fact of the market economy is that what the customers want, the providers are going to sell. Making the IP backbones more resilient costs money. You get that money from your customers. You get the customers by selling them what they are asking for. What they are asking for is multihoming. If they can't multihome with IPv6, well, then they won't use IPv6 until they can. If the customers don't want to use IPv6, the providers won't spend the money to support it. ...and this is yet another rehash of a discussion that has already been had so many times by so many people that I'm sure we can just copy & paste from here on out. The fact of the matter is, whether it's the best approach or not, we need a solution for customers to multihome. So let's bring our attention back to that, shall we? /leg From owner-multi6@ops.ietf.org Thu Feb 20 10:21:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17386 for ; Thu, 20 Feb 2003 10:21:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lsYz-0007Cf-00 for multi6-data@psg.com; Thu, 20 Feb 2003 07:24:41 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18lsYw-0007CT-00 for multi6@ops.ietf.org; Thu, 20 Feb 2003 07:24:38 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1KFO0b14663; Thu, 20 Feb 2003 17:24:00 +0200 Date: Thu, 20 Feb 2003 17:24:00 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: "Alan E. Beard" , Tim Chown , , Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <20030220112127.Q61596-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 20 Feb 2003, Iljitsch van Beijnum wrote: > On Thu, 20 Feb 2003, Pekka Savola wrote: > > > > Your comment may be true, but my clients are nonetheless unwilling to risk > > > the possibility of an extended network outage on a single ISP (while not > > > frequent, these events are far from unprecedented) rendering their online > > > customer-support environment unavailable for several hours, much less for > > > a day. Shorter outages (on the order of minutes in the single digits) are > > > tolerated, provided that such outages are infrequent. > > > This is a very problematic approach IMO. > > > Need more resiliency? Network outages unacceptable? > > > The right place to fix this is the network service provider, period. > > Nothing else seems like a scalable approach. > > There is no technical reason why a single service provider network can > do better than a similar network that consists of several smaller > service provider networks. [...] Of course not -- but it's *much* easier. > > Consider a case when many companies _phone_ services would have been > > changed to VoIP. IP would be a critical service. Do the enterprises > > protect against failures by getting more ISP's? Unscalable. No, the > > ISP's _must_ get better. Pick one well when choosing them. > > We are _very_ far from a situation where even the best ISP provides a > service level that is better then the one you get from multihoming even > if you consider failover delays. In some cases, this may be better. In some others, not. It's not IMO necessary to get significantly better but "roughly equal". > > When ISP's have SLA's, a lot of customers for which continued service is > > of utmost importance, the networks *will* work. There is just no other > > choice. If the mobile phone of CTO, CEO or whatever rings after (1)5 > > minutes of network outage, things _will_ happen. > > My experience with SLAs is that they are a marketing tool and job > security for bureaucrats. They don't make the worst case any better, > they only make the worst case slightly less frequent. > > (What makes you think this mobile phone will ring anyway? Speaking of > unreliable networks...) Some means of contacting will always exist, or the monitoring system of ISP's has developed so far the problems in the IP service are extremely rare. > And the single service provider thing doesn't scale anyway: the end > result would have to be a single global ISP. It does scale, pretty well actually. I'm not talking about your average neighborhood ISP's with 100 customers, though. Currently in DFZ, there are about 3500 (ONLY!) AS numbers which transit at least one other AS number. Even multiplying that with 10, we would not have a problem. > > It just seems the mentality in some networks is that network outages are > > ok, networks don't have to be designed with multiple connections, etc.etc. > > > That must change if we want to build a mission-critical IP infrastructure. > > Instead of making every site try to deal with the problems themselves. > > Has the end-to-end principle failed to teach us anything? Reliability > begins and ends in the end hosts. If each host is connected over two > service providers there are four possible paths the hosts can switch > between on a per-packet basis. Then the only problem becomes detecting > failure. The end hosts are in an excellent position to do this without > having to generate keepalive messages; a well designed protocol could > switch to an alternate path within a few round trip times when a path > failure occurs. Compare this to a solution where the site has two connections to the same ISP, and you're left with major ISP backbone failure or upstream failure (any relevant ISP's have only one upstream)? Doesn't sound that difficult to me, particularly as these problems affect the whole (or majority) of the ISP -- and hence, are fixed quickly. A solution without multi-connecting, ie. only one L1 connection to one ISP, is naturally out of question. > Multi6 has been gravitating towards multi-address multihoming solutions > for a while now, but unfortunately it seems impossible to move foward. Multi-address solutions solve certain problems well, but leave some unsolved. Coupling multi-addressing with multi-connecting, you have a very comprehensive solution, IMO. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Feb 20 14:01:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25537 for ; Thu, 20 Feb 2003 14:01:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lvyv-000GtP-00 for multi6-data@psg.com; Thu, 20 Feb 2003 11:03:41 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18lvyc-000GsU-00 for multi6@ops.ietf.org; Thu, 20 Feb 2003 11:03:22 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id E9CA9431E6; Thu, 20 Feb 2003 20:03:20 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 1F98099E6C; Thu, 20 Feb 2003 20:03:20 +0100 (CET) Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] From: marcelo bagnulo To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org In-Reply-To: <20030220112127.Q61596-100000@sequoia.muada.com> References: <20030220112127.Q61596-100000@sequoia.muada.com> Content-Type: text/plain Organization: uc3m Message-Id: <1045767798.723.49.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Feb 2003 20:03:18 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I haven't included ipng since i guess this is out of scope for them. Hi Iljitsch, > Has the end-to-end principle failed to teach us anything? Reliability > begins and ends in the end hosts. If each host is connected over two > service providers there are four possible paths the hosts can switch > between on a per-packet basis. Then the only problem becomes detecting > failure. The end hosts are in an excellent position to do this without > having to generate keepalive messages; How? Thanks, marcelo > a well designed protocol could > switch to an alternate path within a few round trip times when a path > failure occurs. > > Multi6 has been gravitating towards multi-address multihoming solutions > for a while now, but unfortunately it seems impossible to move foward. -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Thu Feb 20 14:10:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25921 for ; Thu, 20 Feb 2003 14:10:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lw8r-000HNR-00 for multi6-data@psg.com; Thu, 20 Feb 2003 11:13:57 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18lw8p-000HNF-00 for multi6@ops.ietf.org; Thu, 20 Feb 2003 11:13:55 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1KJD4x20234; Thu, 20 Feb 2003 20:13:04 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 20 Feb 2003 20:13:03 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Savola cc: "Alan E. Beard" , Tim Chown , , Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: Message-ID: <20030220195703.M61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 20 Feb 2003, Pekka Savola wrote: > > We are _very_ far from a situation where even the best ISP provides a > > service level that is better then the one you get from multihoming even > > if you consider failover delays. > In some cases, this may be better. In some others, not. > It's not IMO necessary to get significantly better but "roughly equal". Don't forget that failover is just one of the benefits of multihoming. Two important others are protection against losing service when ISPs go out of business and more optimal traffic flow. > > And the single service provider thing doesn't scale anyway: the end > > result would have to be a single global ISP. > It does scale, pretty well actually. I'm not talking about your average > neighborhood ISP's with 100 customers, though. Currently in DFZ, there > are about 3500 (ONLY!) AS numbers which transit at least one other AS > number. I don't see your point. What you were saying is that using a single reliable ISP would be better than multihoming. Now obviously an ISP can only control the QoS parameters inside its own network so if you want to do reliable and high quality VoIP you need to use the same ISP end-to-end. In other words: just one ISP. > > Has the end-to-end principle failed to teach us anything? Reliability > > begins and ends in the end hosts. If each host is connected over two > > service providers there are four possible paths the hosts can switch > > between on a per-packet basis. Then the only problem becomes detecting > > failure. The end hosts are in an excellent position to do this without > > having to generate keepalive messages; a well designed protocol could > > switch to an alternate path within a few round trip times when a path > > failure occurs. > Compare this to a solution where the site has two connections to the same > ISP, and you're left with major ISP backbone failure or upstream failure > (any relevant ISP's have only one upstream)? So ISPs get to multihome but not end-users? There are many ways in which an ISP network can fail, as the large scale Worldcom and AT&T outages six months ago illustrate. More common is the situation that an ISP network has trouble reaching a certain destination because the only link to that destination has failed (which in itself may not be their fault) or there is congestion somewhere. And don't forget maintenance windows. > A solution without multi-connecting, ie. only one L1 connection to one > ISP, is naturally out of question. Ok, so why is multihoming to a single ISP better than multihoming to several ISPs? > > Multi6 has been gravitating towards multi-address multihoming solutions > > for a while now, but unfortunately it seems impossible to move foward. > Multi-address solutions solve certain problems well, but leave some > unsolved. Like what? From owner-multi6@ops.ietf.org Thu Feb 20 14:17:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26115 for ; Thu, 20 Feb 2003 14:17:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lwFG-000HgU-00 for multi6-data@psg.com; Thu, 20 Feb 2003 11:20:34 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18lwFB-000HgD-00 for multi6@ops.ietf.org; Thu, 20 Feb 2003 11:20:29 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1KJJg120241; Thu, 20 Feb 2003 20:19:42 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 20 Feb 2003 20:19:42 +0100 (CET) From: Iljitsch van Beijnum To: marcelo bagnulo cc: Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <1045767798.723.49.camel@presto.it.uc3m.es> Message-ID: <20030220201309.H61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 20 Feb 2003, marcelo bagnulo wrote: > > If each host is connected over two > > service providers there are four possible paths the hosts can switch > > between on a per-packet basis. Then the only problem becomes detecting > > failure. The end hosts are in an excellent position to do this without > > having to generate keepalive messages; > How? With TCP you simply monitor incoming ACKs. If there aren't any for a while, when they are expected, something must have gone wrong -> switch to an alternate path. UDP-based protocols can use a similar mechanism, but they often already know how to fall back to a secondary address. The main problem is not switching to an alternate path too aggressively when some packets are lost or there is an increase in delay. From owner-multi6@ops.ietf.org Thu Feb 20 14:51:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27293 for ; Thu, 20 Feb 2003 14:51:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lwm5-000Jer-00 for multi6-data@psg.com; Thu, 20 Feb 2003 11:54:29 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18lwm1-000Jdn-00 for multi6@ops.ietf.org; Thu, 20 Feb 2003 11:54:25 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1KJrlg16575; Thu, 20 Feb 2003 21:53:47 +0200 Date: Thu, 20 Feb 2003 21:53:47 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: "Alan E. Beard" , Tim Chown , , Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <20030220195703.M61596-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 20 Feb 2003, Iljitsch van Beijnum wrote: > On Thu, 20 Feb 2003, Pekka Savola wrote: > > > We are _very_ far from a situation where even the best ISP provides a > > > service level that is better then the one you get from multihoming even > > > if you consider failover delays. > > > In some cases, this may be better. In some others, not. > > > It's not IMO necessary to get significantly better but "roughly equal". > > Don't forget that failover is just one of the benefits of multihoming. > Two important others are protection against losing service when ISPs > go out of business Sure, independence is another issue -- not related to ISP failures, and there are ways to protect against this. > and more optimal traffic flow. I agree, but other than really simple traffic flow balancing (read: multiple addresses) is a difficult thing to do, and people don't often really do it. > > > And the single service provider thing doesn't scale anyway: the end > > > result would have to be a single global ISP. > > > It does scale, pretty well actually. I'm not talking about your average > > neighborhood ISP's with 100 customers, though. Currently in DFZ, there > > are about 3500 (ONLY!) AS numbers which transit at least one other AS > > number. > > I don't see your point. What you were saying is that using a single > reliable ISP would be better than multihoming. Considering the tradeoffs, yes. > Now obviously an ISP can > only control the QoS parameters inside its own network so if you want to > do reliable and high quality VoIP you need to use the same ISP > end-to-end. In other words: just one ISP. This seems like a ridiculous argument or I'm missing something. You could just use VoIP up to the ISP, have ISP's coordinate the parameters (if you need any), etc. This is no different than multihomed scenario. > > > Has the end-to-end principle failed to teach us anything? Reliability > > > begins and ends in the end hosts. If each host is connected over two > > > service providers there are four possible paths the hosts can switch > > > between on a per-packet basis. Then the only problem becomes detecting > > > failure. The end hosts are in an excellent position to do this without > > > having to generate keepalive messages; a well designed protocol could > > > switch to an alternate path within a few round trip times when a path > > > failure occurs. > > > Compare this to a solution where the site has two connections to the same > > ISP, and you're left with major ISP backbone failure or upstream failure > > (any relevant ISP's have only one upstream)? > > So ISPs get to multihome but not end-users? Yes. > There are many ways in which an ISP network can fail, as the large scale > Worldcom and AT&T outages six months ago illustrate. I'm not aware of the case, so I can't really comment. Pointers? > More common is the > situation that an ISP network has trouble reaching a certain destination > because the only link to that destination has failed (which in itself > may not be their fault) or there is congestion somewhere. This seems no different than the case when using BGP site multihoming -- unless you want the fine-tune your policy per destination -- a non-starter. > And don't > forget maintenance windows. No real ISP has maintenance windows that seriously affect all communications at once. > > A solution without multi-connecting, ie. only one L1 connection to one > > ISP, is naturally out of question. > > Ok, so why is multihoming to a single ISP better than multihoming to > several ISPs? Fewer tradeoffs: you can protect against most failure modes, while not having to hae AS, your own IP addresses etc -- that is, it doesn't require bloating the DFZ! > > > Multi6 has been gravitating towards multi-address multihoming solutions > > > for a while now, but unfortunately it seems impossible to move foward. > > > Multi-address solutions solve certain problems well, but leave some > > unsolved. > > Like what? Solves: operator independence Doesn't solve: connection survivability, short-term failures, more than basic TE [mostly a non-issue IMO] Mixing multiconnecting to one ISP and having a backup to the second one gives you mostly everything. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Feb 20 19:44:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04987 for ; Thu, 20 Feb 2003 19:44:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m1Li-000B8o-00 for multi6-data@psg.com; Thu, 20 Feb 2003 16:47:34 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18m1Ig-000AyW-01 for multi6@ops.ietf.org; Thu, 20 Feb 2003 16:44:26 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18m02T-0004y1-00 for multi6@ops.ietf.org; Fri, 21 Feb 2003 08:23:37 +0900 Message-ID: <33CE6457C7003A478381BCD0B584DEC502740E64@srmoon.eng.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "sasson, shuki" To: ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: IPv6 message size with OpenBSD. Is it a must that IPv6 packet len gth will be a multiply of 8? Date: Thu, 20 Feb 2003 11:24:51 -0500 X-Spam-Status: No, hits=0.6 required=5.0 tests=RESENT_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA04987 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi all, observing the code of OpenBSD and also trying it, I see that the code takes care that the IPv6 packet length will be a multiplication of 8. I read the IPv6 RFC 2460 and I didn't see ant restriction there that suggests that the IPv6 packet length should be a multiplication of 8. Does any of you have an idea why is that? Can I safely send IPv6 packet with a length that is not a multiplication of 8 and make a better use of the MTU? Example:: In a system where the MTU is 1500 the Ethernet packet sent in OpenBSD systems are 1510 instead of 1514 thus a loss of additional 4 bytes as a result. Your help is appreciated, Shuki Sasson Principal Engineer, Network Storage Group EMC² where information lives Phone: 508 305 8515 FaxNo: 508 435 8901 Pager: 877 919 0794 Email: sasson_shuki@emc.com From owner-multi6@ops.ietf.org Fri Feb 21 09:21:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01102 for ; Fri, 21 Feb 2003 09:21:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mE4g-000OYt-00 for multi6-data@psg.com; Fri, 21 Feb 2003 06:22:50 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18mE4c-000OYY-00 for multi6@ops.ietf.org; Fri, 21 Feb 2003 06:22:46 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1LELuC22074; Fri, 21 Feb 2003 15:21:56 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 21 Feb 2003 15:21:56 +0100 (CET) From: Iljitsch van Beijnum To: "sasson, shuki" cc: , Subject: Re: IPv6 message size with OpenBSD. Is it a must that IPv6 packet len gth will be a multiply of 8? In-Reply-To: <33CE6457C7003A478381BCD0B584DEC502740E64@srmoon.eng.emc.com> Message-ID: <20030221140414.L61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 20 Feb 2003, sasson, shuki wrote: > Hi all, observing the code of OpenBSD and also trying it, I see that the > code takes care that the IPv6 packet length will be a multiplication of 8. > I read the IPv6 RFC 2460 and I didn't see ant restriction there that > suggests that the IPv6 packet length should be a multiplication of 8. > Does any of you have an idea why is that? > Can I safely send IPv6 packet with a length that is not a multiplication of > 8 and make a better use of the MTU? This is confusing. You talk about IP, but what you really mean is TCP. IP can't modify packet sizes: it must always use the exact size of the payload data because there is no provision for padding the payload. But TCP gets to divide the data over multiple packets. If a TCP implementation decides it is more efficient to use multiples of 8 bytes for the payload than fill up the maximum packet size, it is free to do so. (For sending. For receiving it just has to take whatever the other end sends as long as it's within the maximum segment size.) I did some tests with www.netbsd.org (assuming they use their own stuff for their web server) and I don't see what you're talking about: 13:58:07.491586 3ffe:2500:310:1:203:93ff:fec5:2d28.49510 > www.netbsd.org.http: S [tcp sum ok] 579406933:579406933(0) win 32768 (len 40, hlim 64) 13:58:07.785009 www.netbsd.org.http > 3ffe:2500:310:1:203:93ff:fec5:2d28.49510: S [tcp sum ok] 2373548153:2373548153(0) ack 579406934 win 32768 (len 40, hlim 56) 13:58:08.261964 www.netbsd.org.http > 3ffe:2500:310:1:203:93ff:fec5:2d28.49510: . 1:1209(1208) ack 494 win 33120 [flowlabel 0x83ed9] (len 1240, hlim 56) And it seems they play fast and loose with the specs in v4: 14:45:56.117122 torreya.muada.com.49566 > www.netbsd.org.http: S [bad tcp cksum 8118!] 452120277:452120277(0) win 32768 (DF) (ttl 64, id 12748, len 60) 14:45:56.288690 www.netbsd.org.http > torreya.muada.com.49566: S [tcp sum ok] 192546578:192546578(0) ack 452120278 win 32768 (ttl 51, id 17146, len 60) 14:45:56.612624 www.netbsd.org.http > torreya.muada.com.49566: . 1:1449(1448) ack 303 win 33580 (ttl 51, id 17162, len 1500) I don't get why they send the MSS option if they're going to ignore it anyway. From owner-multi6@ops.ietf.org Fri Feb 21 11:11:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04906 for ; Fri, 21 Feb 2003 11:11:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mFnp-0003xL-00 for multi6-data@psg.com; Fri, 21 Feb 2003 08:13:33 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 18mFnh-0003wy-00 for multi6@ops.ietf.org; Fri, 21 Feb 2003 08:13:28 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02978; Fri, 21 Feb 2003 08:13:20 -0800 (PST) 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 h1LGDJP25486; Fri, 21 Feb 2003 17:13:19 +0100 (MET) Date: Fri, 21 Feb 2003 17:09:35 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Draft: PI addressing derived from AS numbers To: "J. Noel Chiappa" Cc: brian@hursley.ibm.com, multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200302040115.h141FOXC002924@ginger.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Unless you start using multiple headers (which is sort of already specified, > which is why I like 16+16, although it has all the obvious "source routing" > security bugs), there's only a single IPv6 address field in "IPv6 > *unmodified*", so it's kind of hard to do both with one field. HIP can help with the "source routing" security bugs. One question in my mind is whether that type of approach requires IPsec protection of every packet, or if one can limit this to a subset of the packets (like the TCP SYN/SYN-ACK exchange). Another question, once we have the architectural 16+16 picture clear, is whether it is possible to do "header compression" to avoid having 4*16 bytes of identifiers+locators in every packet. A third question is whether one can make this work with both hosts doing 16+16 (which might provide a stronger security binding) and site border routers doing it (which would be easier to deploy using existing IPv6 implementations in the hosts). I'll stop now, Erik From owner-multi6@ops.ietf.org Fri Feb 21 11:31:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05708 for ; Fri, 21 Feb 2003 11:31:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mG7a-0005CC-00 for multi6-data@psg.com; Fri, 21 Feb 2003 08:33:58 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18mG7U-0005Bz-00 for multi6@ops.ietf.org; Fri, 21 Feb 2003 08:33:53 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29799; Fri, 21 Feb 2003 09:33:48 -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 h1LGXlP28181; Fri, 21 Feb 2003 17:33:47 +0100 (MET) Date: Fri, 21 Feb 2003 17:30:03 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: GSE To: Kurt Erik Lindqvist Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <609F1A25-41F0-11D7-874A-000393AB1404@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Ok, I have re-read Mike O'Dells old draft from 1997. Can someone remind > me what the reasons for not going with this was? Part of it being fear of the unknown and doing something so radical to IPv6. Part of it being some technical aspects (such as the impact of not having a checksum on the source locator causing new failures, and security issues related to relaxing the binding between identifiers and locators). An attampt to capture the technical issues is in http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-ipngwg-esd-analysis-05.txt (Yes, www.ietf.org can search across all documents at the internet drafts web page.) Note that the security issues due to the relaxation can be solved by stuff like HIP. Erik From owner-multi6@ops.ietf.org Fri Feb 21 12:45:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08566 for ; Fri, 21 Feb 2003 12:45:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mHHA-00099F-00 for multi6-data@psg.com; Fri, 21 Feb 2003 09:47:56 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18mHGv-00098h-00 for multi6@ops.ietf.org; Fri, 21 Feb 2003 09:47:42 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 2D14A8E0B; Fri, 21 Feb 2003 12:47:40 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 12:47:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Date: Fri, 21 Feb 2003 12:47:39 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240F3E@tayexc13.americas.cpqcorp.net> Thread-Topic: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Thread-Index: AcLY0H8B1jpsDoObQmyT6Em+LRkvSQA/zWZQ From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Pekka Savola" Cc: "Alan E. Beard" , "Tim Chown" , , X-OriginalArrivalTime: 21 Feb 2003 17:47:39.0861 (UTC) FILETIME=[53E39050:01C2D9D1] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA08566 Folks, I am on multi6 and just listen and send clarification questions to various participants. But a short comment here. > Has the end-to-end principle failed to teach us anything? > Reliability begins and ends in the end hosts. If each host is > connected over two service providers there are four possible > paths the hosts can switch between on a per-packet basis. > Then the only problem becomes detecting failure. The end > hosts are in an excellent position to do this without having > to generate keepalive messages; a well designed protocol > could switch to an alternate path within a few round trip > times when a path failure occurs. I agree with the above view and much of the problem can be solved by intelligent code and configuration being done by the end system for new IPv6 development and some existing network application infrastructure that is a direct port from IPv4 that has been ported and deployed. SCTP is a clear winner for us here over TCP and it's a new API so we could go there. But more importantly the transition to this requires code on the end systems from suppliers, and then either apps change or shims are built on the end systems. Doing it with TCP is possible till SCTP is more dominant. This is solving the problem at layer 7 and 4. And that means we need new platform code releases and development to make it happen. Which is fine but will take time. Layer 1 and 3 may be able to do something too but that will take time and require new code and platform releases. I think we need to first pick which way we want to specify this or both and provide technical spec on what each mean. It is really transparent to IPv6 but IPv6 has a better chance of getting this right. > Multi6 has been gravitating towards multi-address multihoming > solutions for a while now, but unfortunately it seems > impossible to move foward. Hmmm. At some point this needs to get done folks. Not sure what will cause it, but I believe it may be external forces resolve it for us. P.S. Mutli6 should not MUST SCTP as Diameter tried (well was forced) that and all the Diameter products shipping are doing it with TCP and same for some other things like RDMA. But Multi6 could do the community a big favor by stressing that SCTP really helps this problem within its inherent failover capabilities via the network association for the connections. Regards, /jim > > > From owner-multi6@ops.ietf.org Fri Feb 21 13:04:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09342 for ; Fri, 21 Feb 2003 13:04:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mHaD-000AbA-00 for multi6-data@psg.com; Fri, 21 Feb 2003 10:07:37 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18mHZw-000AZm-00 for multi6@ops.ietf.org; Fri, 21 Feb 2003 10:07:21 -0800 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id CA5026710B; Fri, 21 Feb 2003 13:19:53 -0500 (EST) Date: Fri, 21 Feb 2003 13:07:02 -0500 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Erik Nordmark From: RJ Atkinson In-Reply-To: Message-Id: <4719ECDA-45C7-11D7-A186-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Feb 21, 2003, at 11:09 America/Montreal, Erik Nordmark wrote: > HIP can help with the "source routing" security bugs. AH can also do that without changes -- the trick for AH and HIP is key management, as always with security gorp. In fact, AH was designed to be able to authenticate *any* IP extension header (or option). ESP can only authenticate stuff inside the ESP payload. This difference between AH and ESP (null-encryption) is not as widely understood as maybe it ought to be. > One question in my mind is whether that type of approach requires > IPsec protection of every packet, or if one can limit this to a subset > of the packets (like the TCP SYN/SYN-ACK exchange). Unclear to me how one avoids cryptographic on each source-routed packet. On the other hand, 16+16 or 8+8 doesn't necessarily involve source-routing. > Another question, once we have the architectural 16+16 picture clear, > is whether it is possible to do "header compression" to avoid having > 4*16 > bytes of identifiers+locators in every packet. The other approach would be to run with 8+8. If 16+16 works, 8+8 can also work since they are architecturally the same. > A third question is whether one can make this work with both hosts > doing > 16+16 (which might provide a stronger security binding) and site border > routers doing it (which would be easier to deploy using existing IPv6 > implementations in the hosts). I don't follow that sentence. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Fri Feb 21 13:06:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09407 for ; Fri, 21 Feb 2003 13:06:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mHcT-000Amc-00 for multi6-data@psg.com; Fri, 21 Feb 2003 10:09:57 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18mHcO-000Alz-00 for multi6@ops.ietf.org; Fri, 21 Feb 2003 10:09:53 -0800 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 968726710B; Fri, 21 Feb 2003 13:22:42 -0500 (EST) Date: Fri, 21 Feb 2003 13:09:51 -0500 Subject: Re: GSE Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Erik Nordmark From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Feb 21, 2003, at 11:30 America/Montreal, Erik Nordmark wrote: > Part of it being some technical aspects (such as the impact of not > having a checksum on the source locator causing new failures, That's a tractable implementation detail. > and security issues related to relaxing the binding between identifiers > and locators). The Security ADs and security-aware IAB folks did not believe that such issues were real. > An attampt to capture the technical issues is in > http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-ipngwg-esd- > analysis-05.txt And note that a whole lot of folks objected to that being published as an RFC on grounds that it was analysing something different from what O'Dell proposed and also because there were sundry incorrect assertions (including, but not limited to, security claims) inside it. > Note that the security issues due to the relaxation can be solved > by stuff like HIP. See smb's comments at www.research.att.com, URL posted by someone else a few days back. HIP has no special magic in this regard. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Fri Feb 21 13:33:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10139 for ; Fri, 21 Feb 2003 13:33:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mI1z-000CTi-00 for multi6-data@psg.com; Fri, 21 Feb 2003 10:36:19 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18mI1t-000CTH-00 for multi6@ops.ietf.org; Fri, 21 Feb 2003 10:36:14 -0800 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 h1LIa6TW018340; Fri, 21 Feb 2003 13:36:06 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1LIa6SF018339; Fri, 21 Feb 2003 13:36:06 -0500 Date: Fri, 21 Feb 2003 13:36:06 -0500 From: "J. Noel Chiappa" Message-Id: <200302211836.h1LIa6SF018339@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: GSE Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Erik Nordmark >> I have re-read Mike O'Dells old draft .. Can someone remind me what >> the reasons for not going with this was? > Part of it being fear of the unknown and doing something so radical to > IPv6. There's a great deal of truth to that (in fact, my personal opinion is that it was, at the root, the main cause why GSE - and all the other GSE-like proposals prior to it - did not catch on). That's all water under the bridge now, though. Let's move on... Noel From owner-multi6@ops.ietf.org Fri Feb 21 19:49:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19940 for ; Fri, 21 Feb 2003 19:49:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mNsd-0009xf-00 for multi6-data@psg.com; Fri, 21 Feb 2003 16:51:03 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18mNs7-0009v2-00 for multi6@ops.ietf.org; Fri, 21 Feb 2003 16:50:31 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1M0nTH22827; Sat, 22 Feb 2003 01:49:29 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 22 Feb 2003 01:49:29 +0100 (CET) From: Iljitsch van Beijnum To: "Bound, Jim" cc: Pekka Savola , "Alan E. Beard" , Tim Chown , , Subject: RE: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240F3E@tayexc13.americas.cpqcorp.net> Message-ID: <20030222012453.G61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 21 Feb 2003, Bound, Jim wrote: > SCTP > is a clear winner for us here over TCP and it's a new API so we could go > there. But more importantly the transition to this requires code on the > end systems from suppliers, and then either apps change or shims are > built on the end systems. Doing it with TCP is possible till SCTP is > more dominant. This is solving the problem at layer 7 and 4. And that > means we need new platform code releases and development to make it > happen. Which is fine but will take time. > Layer 1 and 3 may be able to do something too but that will take time > and require new code and platform releases. Well, the "let's do it fast" ship has sailed a long time ago (it is presumed to have hit an iceberg). So we only have the choice to do it right or not. It's time we start to rethink what we're trying to do here. Sure, SCTP will provide some functionality. HIP also. Add a header here, a tunnel there, maybe a little aggregation... It will all help with the problem at hand to a certain degree, but it will break nearly as much as it will fix and in 10 years we'll be doing it all again for IPv7 or OSIv3. The problem with the IPv4->IPv6 transition is that all applications have to change. That sucks. So what is it we do? We replace the socket API that sucks with an API that sucks with bigger addresses. If we're going to do SCTP, we'll be replacing the API with one that sucks with multiple addresses. (I'm not about to apologize for saying the socket API sucks, I've programmed with it.) If we're going to change applications, we need to do it in such a way that we won't have to do it again. So regular applications such as remote login, email or webbrowsing only get to see the information about a connection that they must, by their nature, always be able to parse. That would be a hostname. Or an email address. Or maybe even an X.509 certificate. But NOT the plumbing, because we'll want to change that later as new technology becomes available, WITHOUT having to change our apps again. If we can agree on this and recognize the fact that changing the IPv6 packet format and routing paradigm at this stage is counterproductive, the rest should be easy. > P.S. Mutli6 should not MUST SCTP as Diameter tried (well was forced) > that and all the Diameter products shipping are doing it with TCP and > same for some other things like RDMA. But Multi6 could do the community > a big favor by stressing that SCTP really helps this problem within its > inherent failover capabilities via the network association for the > connections. No idea what you're referring to here. From owner-multi6@ops.ietf.org Sat Feb 22 00:34:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25408 for ; Sat, 22 Feb 2003 00:34:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mSKF-0000cm-00 for multi6-data@psg.com; Fri, 21 Feb 2003 21:35:51 -0800 Received: from tele2-1-1-dialup-125.freesurf.ch ([194.230.196.125] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18mSJe-0000ZN-00; Fri, 21 Feb 2003 21:35:16 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1M5Yjif008512; Sat, 22 Feb 2003 06:34:57 +0100 (CET) Date: Fri, 21 Feb 2003 16:19:36 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Alan E. Beard" , Tim Chown , , , To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.4 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I'll take one particular issue, and Cc: to multi6 as I believe it is a > very important thing to consider. > > On Fri, 14 Feb 2003, Alan E. Beard wrote: >>>> Most of the end-user-network managers among my clients now >>>> multihome, >>>> and >>>> will continue to require multihomed service in future. In every >>>> case >>>> where the user's network is multihomed, the multiple independent >>>> connections are seen as crucial for maintenance of high >>>> availability of >>> >>> [Kurtis:] >>> I find this funny. A number of studies have shown that if this is >>> what >>> you are after, multihoming and BGP is the wrong way to go - but never >>> mind. >>> >> Your comment may be true, but my clients are nonetheless unwilling to >> risk >> the possibility of an extended network outage on a single ISP (while >> not >> frequent, these events are far from unprecedented) rendering their >> online >> customer-support environment unavailable for several hours, much less >> for >> a day. Shorter outages (on the order of minutes in the single >> digits) are >> tolerated, provided that such outages are infrequent. > > This is a very problematic approach IMO. > > Need more resiliency? Network outages unacceptable? > > The right place to fix this is the network service provider, period. > Nothing else seems like a scalable approach. > > Consider a case when many companies _phone_ services would have been > changed to VoIP. IP would be a critical service. Do the enterprises > protect against failures by getting more ISP's? Unscalable. No, the > ISP's _must_ get better. Pick one well when choosing them. > > When ISP's have SLA's, a lot of customers for which continued service > is > of utmost importance, the networks *will* work. There is just no other > choice. If the mobile phone of CTO, CEO or whatever rings after (1)5 > minutes of network outage, things _will_ happen. > > It just seems the mentality in some networks is that network outages > are > ok, networks don't have to be designed with multiple connections, > etc.etc. > > That must change if we want to build a mission-critical IP > infrastructure. > Instead of making every site try to deal with the problems themselves. > > This is my view as ISP and an end-user. > This highlights another issue with the solution to the multi6 problem - convergence time. We need a solution that also improves this, besides scales in the DFZ. - kurtis - From owner-multi6@ops.ietf.org Sat Feb 22 00:45:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25527 for ; Sat, 22 Feb 2003 00:45:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mSWA-0001MW-00 for multi6-data@psg.com; Fri, 21 Feb 2003 21:48:10 -0800 Received: from tele2-1-1-dialup-125.freesurf.ch ([194.230.196.125] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18mSVZ-0001H8-00 for multi6@ops.ietf.org; Fri, 21 Feb 2003 21:47:35 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1M5kBif008668; Sat, 22 Feb 2003 06:46:29 +0100 (CET) Date: Fri, 21 Feb 2003 16:29:22 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Pekka Savola , "Alan E. Beard" , Tim Chown , , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030220112127.Q61596-100000@sequoia.muada.com> Message-Id: <40BA4A2F-45B1-11D7-932B-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.7 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > There is no technical reason why a single service provider network can > do better than a similar network that consists of several smaller > See Abha and Craigs paper on convergence of BGP. Personally I would go for a large provider with multiple connections. Last fall I was invited to a conference in Sweden to debate multihoming and the enterprise. Before me was this enterprise IT manager who showed how much more resilient his network was with two BGP sessions. While he talked I checked his announcements just to find that one of the providers bought transit from the other. You can't buy clue. > service provider networks. Sure, BGP as-is doesn't provide the seamless > failorver some people would like. It annoys me to no end that Cisco > uses > a 180 second default hold time for BGP, twice the already too > conservative value that is is suggested in the RFC. This means that > when > a circuit goes down BGP takes two or three minutes to notice this. I > always recommend configuring a hold time of 15 seconds, but it seems > some vendors have designed their stuff in such a way that sessions can > fail with this value when the box is busy. But IGPs have the same > fundamental problem (although the details may differ). OSPF for > instance > takes 40 seconds to detect a dead circuit. there was a fix proposed in San Diego (although for IS-IS) but that was voted down. There was pros and cons. > We are _very_ far from a situation where even the best ISP provides a > service level that is better then the one you get from multihoming even > if you consider failover delays. I would like to see numbers for this. My experience says otherwise. Perhaps CAIDA have something on this? Or the RIPE RIS boxes could give some insight. > > Also, these approaches aren't mutually exclusive. ISPs should get > better. Multihoming should get better. Yes, but not for the same reasons. > At the same time, we should recognize that it is simply impossible to > have the same failover delays at layer 3 as at layer 1. From my experience you can get very close, but I am very close to a NDA I have signed. > My experience with SLAs is that they are a marketing tool and job > security for bureaucrats. They don't make the worst case any better, > they only make the worst case slightly less frequent. To some extent I agree. There was inflation in SLAs some year ago. This was bad for the entire industry. - kurtis - From owner-multi6@ops.ietf.org Sat Feb 22 00:46:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25561 for ; Sat, 22 Feb 2003 00:46:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mSXm-0001UU-00 for multi6-data@psg.com; Fri, 21 Feb 2003 21:49:50 -0800 Received: from tele2-1-1-dialup-125.freesurf.ch ([194.230.196.125] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18mSWo-0001Q7-00; Fri, 21 Feb 2003 21:48:52 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1M5lqif008671; Sat, 22 Feb 2003 06:48:19 +0100 (CET) Date: Fri, 21 Feb 2003 16:35:15 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Pekka Savola , "Alan E. Beard" , Tim Chown , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org, randy@psg.com To: Lars Erik Gullerud From: Kurt Erik Lindqvist In-Reply-To: <1045753567.81330.33.camel@sabre.ncc.catchcom.no> Message-Id: <12EFDD17-45B2-11D7-932B-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.1 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > In a perfect world I'm sure I'd agree with you. In real life however, > the fact of the matter is that customers want multihoming, and it > doesn't matter to the customers if that is a problematic approach that > doesn't scale for the SPs. Doesn't even matter if it's technically the > best solution for THEM, customers are not known for picking the best > solutions, nor listening to their providers suggestions for better > ones, > half the time. And, the simple fact of the market economy is that what > the customers want, the providers are going to sell. ....which explains a lot of bad stuff being deployed, but that is another WG..:=) > > Making the IP backbones more resilient costs money. You get that money > from your customers. You get the customers by selling them what they > are > asking for. What they are asking for is multihoming. If they can't > multihome with IPv6, well, then they won't use IPv6 until they can. If > the customers don't want to use IPv6, the providers won't spend the > money to support it. Agreed!!! > ...and this is yet another rehash of a discussion that has already been > had so many times by so many people that I'm sure we can just copy & > paste from here on out. > > The fact of the matter is, whether it's the best approach or not, we > need a solution for customers to multihome. So let's bring our > attention > back to that, shall we? > Agreed. I have a suggestion....:) - kurtis - From owner-multi6@ops.ietf.org Sat Feb 22 04:31:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07910 for ; Sat, 22 Feb 2003 04:31:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mW1R-000EFB-00 for multi6-data@psg.com; Sat, 22 Feb 2003 01:32:41 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18mW0v-000EEs-00 for multi6@ops.ietf.org; Sat, 22 Feb 2003 01:32:09 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1M9V9C26012; Sat, 22 Feb 2003 10:31:09 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 22 Feb 2003 10:31:04 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Pekka Savola , "Alan E. Beard" , Tim Chown , , Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <40BA4A2F-45B1-11D7-932B-000393AB1404@kurtis.pp.se> Message-ID: <20030222101339.D61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 21 Feb 2003, Kurt Erik Lindqvist wrote: > > There is no technical reason why a single service provider network can > > do better than a similar network that consists of several smaller > See Abha and Craigs paper on convergence of BGP. Personally I would go > for a large provider with multiple connections. Based on this paper? What I see is rarely as bad as what they describe. However, I had the chance to experiment a little with revoking a longer prefix and then see how soon the shorter prefix would "catch" the traffic a while back, and this was certainly interesting: the state goes back and forth between "working" and "not working" several times over the course of two minutes. But simple failover is usually pretty fast. If failover times when a circuit goes down are your main concern, connecting to the same ISP twice makes a lot of sense. (Use a non-switched network for this, though, or you'll be at the mercy of the hold time.) On the other hand your failover time when in case of an ISP failure is much worse this way. Personally, I'd rather eat the two minute failover and be protected against the two week one than the other way around, even if the former happens once every few months and the latter may not happen at all. > Last fall I was invited to a conference in Sweden to debate multihoming > and the enterprise. Before me was this enterprise IT manager who showed > how much more resilient his network was with two BGP sessions. While he > talked I checked his announcements just to find that one of the > providers bought transit from the other. You can't buy clue. You can buy a good book that explains it all. :-) Did you check to see if the second ISPs also had additional upstreams? > > But IGPs have the same > > fundamental problem (although the details may differ). OSPF for > > instance takes 40 seconds to detect a dead circuit. > there was a fix proposed in San Diego (although for IS-IS) but that was > voted down. There was pros and cons. Just type: ip ospf hello-interval 1 ip ospf dead-interval 3 But do it on ALL your boxes in the subnet or you'll live to regret it. From owner-multi6@ops.ietf.org Sat Feb 22 08:14:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10480 for ; Sat, 22 Feb 2003 08:14:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mZUj-000PED-00 for multi6-data@psg.com; Sat, 22 Feb 2003 05:15:09 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18mZTx-000PCe-00 for multi6@ops.ietf.org; Sat, 22 Feb 2003 05:14:21 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1MDEHh17323; Sat, 22 Feb 2003 14:14:17 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h1MDBMof043539; Sat, 22 Feb 2003 14:11:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302221311.h1MDBMof043539@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: RJ Atkinson cc: marcelo bagnulo , Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: GSE In-reply-to: Your message of Mon, 17 Feb 2003 08:11:40 EST. <5A20A8C2-4279-11D7-AC71-00039357A82A@extremenetworks.com> Date: Sat, 22 Feb 2003 14:11:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: > I guess that the long answer to your question can be found at: > > draft-ietf-ipngwg-esd-analysis-*.txt That draft was never published as an RFC mostly because the IESG, IAB, and several IETF Security Directorate members believed that it was not factually correct. The biggest issue is that it does not describe the actual GSE/8+8 proposal accurately -- so the criticisms are of something not quite the same as GSE/8+8. This is NOT to imply that the IESG, IAB, or other folks thought that GSE/8+8 was without problems -- merely that the above draft was not on-target in its claims. So folks should add a lot of salt when reading that draft. => but this draft (draft-ietf-ipngwg-esd-analysis-05.txt) remains the best introduction to two-space systems... I remember the interim meeting where GSE/8+8 was not adopted: the main problem was failover. Please lets move forward on multi6, rather than revisiting painful old IPng WG history here. => two-space systems are still raisonable long term solutions, especially HIP (Host Identity Payload Protocol) which doesn't share the security concern on the binding between the locator and the identity. (PS: and its overhead is not a problem for guys like me who'd like to hide everything behind ESP :-). Thanks Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Sat Feb 22 09:18:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11073 for ; Sat, 22 Feb 2003 09:18:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18maW7-0002eD-00 for multi6-data@psg.com; Sat, 22 Feb 2003 06:20:39 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18maVb-0002cx-00 for multi6@ops.ietf.org; Sat, 22 Feb 2003 06:20:07 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1MEJEN26294; Sat, 22 Feb 2003 15:19:14 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 22 Feb 2003 15:19:14 +0100 (CET) From: Iljitsch van Beijnum To: Francis Dupont cc: RJ Atkinson , marcelo bagnulo , Kurt Erik Lindqvist , Subject: Re: GSE In-Reply-To: <200302221311.h1MDBMof043539@givry.rennes.enst-bretagne.fr> Message-ID: <20030222143351.H61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 22 Feb 2003, Francis Dupont wrote: > => two-space systems are still raisonable long term solutions, especially > HIP (Host Identity Payload Protocol) which doesn't share the security > concern on the binding between the locator and the identity. > (PS: and its overhead is not a problem for guys like me who'd like > to hide everything behind ESP :-). Is there a good write-up of HIP yet? We should really watch the overhead, because most of the time it's simply unnecessary. Want do do voice over IP with IPsec? If you don't do the IPsec in the phone, you MUST use tunnel mode as per the RFC. But you can't do routing over IPsec tunnels, so you need another GRE tunnel. Then comes the ESP overhead, which is actually fairly small but they chose to inlcude padding, which IMO was a mistake. Also, the initialization vectors eat up a fair number of bytes, while it wouldn't be very hard to come up with a scheme where the IV isn't carried inside the packet. Then of course we encapsulate all of this in an ethernet frame which wastes 64 bits on a preamble and 160 bits on an inter frame gap, which are necessary to make the manchester encoding work. Since we typically use ethernet with encodings that regulate this stuff at even lower layers, most of these 20 bytes are wasted for no reason. So in order to carry a 64 kbps voice stream in more or less 64 kbps and have a reasonable delay, we need to compress the actual payload by a factor 4 to make room for the overhead, which is then 78%. About half of this could be removed without any impact to functionality. The problem with many headers is that they implement too much. Ideally, each function would have its own header so you only need to include the headers you're actually going to use. (IPv6 options have the right idea.) But of course that leads to header recognition overhead, where each header needs a header... From owner-multi6@ops.ietf.org Sat Feb 22 10:02:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11677 for ; Sat, 22 Feb 2003 10:02:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mbCT-00050x-00 for multi6-data@psg.com; Sat, 22 Feb 2003 07:04:25 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #1) id 18mbBS-0004xH-00 for multi6@ops.ietf.org; Sat, 22 Feb 2003 07:03:22 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h1MF3Hh18394; Sat, 22 Feb 2003 16:03:18 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h1MF0Oof044344; Sat, 22 Feb 2003 16:00:24 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200302221500.h1MF0Oof044344@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Iljitsch van Beijnum cc: RJ Atkinson , marcelo bagnulo , Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: GSE In-reply-to: Your message of Sat, 22 Feb 2003 15:19:14 +0100. <20030222143351.H61596-100000@sequoia.muada.com> Date: Sat, 22 Feb 2003 16:00:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: On Sat, 22 Feb 2003, Francis Dupont wrote: > => two-space systems are still raisonable long term solutions, especially > HIP (Host Identity Payload Protocol) which doesn't share the security > concern on the binding between the locator and the identity. > (PS: and its overhead is not a problem for guys like me who'd like > to hide everything behind ESP :-). Is there a good write-up of HIP yet? => draft-jokela-hip-packets-xx.txt and old I-Ds by Robert Moskowitz. We should really watch the overhead, because most of the time it's simply unnecessary. Want do do voice over IP with IPsec? If you don't do the IPsec in the phone, you MUST use tunnel mode as per the RFC. => HIP is end-to-end. But you can't do routing over IPsec tunnels, so you need another GRE tunnel. => fortunately this is not 100% true. Then comes the ESP overhead, which is actually fairly small but they chose to inlcude padding, which IMO was a mistake. Also, the initialization vectors eat up a fair number of bytes, while it wouldn't be very hard to come up with a scheme where the IV isn't carried inside the packet. => both are properties of the algorithm(s), not of ESP itself. And security has a price... Then of course we encapsulate all of this in an ethernet frame which wastes 64 bits on a preamble and 160 bits on an inter frame gap, which are necessary to make the manchester encoding work. Since we typically use ethernet with encodings that regulate this stuff at even lower layers, most of these 20 bytes are wasted for no reason. So in order to carry a 64 kbps voice stream in more or less 64 kbps and have a reasonable delay, we need to compress the actual payload by a factor 4 to make room for the overhead, which is then 78%. About half of this could be removed without any impact to functionality. => if they could be removed they could be compressed too. The problem with many headers is that they implement too much. Ideally, each function would have its own header so you only need to include the headers you're actually going to use. (IPv6 options have the right idea.) But of course that leads to header recognition overhead, where each header needs a header... => I am afraid we are outside the scope of the MULTI6 list. Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Sat Feb 22 10:29:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12043 for ; Sat, 22 Feb 2003 10:29:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mbd0-0006Zw-00 for multi6-data@psg.com; Sat, 22 Feb 2003 07:31:50 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18mbcU-0006Wj-00 for multi6@ops.ietf.org; Sat, 22 Feb 2003 07:31:18 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1MFUUU26390; Sat, 22 Feb 2003 16:30:30 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 22 Feb 2003 16:30:29 +0100 (CET) From: Iljitsch van Beijnum To: Francis Dupont cc: Subject: Re: GSE In-Reply-To: <200302221500.h1MF0Oof044344@givry.rennes.enst-bretagne.fr> Message-ID: <20030222162122.P61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 22 Feb 2003, Francis Dupont wrote: > Is there a good write-up of HIP yet? > => draft-jokela-hip-packets-xx.txt and old I-Ds by Robert Moskowitz. Excellent, I'll look them up. > But you can't do routing over IPsec tunnels, so you need another > GRE tunnel. > => fortunately this is not 100% true. I meant "routing protocols" here. > Then comes the ESP overhead, which is actually fairly small but they > chose to inlcude padding, which IMO was a mistake. Also, the > initialization vectors eat up a fair number of bytes, while it wouldn't > be very hard to come up with a scheme where the IV isn't carried inside > the packet. > => both are properties of the algorithm(s), not of ESP itself. Yes, padding and IVs are necessary. But that doesn't mean they have to be carried in the packets. If you use a stream cipher you don't need to pad. IVs can be generated independently by both ends from pre-shared information. From owner-multi6@ops.ietf.org Sat Feb 22 13:35:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14228 for ; Sat, 22 Feb 2003 13:35:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18meVA-000HOT-00 for multi6-data@psg.com; Sat, 22 Feb 2003 10:35:56 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 18meV7-000HOH-00 for multi6@ops.ietf.org; Sat, 22 Feb 2003 10:35:53 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 36AD81C; Sat, 22 Feb 2003 20:44:29 +0200 (EET) Message-ID: <3E57C308.9080900@nomadiclab.com> Date: Sat, 22 Feb 2003 20:35:52 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson Cc: Erik Nordmark , multi6@ops.ietf.org Subject: Re: GSE References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit RJ Atkinson wrote: >> Note that the security issues due to the relaxation can be solved >> by stuff like HIP. > > See smb's comments at www.research.att.com, URL posted by someone else > a few days back. HIP has no special magic in this regard. HIP has no special magic, I agree. It just uses public keys as primary identifiers. That is pretty similar to what SSH does today. HIP has both an opportunistic mode, more or less similar to the way SSH hosts learn the keys of the other hosts, and a DNS(sec) based mode where you learn the public key of the intended recipient form the DNS. That latter comes, of course, with the usual problems with DNS(sec) or any other PKI (like) system. From my point of view, the ability to use public keys as primary identifiers of end-hosts opens up some interesting ways to deal with some security problems. --Pekka From owner-multi6@ops.ietf.org Sat Feb 22 13:41:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14296 for ; Sat, 22 Feb 2003 13:41:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18medf-000HtM-00 for multi6-data@psg.com; Sat, 22 Feb 2003 10:44:43 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 18medc-000HsZ-00 for multi6@ops.ietf.org; Sat, 22 Feb 2003 10:44:40 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 2F6801C; Sat, 22 Feb 2003 20:53:17 +0200 (EET) Message-ID: <3E57C518.6030003@nomadiclab.com> Date: Sat, 22 Feb 2003 20:44:40 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030220 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: Iljitsch van Beijnum , RJ Atkinson , Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: GSE References: <200302221500.h1MF0Oof044344@givry.rennes.enst-bretagne.fr> In-Reply-To: <200302221500.h1MF0Oof044344@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> two-space systems are still raisonable long term solutions, especially >>> HIP (Host Identity Payload Protocol) which doesn't share the security >>> concern on the binding between the locator and the identity. >>> (PS: and its overhead is not a problem for guys like me who'd like >>> to hide everything behind ESP :-). >> >> Is there a good write-up of HIP yet? > > draft-jokela-hip-packets-xx.txt and old I-Ds by Robert Moskowitz. We are in the process of revising the drafts; I'm trying to get two of them out by the next deadline, but I may miss it. Bob's old drafts contain some small mistakes or ambiguities; we are trying to fix (most of) them. In the mean while, our recent paper at NDSS'03 may be easier to approach. http://www.tml.hut.fi/~pnr/publications/NDSS03-Nikander-et-al.pdf There are also slides at http://www.tml.hut.fi/~pnr/presentations/ --Pekka Nikander From owner-multi6@ops.ietf.org Sun Feb 23 11:24:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09417 for ; Sun, 23 Feb 2003 11:24:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18myv9-000889-00 for multi6-data@psg.com; Sun, 23 Feb 2003 08:24:07 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18myv7-00087r-00 for multi6@ops.ietf.org; Sun, 23 Feb 2003 08:24:05 -0800 Received: from extremenetworks.com (unknown [10.0.8.126]) by gnat.inet.org (Postfix) with ESMTP id AE25667109; Sun, 23 Feb 2003 11:37:08 -0500 (EST) Date: Sun, 23 Feb 2003 11:23:56 -0500 Subject: Re: VoIP/ESP+AH Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20030222143351.H61596-100000@sequoia.muada.com> Message-Id: <349298B6-474B-11D7-91A1-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Saturday, Feb 22, 2003, at 09:19 America/Montreal, Iljitsch van Beijnum wrote: > But you can't do routing over IPsec tunnels, so you need another GRE > tunnel. That's untrue. Nothing prevents one from routing over an IPsec tunnel, in fact it is quite commonly deployed. One might choose not to do so, as a matter of policy, but there is nothing in ESP/AH that prevents one from doing so. And I know folks who deployed VoIP/ESP+AH several years ago. It works fine -- and the encryption is not implemented inside the phone. Mind, neither the original posting nor this followup is tremendously on-topic for this list. Ran From owner-multi6@ops.ietf.org Mon Feb 24 00:56:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22092 for ; Mon, 24 Feb 2003 00:56:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nBaW-000N8A-00 for multi6-data@psg.com; Sun, 23 Feb 2003 21:55:40 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18nBaT-000N7y-00 for multi6@ops.ietf.org; Sun, 23 Feb 2003 21:55:37 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1O5upif009370 for ; Mon, 24 Feb 2003 06:56:52 +0100 (CET) Date: Mon, 24 Feb 2003 06:56:50 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: roadmap From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.0 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I finally submitted a roadmap document as discussed in Atlanta. It's called draft-kurtis-multi6-roadmap-00.txt. While waiting for publication it can be found at http://www.kurtis.pp.se/ietf/draft-kurtis-multi6-roadmap.txt. I wrote most of it last night so it is lacking references and most likely spelling..:) - kurtis - From owner-multi6@ops.ietf.org Mon Feb 24 01:50:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22979 for ; Mon, 24 Feb 2003 01:50:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nCTK-000P2l-00 for multi6-data@psg.com; Sun, 23 Feb 2003 22:52:18 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18nCTH-000P2Y-00 for multi6@ops.ietf.org; Sun, 23 Feb 2003 22:52:16 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1O6q5R17224; Mon, 24 Feb 2003 08:52:05 +0200 Date: Mon, 24 Feb 2003 08:52:05 +0200 (EET) From: Pekka Savola To: Kurt Erik Lindqvist cc: multi6@ops.ietf.org Subject: Re: roadmap In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 24 Feb 2003, Kurt Erik Lindqvist wrote: > I finally submitted a roadmap document as discussed in Atlanta. It's > called draft-kurtis-multi6-roadmap-00.txt. While waiting for > publication it can be found at > http://www.kurtis.pp.se/ietf/draft-kurtis-multi6-roadmap.txt. Doesn't exist for v4, and on v6: sampo2 ~> dig any www.kurtis.pp.se [...] ;; ANSWER SECTION: www.kurtis.pp.se. 86357 IN AAAA 2001:670:87:3001::6 www.kurtis.pp.se. 86357 IN A 195.43.225.69 $ traceroute6 2001:670:87:3001::6 traceroute to 2001:670:87:3001::6 (2001:670:87:3001::6) from 2001:670:86:3001::1, 30 hops max, 16 byte packets 1 netcore-gw.ipv6.netcore.fi (2001:670:86:3001::) 13.285 ms 11.78 ms 9.86 ms 2 * * * 3 * * sampo2 ~> traceroute6 2001:670:87:3001::6 traceroute to 2001:670:87:3001::6 (2001:670:87:3001::6) from 2001:708:10:10::1:157, 30 hops max, 16 byte packets 1 ws-6gw.ipv6.csc.fi (2001:708:10:10::1) 0.331 ms 0.236 ms 0.205 ms 2 cscv6-t30-csc-ws.ipv6.funet.fi (2001:708:0:f010::1) 2.234 ms 1.973 ms 2.079 ms 3 6net-p31-cscv6.ipv6.funet.fi (2001:708:0:f000::102:1) 2.067 ms 1.863 ms 1.918 ms 4 v6-a202-cscv6.ipv6.funet.fi (2001:708:0:f000::101:1) 2.253 ms 2.114 ms 2.078 ms 5 r3-AT1-0-4-KQ1.Hel.FI.KPNQwest.net (2001:670:40::1) 4.018 ms 4.8 ms 5 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * $ traceroute6 2001:670:87:3001::6 traceroute6 to 2001:670:87:3001::6 (2001:670:87:3001::6) from 2002:d436:1c91::1, 30 hops max, 12 byte packets 1 2002:3eec:20cb::1 41.465 ms 24.951 ms 24.494 ms 2 * * * 3 * * * 4 * * * .. luckily enough, site multihomin in v6 is not the one of our biggest problems at the moment... :-/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Feb 24 02:00:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23587 for ; Mon, 24 Feb 2003 02:00:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nCcc-000PRN-00 for multi6-data@psg.com; Sun, 23 Feb 2003 23:01:54 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18nCcZ-000PR7-00 for multi6@ops.ietf.org; Sun, 23 Feb 2003 23:01:51 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1O738if009512; Mon, 24 Feb 2003 08:03:08 +0100 (CET) Date: Mon, 24 Feb 2003 08:03:07 +0100 Subject: Re: roadmap Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <07237A3B-47C6-11D7-BBDF-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_AND_TO_SAME_2,IN_REP_TO, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA23587 This should be with a -00 at the end... - kurtis - On måndag, feb 24, 2003, at 06:56 Europe/Stockholm, Kurt Erik Lindqvist wrote: > > > > I finally submitted a roadmap document as discussed in Atlanta. It's > called draft-kurtis-multi6-roadmap-00.txt. While waiting for > publication it can be found at > http://www.kurtis.pp.se/ietf/draft-kurtis-multi6-roadmap.txt. > > I wrote most of it last night so it is lacking references and most > likely spelling..:) > > - kurtis - > > From owner-multi6@ops.ietf.org Mon Feb 24 02:01:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24757 for ; Mon, 24 Feb 2003 02:01:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nCeI-000PUW-00 for multi6-data@psg.com; Sun, 23 Feb 2003 23:03:38 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18nCeF-000PUJ-00 for multi6@ops.ietf.org; Sun, 23 Feb 2003 23:03:36 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1O74qif009515; Mon, 24 Feb 2003 08:04:52 +0100 (CET) Date: Mon, 24 Feb 2003 08:04:52 +0100 Subject: Re: roadmap Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <45469DA5-47C6-11D7-BBDF-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I finally submitted a roadmap document as discussed in Atlanta. It's >> called draft-kurtis-multi6-roadmap-00.txt. While waiting for >> publication it can be found at >> http://www.kurtis.pp.se/ietf/draft-kurtis-multi6-roadmap.txt. > > Doesn't exist for v4, and on v6: It does for v4, but with the -00 at the end... > > .. luckily enough, site multihomin in v6 is not the one of our biggest > problems at the moment... :-/ > :) I need to talk to my upstream...:( - kurtis - From owner-multi6@ops.ietf.org Mon Feb 24 03:23:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04535 for ; Mon, 24 Feb 2003 03:23:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nDv1-0002nr-00 for multi6-data@psg.com; Mon, 24 Feb 2003 00:24:59 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18nDuy-0002nf-00 for multi6@ops.ietf.org; Mon, 24 Feb 2003 00:24:57 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1O8O4n29998; Mon, 24 Feb 2003 09:24:04 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 24 Feb 2003 09:24:04 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: roadmap In-Reply-To: Message-ID: <20030224091049.I61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 24 Feb 2003, Kurt Erik Lindqvist wrote: > I wrote most of it last night so it is lacking references and most > likely spelling..:) And how about this: "The current amount of AS numbers available are limited by the 32-bit field of AS-number in the BGP specification. However, there is a proposal in the IDR working group of the IETF to increase this field to 64-bits. This would increase the amount of ASes available, and therefor the potential amount of routes in the global routing table." I don't think recognizing the 16 bit AS number space as a limit on multihoming is a good thing to do. There are many ways to do it without an AS number. "One way of achieving multihoming that exists already today is to use multiple addresses on the end hosts." This doesn't work so it shouldn't be presented in this way. Also, for future multihoming solutions it is important to know how having multiple addresses is handled; there are many different ways. From owner-multi6@ops.ietf.org Mon Feb 24 03:23:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04549 for ; Mon, 24 Feb 2003 03:23:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nDwC-0002qf-00 for multi6-data@psg.com; Mon, 24 Feb 2003 00:26:12 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18nDw9-0002qS-00 for multi6@ops.ietf.org; Mon, 24 Feb 2003 00:26:09 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1O8RMif009799; Mon, 24 Feb 2003 09:27:22 +0100 (CET) Date: Mon, 24 Feb 2003 09:27:21 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Pekka Savola , "Alan E. Beard" , Tim Chown , , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030222101339.D61596-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> There is no technical reason why a single service provider network >>> can >>> do better than a similar network that consists of several smaller > >> See Abha and Craigs paper on convergence of BGP. Personally I would go >> for a large provider with multiple connections. > > Based on this paper? What I see is rarely as bad as what they describe. > However, I had the chance to experiment a little with revoking a > longer prefix and then see how soon the shorter prefix would "catch" > the > traffic a while back, and this was certainly interesting: the state > goes > back and forth between "working" and "not working" several times over > the course of two minutes. But simple failover is usually pretty fast. My experience is different, and I believe many others share that. But this will always be different for everyone. >> Last fall I was invited to a conference in Sweden to debate >> multihoming >> and the enterprise. Before me was this enterprise IT manager who >> showed >> how much more resilient his network was with two BGP sessions. While >> he >> talked I checked his announcements just to find that one of the >> providers bought transit from the other. You can't buy clue. > > You can buy a good book that explains it all. :-) > > Did you check to see if the second ISPs also had additional upstreams? Yes they did. And they bought transit from the first provider. > >>> But IGPs have the same >>> fundamental problem (although the details may differ). OSPF for >>> instance takes 40 seconds to detect a dead circuit. > >> there was a fix proposed in San Diego (although for IS-IS) but that >> was >> voted down. There was pros and cons. > > Just type: > > ip ospf hello-interval 1 > ip ospf dead-interval 3 > > But do it on ALL your boxes in the subnet or you'll live to regret it. This I thought was more or less standard. I was talking about less than 100ms convergence. - kurtis - From owner-multi6@ops.ietf.org Mon Feb 24 03:26:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04583 for ; Mon, 24 Feb 2003 03:26:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nDyj-0002w8-00 for multi6-data@psg.com; Mon, 24 Feb 2003 00:28:49 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18nDyh-0002vi-00 for multi6@ops.ietf.org; Mon, 24 Feb 2003 00:28:47 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1O8U5if009811; Mon, 24 Feb 2003 09:30:05 +0100 (CET) Date: Mon, 24 Feb 2003 09:30:04 +0100 Subject: Re: roadmap Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030224091049.I61596-100000@sequoia.muada.com> Message-Id: <2C7E25BD-47D2-11D7-BBDF-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I wrote most of it last night so it is lacking references and most >> likely spelling..:) > > And how about this: > > "The current amount of AS numbers available are limited by the 32-bit > field of AS-number in the BGP specification. However, there is a > proposal in the IDR working group of the IETF to increase this field > to 64-bits. This would increase the amount of ASes available, and > therefor the potential amount of routes in the global routing > table." > > I don't think recognizing the 16 bit AS number space as a limit on > multihoming is a good thing to do. There are many ways to do it without > an AS number. There is. But it will still limited the growth somewhat. > "One way of achieving multihoming that exists already today is to use > multiple addresses on the end hosts." > > This doesn't work so it shouldn't be presented in this way. Also, for > future multihoming solutions it is important to know how having > multiple > addresses is handled; there are many different ways. Send text! :) - kurtis - From owner-multi6@ops.ietf.org Mon Feb 24 05:59:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07586 for ; Mon, 24 Feb 2003 05:59:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nGKz-0007JB-00 for multi6-data@psg.com; Mon, 24 Feb 2003 02:59:57 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18nGKw-0007Iz-00 for multi6@ops.ietf.org; Mon, 24 Feb 2003 02:59:55 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1OAx6P30225; Mon, 24 Feb 2003 11:59:06 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 24 Feb 2003 11:59:06 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: roadmap In-Reply-To: <2C7E25BD-47D2-11D7-BBDF-000393AB1404@kurtis.pp.se> Message-ID: <20030224100407.I61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 24 Feb 2003, Kurt Erik Lindqvist wrote: > > "One way of achieving multihoming that exists already today is to use > > multiple addresses on the end hosts." > > This doesn't work so it shouldn't be presented in this way. Also, for > > future multihoming solutions it is important to know how having > > multiple addresses is handled; there are many different ways. > Send text! :) Don't think I won't! I have to do some programming work so I was looking for a way to procrastinate anyway... Here is some text. The trouble is that it doesn't fit into your classification, and I see no way to make this happen. A way to make multihoming very scalable without taxing the routing system is to use address space from each ISP the multihomed network is connected to, rather than (semi-)independent address space. This allows for full scale provider-based aggregation and full scale multihoming benefits at the same time. There are basically four ways to accomplish this: 1. Multi-address aware applications. These exist today. The DNS and email both take several destination addresses for many operations and cycle through them one by one until a working address is found. This is traditionally used to fall back from one host to another, but this mechanism is also usable for falling back from one address to another address tied to the same host. However, this mechanism doesn't provide any way to switch from one address to another during a session. This makes it unusable for applications with long-lived sessions. But for applications that typically use short transactions which can simply be repeated after failure, this mechanism can work very well. One application that uses short transactions most of the time is the world wide web. 2. Multi-address aware transport protocols. At this time, there is SCTP. There are several proof-of-concept modifications to TCP to accomplish the same thing. This could probably be more interoperable than switching to a new transport protocol. 3. Failure repair with tunnels or extension headers. It has been observed that Mobile IP offers functionality that can be used here, although there are also elements missing that would be required for a usable multihoming solution based on MIP. 4. Two-space systems, where there are addresses (or names that don't look like addresses) used for the identifaction of the endpoints taking part in the communication and different addresses used to route packets. Solutions that separate the identifier and locator functions marry portable address space to full aggregation within the routing system. There must always be a locator as the destination address (for forwarding) and a locator as the source address (so ICMP messages can be sent back) in each packet. The identifiers may be carried explicitly or they may be implied and be found by looking up the locators and possibly session-identifying information in a mapping table. However, as explicit identifiers aren't protected by even the low level of security provided by return routability, it is impossible to use them they way they are found in a packet. Rather than trying to authenticate the identifier in the packet and incur even more per-packet overhead, it seems logical to use implicit identifiers. Mechanisms 1 and 2 (mostly) can simply use the DNS to find additional addresses. Mechanism 4 and maybe 3 as well need a more extensive mapping or negotiation mechanism to discover all the information needed to operate. Another difference between 1 and 2 on the one hand and 3 and 4 on the other hand is that it may be possible to implement 3 and/or 4 on a proxy multihoming processing box. This could have important deployment advantages. Iljitsch From owner-multi6@ops.ietf.org Mon Feb 24 11:03:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17606 for ; Mon, 24 Feb 2003 11:03:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nL52-000LFb-00 for multi6-data@psg.com; Mon, 24 Feb 2003 08:03:48 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18nL4x-000LF5-00 for multi6@ops.ietf.org; Mon, 24 Feb 2003 08:03:44 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28467; Mon, 24 Feb 2003 09:03:42 -0700 (MST) Received: from localhost (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1OG3fP25722; Mon, 24 Feb 2003 17:03:41 +0100 (MET) Date: Mon, 24 Feb 2003 16:59:53 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Draft: PI addressing derived from AS numbers To: RJ Atkinson Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <4719ECDA-45C7-11D7-A186-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Unclear to me how one avoids cryptographic on each source-routed packet. > On the other hand, 16+16 or 8+8 doesn't necessarily involve > source-routing. Sorry, I was reusing Noel's "source routing bugs" term. The issue is with the decoupling of identifiers and locators opening up a type of spoofing attack which isn't present when identifier=locator. The nature of this is similar to source routing attacks, which is why I think Noel was using that expression. > > A third question is whether one can make this work with both hosts > > doing > > 16+16 (which might provide a stronger security binding) and site border > > routers doing it (which would be easier to deploy using existing IPv6 > > implementations in the hosts). > > I don't follow that sentence. Assume you are going to do 16+16 with reasonable security. One choice would be to have 16+16 addresses/headers end-to-end. Another choice would be to have boxes in the middle (such as border routers) add and remove the outer addresses/headers. My question is whether this can be done. Erik From owner-multi6@ops.ietf.org Mon Feb 24 11:35:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18359 for ; Mon, 24 Feb 2003 11:35:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nLZb-000Mzw-00 for multi6-data@psg.com; Mon, 24 Feb 2003 08:35:23 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18nLZJ-000Mwj-00 for multi6@ops.ietf.org; Mon, 24 Feb 2003 08:35:07 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18nLZF-000Ezq-00 for multi6@ops.ietf.org; Tue, 25 Feb 2003 01:35:01 +0900 Message-ID: <022e01c2dc1d$76f49d20$0301a8c0@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Tom Petch" To: "Iljitsch van Beijnum" , "Kurt Erik Lindqvist" Cc: "Pekka Savola" , "Alan E. Beard" , , Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Date: Mon, 24 Feb 2003 15:55:16 -0000 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] To talk about resilience is a snare for the unwary until you specify what you are providing resilience against. The large enterprises I work with have a simple policy, set by the non-technicians who run the organisation; no single point of failure. That doesn't mean no single point of failure in the ISP - that is up to the management of the ISP - but no single failure in the parts the enterprise management is accountable for, such as the links to the ISP. So if one ISP piggy backs on another, that is the choice of the management of the ISP and so not their responsibility. In the non-IP world, that invariably means taking bandwidth, basic carrier services, to two different telcos, coming out of different parts of the site, to different exchanges, perhaps with different media (copper and fibre, fibre and wireless), not having a power supply (eg local electricity supplier) in common. If in the centre of the world these feeds share a fibre, that is the telco's concern, not the enterprise's. The enterprise should ensure that the telcos do not share a local exchange or fibre to the site but no more than that. This is a system that has evolved over decades with much pain but it does work well because the bulk of failures - some surveys put it as high as 95% - occur within the 'last mile' and that is what this gives resilience against. IP? same difference. It is the links to the ISPs' points of presence (obviously not co-located) that are the primary concern of the enterprise management. If ISPs share a resource, which in a sense every ISP does because there is a single world-wide BGP RIB, then that is the responsibility of the ISP. So multi-homing is a must. Tom Petch, Network Consultant nwnetworks@dial.pipex.com -----Original Message----- From: Kurt Erik Lindqvist To: Iljitsch van Beijnum Cc: Pekka Savola ; Alan E. Beard ; Tim Chown ; ipng@sunroof.eng.sun.com ; multi6@ops.ietf.org Date: 24 February 2003 08:29 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] >>>> There is no technical reason why a single service provider network >>>> can >>>> do better than a similar network that consists of several smaller >> >>> See Abha and Craigs paper on convergence of BGP. Personally I would go >>> for a large provider with multiple connections. >> >> Based on this paper? What I see is rarely as bad as what they describe. >> However, I had the chance to experiment a little with revoking a >> longer prefix and then see how soon the shorter prefix would "catch" >> the >> traffic a while back, and this was certainly interesting: the state >> goes >> back and forth between "working" and "not working" several times over >> the course of two minutes. But simple failover is usually pretty fast. > >My experience is different, and I believe many others share that. But >this will always be different for everyone. > >>> Last fall I was invited to a conference in Sweden to debate >>> multihoming >>> and the enterprise. Before me was this enterprise IT manager who >>> showed >>> how much more resilient his network was with two BGP sessions. While >>> he >>> talked I checked his announcements just to find that one of the >>> providers bought transit from the other. You can't buy clue. >> >> You can buy a good book that explains it all. :-) >> >> Did you check to see if the second ISPs also had additional upstreams? > >Yes they did. And they bought transit from the first provider. > >> >>>> But IGPs have the same >>>> fundamental problem (although the details may differ). OSPF for >>>> instance takes 40 seconds to detect a dead circuit. >> >>> there was a fix proposed in San Diego (although for IS-IS) but that >>> was >>> voted down. There was pros and cons. >> >> Just type: >> >> ip ospf hello-interval 1 >> ip ospf dead-interval 3 >> >> But do it on ALL your boxes in the subnet or you'll live to regret it. > >This I thought was more or less standard. I was talking about less than >100ms convergence. > >- kurtis - > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- From owner-multi6@ops.ietf.org Mon Feb 24 11:35:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18375 for ; Mon, 24 Feb 2003 11:35:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nLZO-000Mzn-00 for multi6-data@psg.com; Mon, 24 Feb 2003 08:35:10 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 18nLZF-000Mwi-00 for multi6@ops.ietf.org; Mon, 24 Feb 2003 08:35:02 -0800 Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id h1OGYt6m027767; Mon, 24 Feb 2003 17:34:55 +0100 Received: (from shane@localhost) by x17.ripe.net (8.12.4/8.12.6) id h1OGYtcF024654; Mon, 24 Feb 2003 17:34:55 +0100 Date: Mon, 24 Feb 2003 17:34:55 +0100 From: Shane Kerr To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: roadmap Message-ID: <20030224163454.GB24494@x17.ripe.net> References: <20030224091049.I61596-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030224091049.I61596-100000@sequoia.muada.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk First, let me say that this draft is the best thing ever written. I'm trying to decide whether to throw out the Bible or Code Complete to make room for it on my shelf. ;) On 2003-02-24 09:24:04 +0100, Iljitsch van Beijnum wrote: > > "One way of achieving multihoming that exists already today is to > use multiple addresses on the end hosts." > > This doesn't work so it shouldn't be presented in this way. It doesn't work, except for where it does, like DNS and SMTP. > Also, for future multihoming solutions it is important to know how > having multiple addresses is handled; there are many different ways. I thought the draft was appropriately free of details. How do you mean exactly? -- Shane Kerr RIPE NCC From owner-multi6@ops.ietf.org Mon Feb 24 13:01:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20804 for ; Mon, 24 Feb 2003 13:01:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nMvT-0001ZR-00 for multi6-data@psg.com; Mon, 24 Feb 2003 10:02:03 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18nMvN-0001Z6-00 for multi6@ops.ietf.org; Mon, 24 Feb 2003 10:01:57 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1OI17330890; Mon, 24 Feb 2003 19:01:08 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 24 Feb 2003 19:01:07 +0100 (CET) From: Iljitsch van Beijnum To: Erik Nordmark cc: Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: Message-ID: <20030224183938.Q61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 24 Feb 2003, Erik Nordmark wrote: > One choice would be to have 16+16 addresses/headers end-to-end. > Another choice would be to have boxes in the middle (such as border routers) > add and remove the outer addresses/headers. > My question is whether this can be done. Why would we want to have two sets of addresses in any part of the communication path? The identifiers can simply be replaced by locators (and vice versa) between the TCP and IP layers. This could also be done by external boxes if those aren't bothered by the state that must be kept. A solution where the identifier is present in each packet may be simpler to implement, but only if there is no additional complexity for authenticating the identifier, which seems unlikely. From owner-multi6@ops.ietf.org Mon Feb 24 13:02:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20859 for ; Mon, 24 Feb 2003 13:02:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nMxd-0001k0-00 for multi6-data@psg.com; Mon, 24 Feb 2003 10:04:17 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18nMxY-0001jj-00 for multi6@ops.ietf.org; Mon, 24 Feb 2003 10:04:12 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1OI3OU30894; Mon, 24 Feb 2003 19:03:24 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 24 Feb 2003 19:03:24 +0100 (CET) From: Iljitsch van Beijnum To: Shane Kerr cc: Subject: Re: roadmap In-Reply-To: <20030224163454.GB24494@x17.ripe.net> Message-ID: <20030224190147.I61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 24 Feb 2003, Shane Kerr wrote: > > "One way of achieving multihoming that exists already today is to > > use multiple addresses on the end hosts." > > This doesn't work so it shouldn't be presented in this way. > It doesn't work, except for where it does, like DNS and SMTP. It only works to a usable degree when you do source-address dependent routing. From owner-multi6@ops.ietf.org Mon Feb 24 23:09:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05599 for ; Mon, 24 Feb 2003 23:08:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nWPq-000EAT-00 for multi6-data@psg.com; Mon, 24 Feb 2003 20:10:02 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=SERVER2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 18nWPL-000E9i-00 for multi6@ops.ietf.org; Mon, 24 Feb 2003 20:09:31 -0800 Content-class: urn:content-classes:message Subject: RE: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Feb 2003 20:09:30 -0800 Message-ID: <963621801C6D3E4A9CF454A1972AE8F54C39@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Thread-Index: AcLb3sTVmlZvIoOMQGqICOs/G7sh6AApHwzA From: "Michel Py" To: "Kurt Erik Lindqvist" , "Iljitsch van Beijnum" Cc: "Pekka Savola" , "Alan E. Beard" , "Tim Chown" , , X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA05599 > Kurt Erik Lindqvist wrote: > This I thought was more or less standard. I was talking about > less than 100ms convergence. Dude, this requires a keepalive or hello at 10ms intervals and a 25~30 ms rtt. You might need to talk to a guy named Albert Einstein; he wrote interesting RFCs about the speed of light that, as far as I know, have not been debunked yet. Michel. From owner-multi6@ops.ietf.org Tue Feb 25 01:19:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07817 for ; Tue, 25 Feb 2003 01:19:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nYT5-000Nlp-00 for multi6-data@psg.com; Mon, 24 Feb 2003 22:21:31 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18nYT2-000Nlc-00 for multi6@ops.ietf.org; Mon, 24 Feb 2003 22:21:29 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1P6Kg125443; Tue, 25 Feb 2003 08:20:42 +0200 Date: Tue, 25 Feb 2003 08:20:42 +0200 (EET) From: Pekka Savola To: Michel Py cc: Kurt Erik Lindqvist , Iljitsch van Beijnum , "Alan E. Beard" , Tim Chown , , Subject: RE: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54C39@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 24 Feb 2003, Michel Py wrote: > > Kurt Erik Lindqvist wrote: > > This I thought was more or less standard. I was talking about > > less than 100ms convergence. > > Dude, this requires a keepalive or hello at 10ms intervals and a 25~30 > ms rtt. You might need to talk to a guy named Albert Einstein; he wrote > interesting RFCs about the speed of light that, as far as I know, have > not been debunked yet. When multi-connecting, such RTT's seem reasonable. If you need to converge on the global routing table, that's a non-starter of course -- but that's one of the main strengths of multi-connecting. No changes to those outside of the ISP. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Feb 25 06:55:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25473 for ; Tue, 25 Feb 2003 06:55:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ndiy-000C0j-00 for multi6-data@psg.com; Tue, 25 Feb 2003 03:58:16 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18ndiv-000C0W-00 for multi6@ops.ietf.org; Tue, 25 Feb 2003 03:58:14 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id AD740431B6 for ; Tue, 25 Feb 2003 12:58:10 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 4D5C399E76 for ; Tue, 25 Feb 2003 12:58:10 +0100 (CET) Subject: Application of MIPv6 to multi-homing draft From: marcelo bagnulo To: multi6@ops.ietf.org Content-Type: text/plain Organization: uc3m Message-Id: <1046174289.732.7.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Feb 2003 12:58:09 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=NOSPAM_INC,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would like to submit the following draft to the wg: draft-bagnulo-multi6-mnm-00 Title: Application of the MIPv6 protocol to the multi-homing problem Abstract: This note attempts to describe how to apply the MIPv6 protocol to provide fault tolerance to transport layer connections established between a multi-homed host and other hosts in the Internet. Specifically, this note addresses the usage of MIPv6 signaling messages to convey information about alternative address to be used when an outage occurs. Additionally, possible mechanisms to detect failures affecting the currently used path are explored. Unitl it is available at the ID site, you can find a copy: http://www.it.uc3m.es/marcelo/draft-bagnulo-multi6-mnm-00.txt Feedback is appreciated Thanks, -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Tue Feb 25 08:08:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29799 for ; Tue, 25 Feb 2003 08:08:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18neqZ-000EcH-00 for multi6-data@psg.com; Tue, 25 Feb 2003 05:10:11 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 18neqW-000Ec5-00 for multi6@ops.ietf.org; Tue, 25 Feb 2003 05:10:08 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29757; Tue, 25 Feb 2003 05:10:07 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1PDA3P09693; Tue, 25 Feb 2003 14:10:03 +0100 (MET) Date: Tue, 25 Feb 2003 14:06:14 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Draft: PI addressing derived from AS numbers To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <20030224183938.Q61596-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Why would we want to have two sets of addresses in any part of the > communication path? The identifiers can simply be replaced by locators > (and vice versa) between the TCP and IP layers. This could also be done > by external boxes if those aren't bothered by the state that must be > kept. I think that conceptually they are all present in each packet. Some form of end-to-end "header compression" can presumably remove the need for the identifiers in every packet, but presumbly this is a function of the state at the endpoints. It would presumably be easier to maintain the compression state in the transport protocols (due to fate sharing etc) than in a separate entity, whether it is below transport in the endpoints or in a separate box. > A solution where the identifier is present in each packet may be simpler > to implement, but only if there is no additional complexity for > authenticating the identifier, which seems unlikely. Good point. Perhaps providing a reasonably strong binding between the identifiers and locators in some initial packet(s), and having subsequent packets only contain the locators (at least until a locator changes) might be the right model. Erik From owner-multi6@ops.ietf.org Tue Feb 25 08:40:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00872 for ; Tue, 25 Feb 2003 08:40:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nfMo-000FvS-00 for multi6-data@psg.com; Tue, 25 Feb 2003 05:43:30 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18nfMm-000FvF-00 for multi6@ops.ietf.org; Tue, 25 Feb 2003 05:43:28 -0800 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 h1PDhPkw018099; Tue, 25 Feb 2003 08:43:26 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1PDhPHO018098; Tue, 25 Feb 2003 08:43:25 -0500 Date: Tue, 25 Feb 2003 08:43:25 -0500 From: "J. Noel Chiappa" Message-Id: <200302251343.h1PDhPHO018098@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=1.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Erik Nordmark > Some form of end-to-end "header compression" can presumably remove the > need for the identifiers in every packet One way to "include" the identifier in each packet implicitly (i.e. make sure the packets get to the right endpoint) is to include the endpoint identifier in the transport "pseudo-header", so that you get a checksum failure if the packet gets to the wrong endpoint. > Perhaps providing a reasonably strong binding between the identifiers > and locators in some initial packet(s), and having subsequent packets > only contain the locators (at least until a locator changes) might be > the right model. I've played with this model some (I even wrote a draft I-D, for the NSRG, showing how to add this capability to IP/TCP-4; it used the checksum trick above). The only problem I recall finding was if you're trying to support mobile computations (not a big goal of anyone at the moment, I understand :-). If you pick up a process with an open connection on TCP port X and move it to a machine which already has an open connection on X, you're kind of hosed. I hypothesized an small, short, endpoint identifier with scope local to the destination (I called it an ESEL, for "endpoint selector") to disambiguate when you have multiple endpoints at a single locator. Noel From owner-multi6@ops.ietf.org Tue Feb 25 08:40:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00875 for ; Tue, 25 Feb 2003 08:40:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nfNS-000Fw9-00 for multi6-data@psg.com; Tue, 25 Feb 2003 05:44:10 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18nfNQ-000Fvx-00 for multi6@ops.ietf.org; Tue, 25 Feb 2003 05:44:08 -0800 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 9818267106; Tue, 25 Feb 2003 08:57:39 -0500 (EST) Date: Tue, 25 Feb 2003 08:44:06 -0500 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Erik Nordmark From: RJ Atkinson In-Reply-To: Message-Id: <35688674-48C7-11D7-81FE-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, Feb 25, 2003, at 08:06 America/Montreal, Erik Nordmark wrote: > It would presumably be easier to maintain the compression state in > the transport protocols (due to fate sharing etc) than in a separate > entity, whether it is below transport in the endpoints or in a > separate box. s/transport protocols/end systems/ Its not at all clear to me that such compression state belongs in TCP/UDP/SCTP rather than being inside IP. In practice, any IPv6 host has some amount of IPv6 protocol state. That is probably the right place for this information. > Perhaps providing a reasonably strong binding between the identifiers > and locators in some initial packet(s), and having subsequent packets > only > contain the locators (at least until a locator changes) might be the > right model. That might well be reasonable. One would want to see the details before drawing a firm conclusion, of course. In my book, "reasonably strong binding" means some form of cryptographic authentication. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Tue Feb 25 08:48:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01027 for ; Tue, 25 Feb 2003 08:48:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nfV7-000GIo-00 for multi6-data@psg.com; Tue, 25 Feb 2003 05:52:05 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18nfV3-000GIb-00 for multi6@ops.ietf.org; Tue, 25 Feb 2003 05:52:01 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1PDrJif002128; Tue, 25 Feb 2003 14:53:19 +0100 (CET) Date: Tue, 25 Feb 2003 14:53:19 +0100 Subject: Re: roadmap Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030224100407.I61596-100000@sequoia.muada.com> Message-Id: <7EF6BB0A-48C8-11D7-BBDF-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> "One way of achieving multihoming that exists already today is to >>> use >>> multiple addresses on the end hosts." > >>> This doesn't work so it shouldn't be presented in this way. Also, for >>> future multihoming solutions it is important to know how having >>> multiple addresses is handled; there are many different ways. > >> Send text! :) > > Don't think I won't! I have to do some programming work so I was > looking good! > Here is some text. The trouble is that it doesn't fit into your > classification, and I see no way to make this happen. > Why don't you think this would fit as text under the Addressing solutions paragraph? Best regards, - kurtis From owner-multi6@ops.ietf.org Tue Feb 25 09:23:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01828 for ; Tue, 25 Feb 2003 09:23:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ng2S-000Hmu-00 for multi6-data@psg.com; Tue, 25 Feb 2003 06:26:32 -0800 Received: from halt-in.cisco.com ([171.70.144.185]) by psg.com with esmtp (Exim 3.36 #1) id 18ng2O-000Hmi-00 for multi6@ops.ietf.org; Tue, 25 Feb 2003 06:26:28 -0800 Received: from cisco.com (171.70.144.164) by halt-in.cisco.com with ESMTP; 25 Feb 2003 06:26:27 -0800 Received: from cisco.com (sjc-vpn3-244.cisco.com [10.21.64.244]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA03854; Tue, 25 Feb 2003 06:26:26 -0800 (PST) Message-ID: <3E5B7D11.3090106@cisco.com> Date: Tue, 25 Feb 2003 06:26:25 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson CC: Erik Nordmark , multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers References: <35688674-48C7-11D7-81FE-00039357A82A@extremenetworks.com> In-Reply-To: <35688674-48C7-11D7-81FE-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit So what I'm getting from this discussion is that 8+8 is too late but 16+16 is too large??? I would agree that 16+16 is too large. How about 4+16? Eliot From owner-multi6@ops.ietf.org Tue Feb 25 10:37:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03665 for ; Tue, 25 Feb 2003 10:37:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nhB9-000KmA-00 for multi6-data@psg.com; Tue, 25 Feb 2003 07:39:35 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18nhB5-000Klw-00 for multi6@ops.ietf.org; Tue, 25 Feb 2003 07:39:31 -0800 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 h1PFdTkw018751; Tue, 25 Feb 2003 10:39:30 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1PFdT0Y018750; Tue, 25 Feb 2003 10:39:29 -0500 Date: Tue, 25 Feb 2003 10:39:29 -0500 From: "J. Noel Chiappa" Message-Id: <200302251539.h1PFdT0Y018750@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Eliot Lear > So what I'm getting from this discussion is that 8+8 is too late but > 16+16 is too large??? I would suggest that 16+16 be done not with a complete second IPv6 header, but rather one of the routing headers (I forget the formal name). That would make it somewhat smaller. Anyway, why does header size matter that much? Those on slow links (< 56K) will be using header compression anyway, so it doesn't really matter for them since the average packet will have all that stuff compressed out anyway, and for those on fast links, who cares about a few extra bytes? Check out the average web page to see how many stupid little icons it has on it, how many JavaScript files it loads, how many pop-up windows (with their own images and Javascript) it loads, etc, etc. (Every Web page designer ought to be sentenced by law to using a 28.8 modem for all their online access... but I digress.) > I would agree that 16+16 is too large. How about 4+16? You mean, wrap an IPv6 packet in an IPv4 packet? First, that would produce a packet of the exact same length as my suggestion above (an IPv4 header is 20 bytes, after all). It would have the advantage that it could be carried over existing substrate. It would have the disadvantage that you'd be limited to a 32-bit locator, something that's already causing us grief. (And don't even *think* about moving some of the "local" topology information into the IPv6 addresses, leaving only the "global" stuff in the IPv4 header. Long architectural rant about why you don't spread functionality across two namespaces left out, as an exercise to the reader.) Noel From owner-multi6@ops.ietf.org Tue Feb 25 11:17:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05039 for ; Tue, 25 Feb 2003 11:17:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nhoZ-000MjF-00 for multi6-data@psg.com; Tue, 25 Feb 2003 08:20:19 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18nhoS-000Mir-00 for multi6@ops.ietf.org; Tue, 25 Feb 2003 08:20:12 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 7038A43128; Tue, 25 Feb 2003 17:20:11 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id C34F899E77; Tue, 25 Feb 2003 17:20:10 +0100 (CET) Subject: Re: Draft: PI addressing derived from AS numbers From: marcelo bagnulo To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: <20030224183938.Q61596-100000@sequoia.muada.com> References: <20030224183938.Q61596-100000@sequoia.muada.com> Content-Type: text/plain Organization: uc3m Message-Id: <1046190005.732.62.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Feb 2003 17:20:06 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, Erik, On Mon, 2003-02-24 at 19:01, Iljitsch van Beijnum wrote: > On Mon, 24 Feb 2003, Erik Nordmark wrote: > > > One choice would be to have 16+16 addresses/headers end-to-end. > > Another choice would be to have boxes in the middle (such as border routers) > > add and remove the outer addresses/headers. > > My question is whether this can be done. > > Why would we want to have two sets of addresses in any part of the > communication path? I do not want to overload the requirements but i think that there are some other relevant problems that could be addressed using the separation of identifiers and locators. In a scheme that identifiers and locators are separated, i would guess that identifiers belong to the identified part (i.e. end users) and locators belong to the ISP. So, PA is used to preserve routing system scalability. In order to preserve aggregation, renumbering is required when changing ISP, this is why end-sites like PI. Now, the separation of identifier and locator can help with this, simplifying re-homing events and renumbering. I guess that this separation can help in such events. Currently internal systems such as access lists, firewall use IP address for filtering, so that if the site renumbers all these list have to be updated. If id-locator separation is implemented, these systems can use identifiers, that belong to the end site, symplifying re-homing events. In order to do this, identifiers need to be carried in packets. Clearly, locators are also needed in packets for routing. Does any of this makes any sense? (If no is answered please explain) Regards, marcelo > The identifiers can simply be replaced by locators > (and vice versa) between the TCP and IP layers. This could also be done > by external boxes if those aren't bothered by the state that must be > kept. > > A solution where the identifier is present in each packet may be simpler > to implement, but only if there is no additional complexity for > authenticating the identifier, which seems unlikely. -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Tue Feb 25 13:44:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10184 for ; Tue, 25 Feb 2003 13:44:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nk6b-000489-00 for multi6-data@psg.com; Tue, 25 Feb 2003 10:47:05 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18nk6J-00047m-00 for multi6@ops.ietf.org; Tue, 25 Feb 2003 10:46:47 -0800 Received: from muada.com (torreya.muada.com [213.156.3.174]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1PIjtv33064 for ; Tue, 25 Feb 2003 19:45:55 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 25 Feb 2003 19:45:26 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Headers From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <4DFA4687-48F1-11D7-BF31-000393C52D28@muada.com> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.5 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [doing some aggregation] RJ Atkinson: > > Perhaps providing a reasonably strong binding between the identifiers > > and locators in some initial packet(s), and having subsequent packets > > only contain the locators (at least until a locator changes) might > be the > > right model. > That might well be reasonable. One would want to see the details > before > drawing a firm conclusion, of course. > In my book, "reasonably strong binding" means some form of > cryptographic > authentication. I'm imagining a situation (see my "transportzilla" posts from a while back for more details) where the application uses an identifier which doesn't have to be an address, and TCP and UDP use this identifier in the pseudo-header. IP only uses the locators. So there must be a mapping between the locators and the identifiers between IP and TCP. As long as each combination of { any source locator, source port, any destination locator, destination port } is unique on both ends, there shouldn't be any trouble finding the right source and destination identifiers on the destination host. Of course there is the minor detail of setting up all this state... This should bind the identifiers to the locators strong enough without any per-packet overhead as long as the setup phase is well-secured. Of course there are still the traditional TCP weaknesses but the billions of packets flowing around the net every second tell us most people can live with this most of the time and there's always TLS and IPsec. J. Noel Chiappa: > One way to "include" the identifier in each packet implicitly (i.e. > make > sure the packets get to the right endpoint) is to include the endpoint > identifier in the transport "pseudo-header", so that you get a checksum > failure if the packet gets to the wrong endpoint. Yes. But: packets shouldn't end up at the wrong session anyway unless something is seriously broken and this provides no protection at all against someone who can intercept the communication as the TCP checksum is hardly a one-way hash. > I hypothesized an small, short, endpoint identifier with scope local > to the > destination (I called it an ESEL, for "endpoint selector") to > disambiguate > when you have multiple endpoints at a single locator. Wouldn't this be similar to a port number (for outgoing connections) or an IPsec SPI? > I would suggest that 16+16 be done not with a complete second IPv6 > header, > but rather one of the routing headers (I forget the formal name). That > would > make it somewhat smaller. Which identifier do you need? The source or destination? The trouble is the 8 byte alignment in IPv6: this is enormously inconvenient when you need to add something that is also 8 byte aligned because you then need 8 bytes just to say there is an extra header. (Lets remember this for IPv7: no 2^x sized addresses!) This means a second IPv6 header is the shortest way to add both a source and a destination identifier. So then we're tunneling. > Anyway, why does header size matter that much? Those on slow links (< > 56K) > will be using header compression anyway, so it doesn't really matter > for them > since the average packet will have all that stuff compressed out > anyway, and > for those on fast links, who cares about a few extra bytes? Short answer: someone should! If we're going to do 2 IPv6 headers the additional 60 bytes per packet aren't going to persuade anyone to switch. The average IP packet size is around 500 bytes, so that's 10% of your bandwidth you're throwing away by switching. Header compression is great, but it doesn't solve everything. For instance, my iBook has RFC1323 extensions enabled by default. This makes the TCP header 12 bytes longer (yeay!) but also unpredictable. Also, all these headers at every layer add up. 11 Mbps wireless? Don't make me laugh: you're lucky if more than half is usable payload. If we can accomplish the same functionality without the extra headers, we should do it without. > Check out the average web page to see how many stupid little icons it > has on > it, how many JavaScript files it loads, how many pop-up windows (with > their > own images and Javascript) it loads, etc, etc. (Every Web page > designer ought > to be sentenced by law to using a 28.8 modem for all their online > access... > but I digress.) So we should do basically the same thing, but then for the entire internet where everyone is forced to eat the extra overhead the next 15 years or so? At least I have a choice when visiting websites, there are only a few flavors of IP around... marcelo bagnulo: > In order to preserve aggregation, renumbering is required when changing > ISP, this is why end-sites like PI. > Now, the separation of identifier and locator can help with this, > simplifying re-homing events and renumbering. I guess that this > separation can help in such events. Currently internal systems such as > access lists, firewall use IP address for filtering, so that if the > site > renumbers all these list have to be updated. If id-locator separation > is > implemented, these systems can use identifiers, that belong to the end > site, symplifying re-homing events. In order to do this, identifiers > need to be carried in packets. You can't take what's in a packet at face value: this information can be spoofed. I would rather have the firewalls take part in the session establishment procedure. Then you don't need the explicit identifiers as per the above. Iljitsch From owner-multi6@ops.ietf.org Wed Feb 26 03:22:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28026 for ; Wed, 26 Feb 2003 03:22:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nwrl-0000EH-00 for multi6-data@psg.com; Wed, 26 Feb 2003 00:24:37 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18nwri-0000E5-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 00:24:35 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1Q8Pjif008058; Wed, 26 Feb 2003 09:25:46 +0100 (CET) Date: Wed, 26 Feb 2003 09:25:44 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michel Py , Iljitsch van Beijnum , "Alan E. Beard" , Tim Chown , , To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Kurt Erik Lindqvist wrote: >>> This I thought was more or less standard. I was talking about >>> less than 100ms convergence. >> >> Dude, this requires a keepalive or hello at 10ms intervals and a 25~30 >> ms rtt. You might need to talk to a guy named Albert Einstein; he >> wrote >> interesting RFCs about the speed of light that, as far as I know, have >> not been debunked yet. > > When multi-connecting, such RTT's seem reasonable. > > If you need to converge on the global routing table, that's a > non-starter > of course -- but that's one of the main strengths of multi-connecting. > No > changes to those outside of the ISP. > The original comment I made was on IGP though... - kurtis - From owner-multi6@ops.ietf.org Wed Feb 26 03:23:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28040 for ; Wed, 26 Feb 2003 03:23:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nwrV-0000DG-00 for multi6-data@psg.com; Wed, 26 Feb 2003 00:24:21 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18nwrT-0000D1-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 00:24:19 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1Q8P3if007584; Wed, 26 Feb 2003 09:25:06 +0100 (CET) Date: Wed, 26 Feb 2003 09:25:02 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Iljitsch van Beijnum" , "Pekka Savola" , "Alan E. Beard" , "Tim Chown" , , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54C39@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Kurt Erik Lindqvist wrote: >> This I thought was more or less standard. I was talking about >> less than 100ms convergence. > > Dude, this requires a keepalive or hello at 10ms intervals and a 25~30 > ms rtt. You might need to talk to a guy named Albert Einstein; he wrote > interesting RFCs about the speed of light that, as far as I know, have > not been debunked yet. > Actually not. Go look at the presentations from the San Diego IETF. I think it was in the ISIS-WG. It was based on 'heartbeats' being sent and you know that if you have missed X number of packets in Y time the link is down. Don't remember all the details. I think it also included moving to partial SPF calculations to get this down even further. - kurtis - From owner-multi6@ops.ietf.org Wed Feb 26 05:15:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29857 for ; Wed, 26 Feb 2003 05:15:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nyeL-0003kc-00 for multi6-data@psg.com; Wed, 26 Feb 2003 02:18:53 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18nyeH-0003kG-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 02:18:49 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 7A2554314A; Wed, 26 Feb 2003 11:18:48 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 599B099E67; Wed, 26 Feb 2003 11:18:48 +0100 (CET) Subject: Re: Headers From: marcelo bagnulo To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org In-Reply-To: <4DFA4687-48F1-11D7-BF31-000393C52D28@muada.com> References: <4DFA4687-48F1-11D7-BF31-000393C52D28@muada.com> Content-Type: text/plain Organization: uc3m Message-Id: <1046254727.717.4.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Feb 2003 11:18:48 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > marcelo bagnulo: > > In order to preserve aggregation, renumbering is required when changing > > ISP, this is why end-sites like PI. > > > Now, the separation of identifier and locator can help with this, > > simplifying re-homing events and renumbering. I guess that this > > separation can help in such events. Currently internal systems such as > > access lists, firewall use IP address for filtering, so that if the > > site > > renumbers all these list have to be updated. If id-locator separation > > is > > implemented, these systems can use identifiers, that belong to the end > > site, symplifying re-homing events. In order to do this, identifiers > > need to be carried in packets. > > You can't take what's in a packet at face value: this information can > be spoofed. Perhaps you could include enough info so you can check this. > > I would rather have the firewalls take part in the session > establishment procedure. Wouldn't this preclude fault tolerance? I mean what happens if this path is broken and the communication is re-routed through another firewall? I mean this would introduce some of the issues of NAT. Regards, marcelo > Then you don't need the explicit identifiers > as per the above. > > Iljitsch -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Wed Feb 26 06:15:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01049 for ; Wed, 26 Feb 2003 06:15:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nzZS-0005fX-00 for multi6-data@psg.com; Wed, 26 Feb 2003 03:17:54 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18nzZQ-0005fL-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 03:17:52 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1QBJ1if000565; Wed, 26 Feb 2003 12:19:02 +0100 (CET) Date: Wed, 26 Feb 2003 12:19:01 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: RJ Atkinson , Erik Nordmark , multi6@ops.ietf.org To: Eliot Lear From: Kurt Erik Lindqvist In-Reply-To: <3E5B7D11.3090106@cisco.com> Message-Id: <1B42B66A-497C-11D7-ADF5-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So what I'm getting from this discussion is that 8+8 is too late but > 16+16 is too large??? I would agree that 16+16 is too large. How > about 4+16? > I am still curious as to why people think that 16+16 would be any different to 8+8. - kurtis - From owner-multi6@ops.ietf.org Wed Feb 26 09:03:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05467 for ; Wed, 26 Feb 2003 09:03:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o29n-000C1i-00 for multi6-data@psg.com; Wed, 26 Feb 2003 06:03:35 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #1) id 18o29c-000C1K-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 06:03:24 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1QE398o011436 for ; Wed, 26 Feb 2003 15:03:11 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1QE31G2285910 for ; Wed, 26 Feb 2003 15:03:01 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54786 from ; Wed, 26 Feb 2003 15:02:59 +0100 Message-Id: <3E5CC8DD.C1217402@hursley.ibm.com> Date: Wed, 26 Feb 2003 15:02:05 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers References: <1B42B66A-497C-11D7-ADF5-000393AB1404@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist wrote: > > > So what I'm getting from this discussion is that 8+8 is too late but > > 16+16 is too large??? I would agree that 16+16 is too large. How > > about 4+16? > > > > I am still curious as to why people think that 16+16 would be any > different to 8+8. Because, like 4+16, it can coexist with plain 16. Whether people like it or not, the product investments in RFC 2460 at this point oblige any plausible solution to behave as an upgrade to plain 16. Brian From owner-multi6@ops.ietf.org Wed Feb 26 09:06:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05636 for ; Wed, 26 Feb 2003 09:06:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o2G8-000CLk-00 for multi6-data@psg.com; Wed, 26 Feb 2003 06:10:08 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 18o2G4-000CL8-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 06:10:05 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1QE9xLD104624 for ; Wed, 26 Feb 2003 15:09:59 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1QE9wG2064658 for ; Wed, 26 Feb 2003 15:09:58 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52224 from ; Wed, 26 Feb 2003 15:09:56 +0100 Message-Id: <3E5CCA7E.B8E5DC4E@hursley.ibm.com> Date: Wed, 26 Feb 2003 15:09:02 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers References: <200302251539.h1PFdT0Y018750@ginger.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "J. Noel Chiappa" wrote: > > > From: Eliot Lear > > > So what I'm getting from this discussion is that 8+8 is too late but > > 16+16 is too large??? > > I would suggest that 16+16 be done not with a complete second IPv6 header, > but rather one of the routing headers (I forget the formal name). That would > make it somewhat smaller. > > Anyway, why does header size matter that much? Those on slow links (< 56K) > will be using header compression anyway, so it doesn't really matter for them > since the average packet will have all that stuff compressed out anyway, and > for those on fast links, who cares about a few extra bytes? > > Check out the average web page to see how many stupid little icons it has on > it, how many JavaScript files it loads, how many pop-up windows (with their > own images and Javascript) it loads, etc, etc. (Every Web page designer ought > to be sentenced by law to using a 28.8 modem for all their online access... > but I digress.) > > > I would agree that 16+16 is too large. How about 4+16? > > You mean, wrap an IPv6 packet in an IPv4 packet? > > First, that would produce a packet of the exact same length as my suggestion > above (an IPv4 header is 20 bytes, after all). > > It would have the advantage that it could be carried over existing > substrate. It has the further advantage of being already implemented, at a basic level. > It would have the disadvantage that you'd be limited to a 32-bit > locator, something that's already causing us grief. More precisely, we don't know how to aggregate 32 bit locators any better than 64 bit locators. 4 billion wide-area locators doesn't seem to be too bad in itself. > (And don't even *think* about moving some of the "local" topology > information into the IPv6 addresses, leaving only the "global" stuff in the > IPv4 header. Long architectural rant about why you don't spread > functionality across two namespaces left out, as an exercise to the reader.) Ah, but pragmatic rant about how it's likely to happen anyway also left out :-( . Brian From owner-multi6@ops.ietf.org Wed Feb 26 09:17:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06009 for ; Wed, 26 Feb 2003 09:17:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o2QC-000Cle-00 for multi6-data@psg.com; Wed, 26 Feb 2003 06:20:32 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #1) id 18o2Q5-000ClJ-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 06:20:25 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1QEKM8o106638 for ; Wed, 26 Feb 2003 15:20:22 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1QEKLG2068586 for ; Wed, 26 Feb 2003 15:20:21 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58706 from ; Wed, 26 Feb 2003 15:20:20 +0100 Message-Id: <3E5CCCED.BA4FB5FA@hursley.ibm.com> Date: Wed, 26 Feb 2003 15:19:25 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Headers References: <4DFA4687-48F1-11D7-BF31-000393C52D28@muada.com> <1046254727.717.4.camel@presto.it.uc3m.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: ... > > I would rather have the firewalls take part in the session > > establishment procedure. > > Wouldn't this preclude fault tolerance? I mean what happens if this path > is broken and the communication is re-routed through another firewall? I > mean this would introduce some of the issues of NAT. Correct, or more generally the issues of any stateful middlebox. The Internet doesn't have sessions, so middleboxes shouldn't have session state. However, it seems likely that any solution will involve either a header rewrite or an encapsulation process. It is a design requirement that any distributed state needed for this is soft state, for the reasom Marcelo gives. Brian From owner-multi6@ops.ietf.org Wed Feb 26 09:47:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07996 for ; Wed, 26 Feb 2003 09:47:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o2tE-000EIA-00 for multi6-data@psg.com; Wed, 26 Feb 2003 06:50:32 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18o2tA-000EHi-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 06:50:28 -0800 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 h1QEoPkw024793; Wed, 26 Feb 2003 09:50:25 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1QEoOox024792; Wed, 26 Feb 2003 09:50:24 -0500 Date: Wed, 26 Feb 2003 09:50:24 -0500 From: "J. Noel Chiappa" Message-Id: <200302261450.h1QEoOox024792@ginger.lcs.mit.edu> To: brian@hursley.ibm.com, multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=1.8 required=5.0 tests=LINES_OF_YELLING,SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter >> [4+16] would have the disadvantage that you'd be limited to a 32-bit >> locator, something that's already causing us grief. > 4 billion wide-area locators doesn't seem to be too bad in itself. Sorry, I didn't follow what you meant by "wide-area locators". Did you mean that (contrary to my express guidance immediately below) these 32 bits would only hold the "high order" part of the location? Or did you mean that 32 bits of locator would be enough? >> (And don't even *think* about moving some of the "local" topology >> information into the IPv6 addresses, leaving only the "global" stuff >> in the IPv4 header. Long architectural rant about why you don't >> spread functionality across two namespaces left out, as an exercise >> to the reader.) > Ah, but pragmatic rant about how it's likely to happen anyway also > left out :-( Well, at least you added a ":-(", which I take to mean that you realize it's a bad idea - so if that's true, please don't take what follows as directed at you. One of my favourite quotations is from Benjamin Franklin's "Poor Richard's Almanac", and it goes: EXPERIENCE IS A DEAR MASTER, BUT FOOLS WILL LEARN AT NO OTHER. So what exactly do you call someone who has the painful experience, and *still* refuses to learn? Clearly, something even lower than a fool. The IPv6 community got into the corner it's in now because it took the path of least technical resistance: IPv6 looks a lot like IPv4 because we "know" that IPv4 "works". Well, guess what, IPv4 *doesn't* work, and IPng needed to look really different, and those of us who tried to tell the rest of the IETF that didn't get very far - although I think we gave it a pretty good try. So if the IPv6 community again takes the path of least technical resistance, having not learned the first time around that that's really not the answer, G-d help you all. Noel From owner-multi6@ops.ietf.org Wed Feb 26 10:03:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09043 for ; Wed, 26 Feb 2003 10:03:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o38a-000F2D-00 for multi6-data@psg.com; Wed, 26 Feb 2003 07:06:24 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18o38V-000F1z-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 07:06:19 -0800 Received: from extremenetworks.com (unknown [10.0.8.75]) by gnat.inet.org (Postfix) with ESMTP id C127A67104; Wed, 26 Feb 2003 10:20:00 -0500 (EST) Date: Wed, 26 Feb 2003 10:06:15 -0500 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: RJ Atkinson In-Reply-To: <3E5CC8DD.C1217402@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Feb 26, 2003, at 09:02 America/Montreal, Brian E Carpenter wrote: > Whether people like > it or not, the product investments in RFC 2460 at this point oblige > any plausible solution to behave as an upgrade to plain 16. I'm not persuaded that is true. Certainly I know a lot of IPv6 deployed sites that are NOT taking the position above. Ran From owner-multi6@ops.ietf.org Wed Feb 26 10:38:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12226 for ; Wed, 26 Feb 2003 10:38:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o3h0-000GoF-00 for multi6-data@psg.com; Wed, 26 Feb 2003 07:41:58 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18o3gs-000Go2-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 07:41:51 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1QFf0L35203; Wed, 26 Feb 2003 16:41:00 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 26 Feb 2003 16:41:00 +0100 (CET) From: Iljitsch van Beijnum To: Brian E Carpenter cc: Subject: Re: Headers In-Reply-To: <3E5CCCED.BA4FB5FA@hursley.ibm.com> Message-ID: <20030226162556.S61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 26 Feb 2003, Brian E Carpenter wrote: > > > I would rather have the firewalls take part in the session > > > establishment procedure. > > Wouldn't this preclude fault tolerance? I mean what happens if this path > > is broken and the communication is re-routed through another firewall? I > > mean this would introduce some of the issues of NAT. > Correct, or more generally the issues of any stateful middlebox. Note that we are not requiring firewalls; other people are. If they fail to require these boxes to handle the necessary state the right way, that's their problem. If a firewall is made part of the whole process at least we get to implement some hooks for restoring the state if said firewall breaks. > The Internet doesn't have sessions, so middleboxes shouldn't > have session state. If you want to be completely stateless, you need to include all the identifying information in each packet. But this information is easily spoofed, so you need additional authentication data. (Can't use IPsec here as that has state.) Fortunately, not much communication is stateless by necessity, it's just implemented over stateless primitives because that has some advantages. I wouldn't be against a situation where we have a stateful multihoming protocol with low per-packet overhead and a stateless multihoming protocol where everything is inside a single packet. However, I would be against a multihoming solution where stateful protocols carry information in each packet that is implied by the session state. From owner-multi6@ops.ietf.org Wed Feb 26 10:44:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12605 for ; Wed, 26 Feb 2003 10:44:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o3mb-000H40-00 for multi6-data@psg.com; Wed, 26 Feb 2003 07:47:45 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18o3mT-000H3H-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 07:47:37 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1QFkkp35218; Wed, 26 Feb 2003 16:46:47 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 26 Feb 2003 16:46:46 +0100 (CET) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: Message-ID: <20030226164336.I61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 26 Feb 2003, RJ Atkinson wrote: > > Whether people like > > it or not, the product investments in RFC 2460 at this point oblige > > any plausible solution to behave as an upgrade to plain 16. > I'm not persuaded that is true. Certainly I know a lot of IPv6 > deployed sites that are NOT taking the position above. Are you saying you wouldn't mind significant changes in the IPv6 packet format? This would essentially be IPv7. In that case I have a few ideas... From owner-multi6@ops.ietf.org Wed Feb 26 11:00:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13429 for ; Wed, 26 Feb 2003 11:00:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o41v-000HrR-00 for multi6-data@psg.com; Wed, 26 Feb 2003 08:03:35 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18o41n-000Hqx-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 08:03:27 -0800 Received: from extremenetworks.com (unknown [10.0.8.83]) by gnat.inet.org (Postfix) with ESMTP id 3111167104; Wed, 26 Feb 2003 11:17:08 -0500 (EST) Date: Wed, 26 Feb 2003 11:03:22 -0500 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20030226164336.I61596-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Feb 26, 2003, at 10:46 America/Montreal, Iljitsch van Beijnum wrote: > Are you saying you wouldn't mind significant changes in the IPv6 packet > format? This would essentially be IPv7. There is some middle ground between "one can't change anything in RFC-2460" and "essentially IPv7". I should hope that someplace in that middle ground sufficient manuevering room could be found. Certainly I'm not advocating dumping IPv6 wholesale, though I'm not above a tweak here or there to the specs IFF it makes a sufficient improvement to be worth the pain. Ran From owner-multi6@ops.ietf.org Wed Feb 26 11:02:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13669 for ; Wed, 26 Feb 2003 11:02:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o44I-000Hyc-00 for multi6-data@psg.com; Wed, 26 Feb 2003 08:06:02 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 18o44G-000HyO-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 08:06:00 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1QG5bLD107698; Wed, 26 Feb 2003 17:05:44 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1QG59G2277090; Wed, 26 Feb 2003 17:05:10 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31446 from ; Wed, 26 Feb 2003 17:04:52 +0100 Message-Id: <3E5CE56E.D080BCBE@hursley.ibm.com> Date: Wed, 26 Feb 2003 17:03:58 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: RJ Atkinson Cc: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit RJ Atkinson wrote: > > On Wednesday, Feb 26, 2003, at 09:02 America/Montreal, Brian E > Carpenter wrote: > > Whether people like > > it or not, the product investments in RFC 2460 at this point oblige > > any plausible solution to behave as an upgrade to plain 16. > > I'm not persuaded that is true. Certainly I know a lot of IPv6 > deployed sites that are NOT taking the position above. I'm not talking about that. I'm talking about implementors. There is no way on earth existings stacks are going to get demolished and reconstructed. Even getting them enhanced will mean a lot of heavy lifting. Please see requirements 3.2.2 and 3.2.3 in the multi6 requirements draft. (If there's a way to make 8+8 meet those requirements, fine.) Brian From owner-multi6@ops.ietf.org Wed Feb 26 11:16:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14256 for ; Wed, 26 Feb 2003 11:16:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o4Gf-000Id1-00 for multi6-data@psg.com; Wed, 26 Feb 2003 08:18:49 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18o4GS-000Ic7-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 08:18:36 -0800 Received: from extremenetworks.com (unknown [10.0.8.83]) by gnat.inet.org (Postfix) with ESMTP id 0236E67104; Wed, 26 Feb 2003 11:32:17 -0500 (EST) Date: Wed, 26 Feb 2003 11:18:32 -0500 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: RJ Atkinson In-Reply-To: <3E5CE56E.D080BCBE@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Feb 26, 2003, at 11:03 America/Montreal, Brian E Carpenter wrote: > There is no way on earth existings stacks are going to get demolished > and > reconstructed. Even getting them enhanced will mean a lot of > heavy lifting. I know of several significant implementers who would be willing to make significant changes to their IPv6 stack, IFF it would have significant improvements for IPv6. Getting multi-homing into a scalable state would be one example of a significant improvement. Making mobility a first-order property, rather than a "Mobile IP" add-on protocol, might be another one (not sure). Frankly, part of the implementers' willingness is caused by desire to see their code get widely deployed operationally. I've personally worked on ~4 different IPv6 implementations since 1995, and I don't see ANY way that IPv6 will EVER be widely deployed given the current trajectory (i.e. there is no significant win to migrating to IPv6 that is visible; IPv6 needs a "killer feature", multi-homing or other routing improvements could be that, the extant misleading claims of IPv4 address shortages is NOT such a feature). As noted in a note earlier today, a significant change to IPv6 stacks is one thing. Throwing IPv6 out entirely is something entirely different; I don't advocate the latter at all. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Wed Feb 26 12:50:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17755 for ; Wed, 26 Feb 2003 12:50:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o5jG-000NG1-00 for multi6-data@psg.com; Wed, 26 Feb 2003 09:52:26 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18o5jC-000NFo-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 09:52:22 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E7284137F02; Wed, 26 Feb 2003 09:52:19 -0800 (PST) Date: Wed, 26 Feb 2003 09:52:21 -0800 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: David Conrad In-Reply-To: <3E5CCA7E.B8E5DC4E@hursley.ibm.com> Message-Id: <0DF500EA-49B3-11D7-92B3-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, On Wednesday, February 26, 2003, at 06:09 AM, Brian E Carpenter wrote: > More precisely, we don't know how to aggregate 32 bit locators > any better than 64 bit locators. Um. Yes we do. It is called CIDR. It is well understood and has the minor advantage of being deployed. What we don't know how to do is aggregate in the face of people refusing to aggregate for 'non-network-topologic' (e.g., economic, political, business, etc.) reasons. One known and obvious way of doing this is by separating the two and providing a mapping. Locators can then be re-arranged without getting into non-network-topologic arguments. Rgds, -drc From owner-multi6@ops.ietf.org Wed Feb 26 13:09:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18517 for ; Wed, 26 Feb 2003 13:09:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o62p-000OIw-00 for multi6-data@psg.com; Wed, 26 Feb 2003 10:12:39 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #1) id 18o62h-000OHi-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 10:12:31 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1QHtEDO046580; Wed, 26 Feb 2003 19:12:18 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1QGChG2210416; Wed, 26 Feb 2003 17:12:53 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38656 from ; Wed, 26 Feb 2003 17:12:41 +0100 Message-Id: <3E5CE742.380B914B@hursley.ibm.com> Date: Wed, 26 Feb 2003 17:11:46 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "J. Noel Chiappa" Cc: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers References: <200302261450.h1QEoOox024792@ginger.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.2 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_05_08, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yes, I think that if we were to pursue 4+16 it would exactly cause us to have two namespaces containing different parts of the locator. I did say :-(. (Of course, it's exactly what we have today with NAT.) Brian "J. Noel Chiappa" wrote: > > > From: Brian E Carpenter > > >> [4+16] would have the disadvantage that you'd be limited to a 32-bit > >> locator, something that's already causing us grief. > > > 4 billion wide-area locators doesn't seem to be too bad in itself. > > Sorry, I didn't follow what you meant by "wide-area locators". Did you mean > that (contrary to my express guidance immediately below) these 32 bits would > only hold the "high order" part of the location? Or did you mean that 32 > bits of locator would be enough? > > >> (And don't even *think* about moving some of the "local" topology > >> information into the IPv6 addresses, leaving only the "global" stuff > >> in the IPv4 header. Long architectural rant about why you don't > >> spread functionality across two namespaces left out, as an exercise > >> to the reader.) > > > Ah, but pragmatic rant about how it's likely to happen anyway also > > left out :-( > > Well, at least you added a ":-(", which I take to mean that you realize it's > a bad idea - so if that's true, please don't take what follows as directed > at you. > > One of my favourite quotations is from Benjamin Franklin's "Poor Richard's > Almanac", and it goes: > > EXPERIENCE IS A DEAR MASTER, BUT FOOLS WILL LEARN AT NO OTHER. > > So what exactly do you call someone who has the painful experience, and > *still* refuses to learn? Clearly, something even lower than a fool. > > The IPv6 community got into the corner it's in now because it took the path > of least technical resistance: IPv6 looks a lot like IPv4 because we "know" > that IPv4 "works". Well, guess what, IPv4 *doesn't* work, and IPng needed to > look really different, and those of us who tried to tell the rest of the > IETF that didn't get very far - although I think we gave it a pretty good > try. > > So if the IPv6 community again takes the path of least technical resistance, > having not learned the first time around that that's really not the answer, > G-d help you all. > > Noel From owner-multi6@ops.ietf.org Wed Feb 26 13:25:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18996 for ; Wed, 26 Feb 2003 13:25:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o6Im-000PCr-00 for multi6-data@psg.com; Wed, 26 Feb 2003 10:29:08 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18o6Ii-000PCP-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 10:29:04 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18o6EK-000GFR-00 for multi6@ops.ietf.org; Thu, 27 Feb 2003 03:24:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200302261228.h1QCS9dB024202@ginger.lcs.mit.edu> Date: Wed, 26 Feb 2003 07:28:09 -0500 From: "J. Noel Chiappa" To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.6 required=5.0 tests=RESENT_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > From: Kurt Erik Lindqvist > I am still curious as to why people think that 16+16 would be any > different to 8+8. To make 8+8 work you have to change the TCP checksum algorithm - or at least change TCP so that when the locator part of the address changes, it changes what's in the pseudo-header it uses for computing checksums (and then you have to make sure you change the pseudo-header at the exact right packet). Noel From owner-multi6@ops.ietf.org Wed Feb 26 13:30:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19173 for ; Wed, 26 Feb 2003 13:30:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o6NG-000PSR-00 for multi6-data@psg.com; Wed, 26 Feb 2003 10:33:46 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18o6NB-000PRA-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 10:33:41 -0800 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 h1QIXdkw025771; Wed, 26 Feb 2003 13:33:39 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1QIXcHY025768; Wed, 26 Feb 2003 13:33:38 -0500 Date: Wed, 26 Feb 2003 13:33:38 -0500 From: "J. Noel Chiappa" Message-Id: <200302261833.h1QIXcHY025768@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter > I think that if we were to pursue 4+16 it would exactly cause us to > have two namespaces containing different parts of the locator. "Experience is a dear master, but fools will learn at no other." > I did say :-(. Oh, if you're right, I'm overjoyed! The final nail in IPv6's coffin! Hoorah! > (Of course, it's exactly what we have today with NAT.) Now, now. May I get you a saucer of milk? Noel From owner-multi6@ops.ietf.org Wed Feb 26 15:06:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22234 for ; Wed, 26 Feb 2003 15:06:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18o7rk-0004mx-00 for multi6-data@psg.com; Wed, 26 Feb 2003 12:09:20 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18o7rg-0004mL-00 for multi6@ops.ietf.org; Wed, 26 Feb 2003 12:09:16 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18o7ri-000GOo-00 for multi6@ops.ietf.org; Thu, 27 Feb 2003 05:09:18 +0900 In-Reply-To: <200302261228.h1QCS9dB024202@ginger.lcs.mit.edu> Message-ID: <20030226200053.S61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 26 Feb 2003 20:28:30 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: Draft: PI addressing derived from AS numbers X-Spam-Status: No, hits=-2.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 26 Feb 2003, J. Noel Chiappa wrote: > > I am still curious as to why people think that 16+16 would be any > > different to 8+8. > To make 8+8 work you have to change the TCP checksum algorithm - or at least > change TCP so that when the locator part of the address changes, it changes > what's in the pseudo-header it uses for computing checksums (and then you > have to make sure you change the pseudo-header at the exact right packet). That's the easy part. And if you implement 16+16 you get 8+8 almost for free if you make the last 8 bytes of the first "16" and the first 8 bytes of the last "16" 0. This will checksum correctly because the presence of additional 0x0000 values in the data to be checksummed doesn't change the result. The advantage of 16+16 is that you don't have to change hosts: the checksum and autoconfig still work. Also, if you don't implement 16+16 as two sets of addresses in each packet, but rather as rewriting the addresses, the necessary state automatically protects you against simple attacks. And 16+16 allows large parts of end-user networks to use "topology independent" addresses (yes, I think that's the right term here, but "provider independent" will do too). The really cool part there is that if we decide we're going to do 16+16 we can allow the TI/PI addresses in the global routing table in the mean time and make them disappear behind the rewriting boxes when the time comes. The hard part is setting up the rewriting state. Michel Py has a draft that basically floods this information over special purpose boxes throughout the net. I'm more in favor of a system where this information is negotiated as needed. Iljitsch From owner-multi6@ops.ietf.org Thu Feb 27 04:24:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23628 for ; Thu, 27 Feb 2003 04:24:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oKHX-000Min-00 for multi6-data@psg.com; Thu, 27 Feb 2003 01:24:47 -0800 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18oKHO-000MiQ-00 for multi6@ops.ietf.org; Thu, 27 Feb 2003 01:24:39 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1R9Puif009683; Thu, 27 Feb 2003 10:25:56 +0100 (CET) Date: Thu, 27 Feb 2003 10:25:55 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3E5CC8DD.C1217402@hursley.ibm.com> Message-Id: <7914874E-4A35-11D7-ADF5-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> So what I'm getting from this discussion is that 8+8 is too late but >>> 16+16 is too large??? I would agree that 16+16 is too large. How >>> about 4+16? >>> >> >> I am still curious as to why people think that 16+16 would be any >> different to 8+8. > > Because, like 4+16, it can coexist with plain 16. Whether people like > it or not, the product investments in RFC 2460 at this point oblige > any plausible solution to behave as an upgrade to plain 16. > Ok, I can see that. I was just under the (apparently mistaken) impression that people thought there was some superior architectural advantage with 16+16. Best regards, - kurtis - From owner-multi6@ops.ietf.org Thu Feb 27 04:44:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23899 for ; Thu, 27 Feb 2003 04:44:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oKe4-000NPT-00 for multi6-data@psg.com; Thu, 27 Feb 2003 01:48:04 -0800 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18oKdu-000NPF-00 for multi6@ops.ietf.org; Thu, 27 Feb 2003 01:47:55 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h1R9nAif009706; Thu, 27 Feb 2003 10:49:10 +0100 (CET) Date: Thu, 27 Feb 2003 10:49:10 +0100 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Brian E Carpenter , multi6@ops.ietf.org To: RJ Atkinson From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> There is no way on earth existings stacks are going to get >> demolished and >> reconstructed. Even getting them enhanced will mean a lot of >> heavy lifting. > > I know of several significant implementers who would be willing to make > significant changes to their IPv6 stack, IFF it would have significant > improvements for IPv6. Getting multi-homing into a scalable state > would > be one example of a significant improvement. Making mobility a > first-order > property, rather than a "Mobile IP" add-on protocol, might be another > one > (not sure). I think you are right. However, I still think that we are trying to solve everything in one go. I think that we will have to go to a 8+8 or 16+16 model, but not from day one. We will have to realize that we need to change things a bit at a time. This will most likely also mean that getting adoption for changes is easier. So besides working on the end outcome we should also be looking at how to get there. - kurtis - From owner-multi6@ops.ietf.org Thu Feb 27 05:19:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24458 for ; Thu, 27 Feb 2003 05:19:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oLBt-000OSI-00 for multi6-data@psg.com; Thu, 27 Feb 2003 02:23:01 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18oLBp-000OS4-00 for multi6@ops.ietf.org; Thu, 27 Feb 2003 02:22:57 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA12395 for ; Thu, 27 Feb 2003 10:22:54 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA28159 for ; Thu, 27 Feb 2003 10:22:54 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h1RAMsm05256 for multi6@ops.ietf.org; Thu, 27 Feb 2003 10:22:54 GMT Date: Thu, 27 Feb 2003 10:22:54 +0000 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers Message-ID: <20030227102253.GS1648@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <3E5CC8DD.C1217402@hursley.ibm.com> <7914874E-4A35-11D7-ADF5-000393AB1404@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7914874E-4A35-11D7-ADF5-000393AB1404@kurtis.pp.se> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, Feb 27, 2003 at 10:25:55AM +0100, Kurt Erik Lindqvist wrote: > >>>So what I'm getting from this discussion is that 8+8 is too late but > >>>16+16 is too large??? I would agree that 16+16 is too large. How > >>>about 4+16? > >>> > >> > >>I am still curious as to why people think that 16+16 would be any > >>different to 8+8. > > > >Because, like 4+16, it can coexist with plain 16. Whether people like > >it or not, the product investments in RFC 2460 at this point oblige > >any plausible solution to behave as an upgrade to plain 16. > > > > Ok, I can see that. I was just under the (apparently mistaken) > impression that people thought there was some superior architectural > advantage with 16+16. Well, unless you could do something very clever with the "unused" 20 bits in the v6 header... I suspect that's the only tweak that could get wide acceptance (compared to suggestions to use DSCP's for multihoming, which I personally don't feel comfortable with). Tim From owner-multi6@ops.ietf.org Thu Feb 27 06:03:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25115 for ; Thu, 27 Feb 2003 06:03:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oLri-000Phw-00 for multi6-data@psg.com; Thu, 27 Feb 2003 03:06:14 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18oLre-000Phj-00 for multi6@ops.ietf.org; Thu, 27 Feb 2003 03:06:10 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h1RB5Dk37448; Thu, 27 Feb 2003 12:05:13 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 27 Feb 2003 12:05:13 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: Message-ID: <20030227114102.A61596-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 27 Feb 2003, Kurt Erik Lindqvist wrote: > > I know of several significant implementers who would be willing to make > > significant changes to their IPv6 stack, IFF it would have significant > > improvements for IPv6. Getting multi-homing into a scalable state > > would be one example of a significant improvement. Making mobility a > > first-order property, rather than a "Mobile IP" add-on protocol, > > might be another one (not sure). > I think you are right. However, I still think that we are trying to > solve everything in one go. I think that we will have to go to a 8+8 or > 16+16 model, but not from day one. We will have to realize that we need > to change things a bit at a time. This will most likely also mean that > getting adoption for changes is easier. So besides working on the end > outcome we should also be looking at how to get there. It all depends on whether you're going to do incremental upgrades that work well with existing stuff or if you're going to break existing implementations. In the latter case, you should do everything in one go. Apart from that I'm not all that concerned with the size of the steps but rather their direction. We need to establish some long-term goals so we can keep our eye on the prize (and other eye on the price) when making those smaller steps. We don't want to paint ourselves into a corner. (Arguably, we already have.) My ultimate goal would be to make applications and transport protocols independent of IP by allowing anything that's suitable for an identifier (hostnames, crypto stuff) and leave the addresses/locators to lower layers. An intermediate step could be middleboxes that replace PI identifier addresses with PA locator addresses for outbound and the other way around for inbound traffic. An intermediate step before that would then be to use these PI identifiers in IPv4-like multihoming for a limited time. Iljitsch From owner-multi6@ops.ietf.org Thu Feb 27 09:18:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04357 for ; Thu, 27 Feb 2003 09:18:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oOtL-000710-00 for multi6-data@psg.com; Thu, 27 Feb 2003 06:20:07 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18oOtE-000706-00 for multi6@ops.ietf.org; Thu, 27 Feb 2003 06:20:00 -0800 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 h1REJwkw000718; Thu, 27 Feb 2003 09:19:58 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h1REJwmr000715; Thu, 27 Feb 2003 09:19:58 -0500 Date: Thu, 27 Feb 2003 09:19:58 -0500 From: "J. Noel Chiappa" Message-Id: <200302271419.h1REJwmr000715@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Kurt Erik Lindqvist > I was just under the (apparently mistaken) impression that people > thought there was some superior architectural advantage with 16+16. [Not quite sure if your comment relates to 16+16 vis a vis only 8+8, or to 4+16 as well...] The advantages of 16+16 over 8+8 are purely deployment ones. The advantages of 16+16 over 4+16 depend on exactly what flavour of 4+16 you're talking of. If you're talking of the one that Brian glumly forsees as inevitable, where the location is spread across the two fields, there *is* an architectural advantage to 16+16. Noel From owner-multi6@ops.ietf.org Fri Feb 28 04:46:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18777 for ; Fri, 28 Feb 2003 04:46:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oh65-000Pu5-00 for multi6-data@psg.com; Fri, 28 Feb 2003 01:46:29 -0800 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 18oh5e-000Psk-00 for multi6@ops.ietf.org; Fri, 28 Feb 2003 01:46:26 -0800 Received: from sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h1QHW6v09507 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 26 Feb 2003 12:32:08 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h1QHW4Fp022315 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 26 Feb 2003 12:32:06 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h1QHW4D9022311 for ; Wed, 26 Feb 2003 12:32:04 -0500 Message-Id: <200302261732.h1QHW4D9022311@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers In-reply-to: Your message of "Tue, 25 Feb 2003 08:44:06 EST." <35688674-48C7-11D7-81FE-00039357A82A@extremenetworks.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 26 Feb 2003 12:32:03 -0500 From: Michael Richardson X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> "RJ" == RJ Atkinson writes: RJ> On Tuesday, Feb 25, 2003, at 08:06 America/Montreal, Erik Nordmark RJ> wrote: >> It would presumably be easier to maintain the compression state in the >> transport protocols (due to fate sharing etc) than in a separate >> entity, whether it is below transport in the endpoints or in a >> separate box. RJ> s/transport protocols/end systems/ RJ> Its not at all clear to me that such compression state belongs in RJ> TCP/UDP/SCTP rather than being inside IP. In practice, any IPv6 host RJ> has some amount of IPv6 protocol state. That is probably the right RJ> place for this information. RJ> That might well be reasonable. One would want to see the details RJ> before drawing a firm conclusion, of course. RJ> In my book, "reasonably strong binding" means some form of RJ> cryptographic authentication. Gosh, this sure sounds like the packets ought look like: IPv6, AH, IPcomp-well-known-CPI, IPv6, TCP ^could be ESP-null The IPsec SPI contains all the state that you need. I assume that we'll worry about how to map end system identifier to locator later. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-multi6@ops.ietf.org Fri Feb 28 08:31:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27274 for ; Fri, 28 Feb 2003 08:31:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18okeN-0007vc-00 for multi6-data@psg.com; Fri, 28 Feb 2003 05:34:07 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18okeK-0007tu-00 for multi6@ops.ietf.org; Fri, 28 Feb 2003 05:34:05 -0800 Received: from extremenetworks.com (unknown [10.0.8.145]) by gnat.inet.org (Postfix) with ESMTP id AA25867120; Fri, 28 Feb 2003 08:48:04 -0500 (EST) Date: Fri, 28 Feb 2003 08:33:59 -0500 Subject: Re: Draft: PI addressing derived from AS numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Michael Richardson From: RJ Atkinson In-Reply-To: <200302261732.h1QHW4D9022311@marajade.sandelman.ottawa.on.ca> Message-Id: <4AF926CE-4B21-11D7-A1BB-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_03_05,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Feb 26, 2003, at 12:32 America/Montreal, Michael Richardson wrote: > Gosh, this sure sounds like the packets ought look like: > IPv6, AH, IPcomp-well-known-CPI, IPv6, TCP > ^could be ESP-null > The IPsec SPI contains all the state that you need. It is not at all clear to me that one needs to use AH/ESP on each data packet in order to have protection equivalent to existing IPv4 packets that are not using AH/ESP. For example, one could imagine using a new ICMP message type to update locator/identity bindings for sessions/flows that are already established -- always using AH on that ICMP message type. I see no need to tunnel IPv6-in-IPv6 normally. I see no need for IPcomp-well-known-CPI normally. So I'd suggest that a typical packet would look more like: IPv6(*), TCP Where (*) is to note that minor tweaks might be needed, either to the IPv6 base header or by adding an IPv6 Routing Header or by some other mechanism, to support identity/locator separation. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Fri Feb 28 11:14:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03336 for ; Fri, 28 Feb 2003 11:14:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18onBt-000F5x-00 for multi6-data@psg.com; Fri, 28 Feb 2003 08:16:53 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 18onBi-000F5I-00 for multi6@ops.ietf.org; Fri, 28 Feb 2003 08:16:45 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1SGGYLD009682; Fri, 28 Feb 2003 17:16:34 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1SGGWsa088294; Fri, 28 Feb 2003 17:16:34 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25544 from ; Fri, 28 Feb 2003 17:16:29 +0100 Message-Id: <3E5F8B26.7456AE75@hursley.ibm.com> Date: Fri, 28 Feb 2003 17:15:34 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: David Conrad Cc: multi6@ops.ietf.org Subject: Re: Draft: PI addressing derived from AS numbers References: <0DF500EA-49B3-11D7-92B3-000393DB42B2@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I meant that we know how to do it for 64 bits (PA) or 32 bits (CIDR) equally well. I agree with waht you say. Brian David Conrad wrote: > > Brian, > > On Wednesday, February 26, 2003, at 06:09 AM, Brian E Carpenter wrote: > > More precisely, we don't know how to aggregate 32 bit locators > > any better than 64 bit locators. > > Um. Yes we do. It is called CIDR. It is well understood and has the > minor advantage of being deployed. What we don't know how to do is > aggregate in the face of people refusing to aggregate for > 'non-network-topologic' (e.g., economic, political, business, etc.) > reasons. One known and obvious way of doing this is by separating the > two and providing a mapping. Locators can then be re-arranged without > getting into non-network-topologic arguments. > > Rgds, > -drc