From owner-Big-Internet@munnari.OZ.AU Wed Aug 23 17:11:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05638; Wed, 23 Aug 1995 17:11:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA01260; Wed, 23 Aug 1995 17:05:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01243; Wed, 23 Aug 1995 16:54:48 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04921; Wed, 23 Aug 1995 16:54:17 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA02426; Tue, 22 Aug 1995 23:54:09 -0700 Date: Tue, 22 Aug 1995 23:54:09 -0700 From: Tony Li Message-Id: <199508230654.XAA02426@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: <11745.809080243@munnari.OZ.AU> (message from Robert Elz on Tue, 22 Aug 1995 18:30:43 +1000) Subject: Re: ownership, leasing, renumbering, and that draft Precedence: bulk Note that if a chair, AD, or doc author, questions this message with a response like "Well, what else can we do?" I will take that as an explicit OK to go ahead and post my suggestions, and debate their merits. Well, what else can we do? Tony From owner-Big-Internet@munnari.OZ.AU Wed Aug 23 21:08:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15127; Wed, 23 Aug 1995 21:08:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA01514; Wed, 23 Aug 1995 21:05:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA01504; Wed, 23 Aug 1995 21:00:16 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB14801; Wed, 23 Aug 1995 21:00:13 +1000 (from rgm3@is.chrysler.com) Received: from sg543689.eng.chrysler.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12022 Wed, 23 Aug 1995 20:59:48 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id GAA09746; Wed, 23 Aug 1995 06:58:22 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id GAA28947; Wed, 23 Aug 1995 06:58:21 -0400 Received: from rgm3 (cldnsts1.wkh.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA16492; Wed, 23 Aug 95 07:07:41 EDT Message-Id: <9508231107.AA16492@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Aug 1995 06:58:09 -0400 To: Tony Li , kre@munnari.OZ.AU From: Robert Moskowitz Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk At 11:54 PM 8/22/95 -0700, Tony Li wrote: > > Note that if a chair, AD, > or doc author, questions this message with a response like > "Well, what else can we do?" I will take that as an explicit > OK to go ahead and post my suggestions, and debate their merits. > >Well, what else can we do? Tell him to write a I-D already... ???? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Wed Aug 23 23:45:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21554; Wed, 23 Aug 1995 23:45:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA01753; Wed, 23 Aug 1995 23:45:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA01735; Wed, 23 Aug 1995 23:44:33 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21415; Wed, 23 Aug 1995 23:43:55 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Tue, 22 Aug 1995 23:54:09 MST." <199508230654.XAA02426@greatdane.cisco.com> Date: Wed, 23 Aug 1995 23:43:32 +1000 Message-Id: <12192.809185412@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Tue, 22 Aug 1995 23:54:09 -0700 From: Tony Li Message-ID: <199508230654.XAA02426@greatdane.cisco.com> Well, what else can we do? First, thanks, I think, for waking up this list - at least it allowed me to find a bunch of dead addresses and get them deleted... Second, as Tony's message may have left some B-I subscribers confused, he was responding to a (lengthy) message of mine on the cidrd list (those of you not there probably don't want to be, but if you do, cidrd-request@iepg.org will get you added - its a path into majordomo, so send majordomo type subscribe commands in the body of the request message). There the question of whether the current internet draft draft-ietf-cidrd-ownership-01.txt should be forwarded to the IESG with a recommendation that it be published as a BCP (see RFC1818) has been being debated. One of the reasons used to support the draft, which calls for all IP addresses in the future to be leased, rather than allocated in perpetuity, is that the Internet has no alternative, it must do this or the routing infrastructure will simply break. Read the draft for more arguments this way. I am not a supporter of the draft, for many reasons, the most basic of which is that I believe there is a better way. On the cidrd list, discussion of this alternative has been ruled out of order - on several grounds - one being that it is unproven (true, but so is the draft, whatever its proponents may say), another that cidrd is purely for the deployment of cidr, and anything which is not that is irrelevant there (which apparently includes showing that the proposed solution is not necessary, or attempting to do that). Anyway, this discussion has now moved here. First, the problem - the Internet default-free routing tables are growing, and growing rapidly, and will sometime be beyond the capacities of current routers. Even if the hardware vendors were willing to do it, essentially everyone recognises that simply building bigger hardware is not a solution that can possibly work, even in the relatively short term. RFC1519 (CIDR) gave us a solution, at least for a while, to the address space exhaustion issues that first caused this list to be started. It also held some hope for the routing table growth problems - by allowing multiple routes to be aggregated into one advertisment, both the size of the routing table, and the size/speed of the processor needed to handle processing changes to it could be contained. Unfortunately, this has not worked as well as hoped, and the routing tables continue to grow. The draft's solution is to attempt to cause the cidr solution to work better, by forcing most new connections to the Internet to use numbers that can be aggregated, and in particular to require those new connections to release their numbers when they move connection points, and sometimes, even when their provider changes, and acquire new ones. The question of whether even this will be sufficient, or whether existing connections may need to be required to be renumbered as well is still open (the draft says that is outside its scope). My solution, which is, incidentally, neither new, nor my invention, is to first buy some time. I believe we can accomplish that by being more agressive with requests for voluntary renumbering (cidrd has been told of some good success rates this way), and if necessary by a pretty obscure way of trading (lots of) $'s for extra time by dividing the routers into clusters of routers. During the time we can obtain by this means, we alter the way routing is done in the defaultless core, so that it is, in fact, based purely on highly topologically significant addresses, that can be renumbered as much as desired, but which are used only within the core (not visible at all, in any way, at end user sites). This allows the routing tables to be kept small, as small as desired basically (less routing information means less optimal paths can be constructed, so restricting the information beyond what is needed would be counter productive). The approach is conceptually very simple - when a packet arrives at a default free router, bearing a standard IP address, one of three cases holds. Either there is no route to the destination, and the packet is dropped, or the destination is at some local connection, routing is known, and the packet is forwarded locally, or the destination is somewhere through the core of the internet, traversing a default-free-router path to some exit point where the destination is "local". It is the last of those cases that is of interest here. The "renumber" solution attempts to make this manageable by forcing the upper bits of the address (upper for IPv4 is probably of the order of 16) to contain enough information to route the packet to its exit point from the core. That requires IPv4 addresses as used by end sites to match the current connection of the site - and consequently, requires renumbering when that connectivity alters. The alternative is to simply map the original destination IPv4 address into something that is topologically significant, and route using that address. To gain the maximum benefit from existing infrastructure, I would (doing this now, not ecessarily if we had years to plan and implement this scheme) make the mapped address be another IPv4 address, from a range reserved for the purpose, which could be the 240/4 space, or the 223/8 space, or anything else (even 10/8, as net 10 is now reserved, ad cannot be a valid internet destination). The original packet would then be encapsulated in a new IP packet, bearing the new address, sent through the core to the exit area, decapsulated, and then continue being routed using the original destination address which is now "local". There are unquestioned drawbacks to this approach - the first is that the routers at the entry and exit points will have more work to do than they now do (probably) and so will probably not be able to route as many packets per second as they could before. That may mean that some routers in this situation (ones nearly at capacity already) might need to be either upgraded, or split into two, each handling a part of the previous load. Note that this cost scales with the amount of traffic handled by the router, not with any external consideration, and so is manageable. Also, note that the cost of processing routing updates will decrease, which may even offset this cost (until it is actually measured we can only speculate). Second, users (which for this means end site network managers, real users don't care about this) would now see the internet core as a one hop black box, with no idea of the workings of that box, or what is happening inside - in this respect it would be like the old ARPANET (which could justify using 10/8). Traceroutes would show the packet enter the core, and then exit again, with no evidence of the path followed. There are probably more, which it would be useful to enumerate. The result of this change would be to trade a growing routing table for a growing mapping table, which at first glance doesn't seem like such a big win, however it has in fact two major advantages. The first is that a mapping table changes very infrequently - only as frequently as sites change their connectivity, network outages are irrelevant, and in any case is very easy and cheap to update (there are no calculations, just entries to install in the table), so the cpu problems we currently have go away. Second, the mapping table, at its very worst, needs be just a simple straight linear array, indexed by /24 network prefixes, and returning a 32 bit IP address. There are only ("only") 2^24 (16M) /24 network prefixes, which means the mapping table has a maximum size of 64Mb. That's too big for current routers, but current routers don't need nearly that big a table (nor would they implement it as a single linear array, until that became the cost-effective way). Cidrd work has shown that the IP address space won't be consumed until sometime after 2010 - that means that the mapping table won't need to be 64Mb till sometime after 2010, at which point 64Mb won't be a noticeable amount of memory (its already just a small handful of SIMS, by 2010 the mem market will probably have stopped making SIMS that small). To implement this scheme we need several things... 1) we need agreement on the addrss range to be used, and the mechanisms involved (this is too simple to really be called a protocol). 2) we need an allocation mechanism for these addresses. That needs to be someone, or something - but we'd probably at least start with a person, with knowledge of the topology, to divide the Internet into areas, and assign them addresses that match the topology reasonably well. That needs to be an ongoing process, to watch for topology changes, and reassign the addresses as needed. This would have all of the properties of the proposed cidr address allocations - cidr blocks and area addresses are basically the same things with different labels. 3) We need a protocol to distribute the mapping table. This could (initially) be done manually (semi-automated), with the various areas sending lists of their connected nets, along with their area address to a central site, which would collect the data, and make it available (via anon ftp if necessary) for the core providers to fetch and load into their border routers (those connected to default-using routers). This would be a horrid way to operate, but it is sufficient to get started, and shows that we don't have to hold up deployment of this scheme waiting for this protocol to be developed, a better, automated, update scheme can come later. 4) We need to have this actually implemented in the border core routers, and deployed by their operators. Implementation will just take pressure upon the router vendors, indicating to them that this is something that the Internet needs. Deployment would be needed by the default free router operators to keep functioning as the net grows, so that should be possible. Routers can be upgraded one by one, they will only use the new scheme for nets in the mapping table, which don't have other routes. While full routing tables remain, that will be never. Once the routers are upgraded, the mapping table can be distributed, and then the areas can start advertising their area addresses, and withdrawing all of their individual net announcements - again, there doesn't need to be any particular co-ordination here, as the old net routes are withdrawn he router will find no specific route, and switch to trying the mapping table instead. Basically that is it - everything else exists already. We already have IP in IP encapsulation (it is used continuously by the mbone, and more), we use the same routing protocols for the new address range that we currently use - there are just less of those addreses. The question now is whether this is a plausible scheme, and if so, should we be working on it? If so, it does need to be done quickly. I'd expect that we have till about the Dallas IETF to get the procedures set in order to be able to get implrementations done, and deployment, before this is really needed. I believe we can hold routing table growth to manageable limits long enough for this. Lastly, in response to Tony, Bob Moskowitz said ... Date: Wed, 23 Aug 1995 06:58:09 -0400 From: Robert Moskowitz Message-Id: <9508231107.AA16492@clncrdv1.is.chrysler.com> Tell him to write a I-D already... which is something that should, eventually be done. This isn't really relevant to the topic at hand, but I have a different concept of I-D's than some IETF people do. There is a practice in some quarters of "think of an idea, write a draft". I don't subscribe to that, I prefer to toss ideas around a little, get more input, before taking that next step. Neither of these is right, and the other wrong, they're just different approaches. kre From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 00:25:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23834; Thu, 24 Aug 1995 00:25:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA01881; Thu, 24 Aug 1995 00:25:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA01808; Thu, 24 Aug 1995 00:16:26 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23373; Thu, 24 Aug 1995 00:16:24 +1000 (from kre@munnari.OZ.AU) To: Yakov Rekhter Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Wed, 23 Aug 1995 07:09:27 PDT." <199508231409.HAA10155@hubbub.cisco.com> Date: Thu, 24 Aug 1995 00:16:02 +1000 Message-Id: <12213.809187362@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Wed, 23 Aug 95 07:09:27 PDT From: Yakov Rekhter Message-ID: <199508231409.HAA10155@hubbub.cisco.com> What are the essential differences between your proposal and IPAE ? Basically, it is a much simpler problem, that has no impact at all on any end user sites, and so avoids many of the complexities. Apart from that, who cares? I did not claim invention of anything new, the question is not what it is similar to, but whether it is workable. kre ps: you really did not need to include my entire (lengthy) message to ask that one line question. You didn't really need to include any of it... From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 00:26:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23864; Thu, 24 Aug 1995 00:26:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA01903; Thu, 24 Aug 1995 00:26:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA01791; Thu, 24 Aug 1995 00:09:41 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23068; Thu, 24 Aug 1995 00:09:31 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id HAA10155; Wed, 23 Aug 1995 07:09:28 -0700 Message-Id: <199508231409.HAA10155@hubbub.cisco.com> To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Wed, 23 Aug 95 23:43:32 +0900." <12192.809185412@munnari.OZ.AU> Date: Wed, 23 Aug 95 07:09:27 PDT From: Yakov Rekhter Precedence: bulk Robert, What are the essential differences between your proposal and IPAE ? Yakov. ------------------------------------------------------------------------- > Date: Tue, 22 Aug 1995 23:54:09 -0700 > From: Tony Li > Message-ID: <199508230654.XAA02426@greatdane.cisco.com> > > Well, what else can we do? > > First, thanks, I think, for waking up this list - at least > it allowed me to find a bunch of dead addresses and get them > deleted... > > Second, as Tony's message may have left some B-I subscribers > confused, he was responding to a (lengthy) message of mine > on the cidrd list (those of you not there probably don't want > to be, but if you do, cidrd-request@iepg.org will get you > added - its a path into majordomo, so send majordomo type > subscribe commands in the body of the request message). > > There the question of whether the current internet draft > draft-ietf-cidrd-ownership-01.txt should be forwarded to the > IESG with a recommendation that it be published as a BCP (see > RFC1818) has been being debated. > > One of the reasons used to support the draft, which calls for > all IP addresses in the future to be leased, rather than > allocated in perpetuity, is that the Internet has no alternative, > it must do this or the routing infrastructure will simply > break. Read the draft for more arguments this way. > > I am not a supporter of the draft, for many reasons, the > most basic of which is that I believe there is a better way. > On the cidrd list, discussion of this alternative has been > ruled out of order - on several grounds - one being that it > is unproven (true, but so is the draft, whatever its > proponents may say), another that cidrd is purely for the > deployment of cidr, and anything which is not that is > irrelevant there (which apparently includes showing that the > proposed solution is not necessary, or attempting to do that). > > Anyway, this discussion has now moved here. > > First, the problem - the Internet default-free routing tables > are growing, and growing rapidly, and will sometime be beyond > the capacities of current routers. Even if the hardware > vendors were willing to do it, essentially everyone recognises > that simply building bigger hardware is not a solution that > can possibly work, even in the relatively short term. > > RFC1519 (CIDR) gave us a solution, at least for a while, to > the address space exhaustion issues that first caused this > list to be started. It also held some hope for the routing > table growth problems - by allowing multiple routes to be > aggregated into one advertisment, both the size of the routing > table, and the size/speed of the processor needed to handle > processing changes to it could be contained. > > Unfortunately, this has not worked as well as hoped, and the > routing tables continue to grow. > > The draft's solution is to attempt to cause the cidr solution > to work better, by forcing most new connections to the Internet > to use numbers that can be aggregated, and in particular to > require those new connections to release their numbers when > they move connection points, and sometimes, even when their > provider changes, and acquire new ones. > > The question of whether even this will be sufficient, or > whether existing connections may need to be required to be > renumbered as well is still open (the draft says that is > outside its scope). > > My solution, which is, incidentally, neither new, nor my > invention, is to first buy some time. I believe we can > accomplish that by being more agressive with requests for > voluntary renumbering (cidrd has been told of some good > success rates this way), and if necessary by a pretty obscure > way of trading (lots of) $'s for extra time by dividing the > routers into clusters of routers. > > During the time we can obtain by this means, we alter the > way routing is done in the defaultless core, so that it is, > in fact, based purely on highly topologically significant > addresses, that can be renumbered as much as desired, but > which are used only within the core (not visible at all, > in any way, at end user sites). > > This allows the routing tables to be kept small, as small as > desired basically (less routing information means less > optimal paths can be constructed, so restricting the information > beyond what is needed would be counter productive). > > The approach is conceptually very simple - when a packet > arrives at a default free router, bearing a standard IP > address, one of three cases holds. Either there is no > route to the destination, and the packet is dropped, or > the destination is at some local connection, routing is > known, and the packet is forwarded locally, or the > destination is somewhere through the core of the internet, > traversing a default-free-router path to some exit point > where the destination is "local". > > It is the last of those cases that is of interest here. > The "renumber" solution attempts to make this manageable > by forcing the upper bits of the address (upper for IPv4 > is probably of the order of 16) to contain enough information > to route the packet to its exit point from the core. > That requires IPv4 addresses as used by end sites to match > the current connection of the site - and consequently, requires > renumbering when that connectivity alters. > > The alternative is to simply map the original destination > IPv4 address into something that is topologically significant, > and route using that address. > > To gain the maximum benefit from existing infrastructure, I > would (doing this now, not ecessarily if we had years to plan > and implement this scheme) make the mapped address be another > IPv4 address, from a range reserved for the purpose, which > could be the 240/4 space, or the 223/8 space, or anything > else (even 10/8, as net 10 is now reserved, ad cannot be a > valid internet destination). The original packet would > then be encapsulated in a new IP packet, bearing the new > address, sent through the core to the exit area, decapsulated, > and then continue being routed using the original destination > address which is now "local". > > There are unquestioned drawbacks to this approach - the first > is that the routers at the entry and exit points will have more > work to do than they now do (probably) and so will probably not > be able to route as many packets per second as they could before. > That may mean that some routers in this situation (ones nearly > at capacity already) might need to be either upgraded, or > split into two, each handling a part of the previous load. > Note that this cost scales with the amount of traffic handled > by the router, not with any external consideration, and so is > manageable. Also, note that the cost of processing routing > updates will decrease, which may even offset this cost (until > it is actually measured we can only speculate). > > Second, users (which for this means end site network managers, > real users don't care about this) would now see the internet > core as a one hop black box, with no idea of the workings of > that box, or what is happening inside - in this respect it would > be like the old ARPANET (which could justify using 10/8). > Traceroutes would show the packet enter the core, and then > exit again, with no evidence of the path followed. > > There are probably more, which it would be useful to enumerate. > > The result of this change would be to trade a growing routing > table for a growing mapping table, which at first glance doesn't > seem like such a big win, however it has in fact two major > advantages. The first is that a mapping table changes very > infrequently - only as frequently as sites change their > connectivity, network outages are irrelevant, and in any case > is very easy and cheap to update (there are no calculations, > just entries to install in the table), so the cpu problems > we currently have go away. Second, the mapping table, at its > very worst, needs be just a simple straight linear array, > indexed by /24 network prefixes, and returning a 32 bit IP > address. There are only ("only") 2^24 (16M) /24 network > prefixes, which means the mapping table has a maximum size of > 64Mb. That's too big for current routers, but current routers > don't need nearly that big a table (nor would they implement it > as a single linear array, until that became the cost-effective > way). Cidrd work has shown that the IP address space won't > be consumed until sometime after 2010 - that means that the > mapping table won't need to be 64Mb till sometime after 2010, > at which point 64Mb won't be a noticeable amount of memory > (its already just a small handful of SIMS, by 2010 the mem > market will probably have stopped making SIMS that small). > > To implement this scheme we need several things... > > 1) we need agreement on the addrss range to be used, and > the mechanisms involved (this is too simple to really be > called a protocol). > > 2) we need an allocation mechanism for these addresses. > That needs to be someone, or something - but we'd probably > at least start with a person, with knowledge of the topology, > to divide the Internet into areas, and assign them addresses > that match the topology reasonably well. That needs to be > an ongoing process, to watch for topology changes, and reassign > the addresses as needed. This would have all of the properties > of the proposed cidr address allocations - cidr blocks and > area addresses are basically the same things with different > labels. > > 3) We need a protocol to distribute the mapping table. > This could (initially) be done manually (semi-automated), > with the various areas sending lists of their connected nets, > along with their area address to a central site, which would > collect the data, and make it available (via anon ftp if > necessary) for the core providers to fetch and load into their > border routers (those connected to default-using routers). > This would be a horrid way to operate, but it is sufficient to > get started, and shows that we don't have to hold up deployment > of this scheme waiting for this protocol to be developed, a > better, automated, update scheme can come later. > > 4) We need to have this actually implemented in the border > core routers, and deployed by their operators. Implementation > will just take pressure upon the router vendors, indicating to > them that this is something that the Internet needs. Deployment > would be needed by the default free router operators to keep > functioning as the net grows, so that should be possible. > Routers can be upgraded one by one, they will only use the > new scheme for nets in the mapping table, which don't have other > routes. While full routing tables remain, that will be never. > Once the routers are upgraded, the mapping table can be > distributed, and then the areas can start advertising their > area addresses, and withdrawing all of their individual net > announcements - again, there doesn't need to be any particular > co-ordination here, as the old net routes are withdrawn he > router will find no specific route, and switch to trying the > mapping table instead. > > Basically that is it - everything else exists already. > We already have IP in IP encapsulation (it is used continuously > by the mbone, and more), we use the same routing protocols > for the new address range that we currently use - there are just > less of those addreses. > > The question now is whether this is a plausible scheme, and > if so, should we be working on it? If so, it does need to > be done quickly. I'd expect that we have till about the > Dallas IETF to get the procedures set in order to be able to > get implrementations done, and deployment, before this is > really needed. I believe we can hold routing table growth to > manageable limits long enough for this. > > Lastly, in response to Tony, Bob Moskowitz said ... > > Date: Wed, 23 Aug 1995 06:58:09 -0400 > From: Robert Moskowitz > Message-Id: <9508231107.AA16492@clncrdv1.is.chrysler.com> > > Tell him to write a I-D already... > > which is something that should, eventually be done. This > isn't really relevant to the topic at hand, but I have a > different concept of I-D's than some IETF people do. There > is a practice in some quarters of "think of an idea, write a > draft". I don't subscribe to that, I prefer to toss ideas > around a little, get more input, before taking that next step. > Neither of these is right, and the other wrong, they're just > different approaches. > > kre From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 01:05:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25258; Thu, 24 Aug 1995 01:05:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA01994; Thu, 24 Aug 1995 01:05:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA01980; Thu, 24 Aug 1995 01:00:24 +1000 Received: from news.ti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25147; Thu, 24 Aug 1995 01:00:16 +1000 (from w-rolph@ds.mc.ti.com) Received: from ganesh.mc.ti.com ([157.87.4.175]) by gate.ti.com (8.6.12/) with SMTP id KAA11400; Wed, 23 Aug 1995 10:00:11 -0500 Received: by ganesh.mc.ti.com; id AA23373; Wed, 23 Aug 1995 10:59:39 -0400 Message-Id: <9508231459.AA23373@ganesh.mc.ti.com> X-Sender: a722756@mail-ad.mc.ti.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Aug 1995 10:59:39 -0400 To: Robert Elz , Tony Li From: "W. Donald Rolph III" Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk Robert, this is the first time I have heard a coherent suggestion on this problem. The concept of a complex router at entry point to the internet is the only class of solution which can be reasonably deployed in the near (3-5 year) term. Nicely writen, I trust that it will be reviewed on its technical merits! >My solution, which is, incidentally, neither new, nor my >invention, is to first buy some time. I believe we can >accomplish that by being more agressive with requests for >voluntary renumbering (cidrd has been told of some good >success rates this way), and if necessary by a pretty obscure >way of trading (lots of) $'s for extra time by dividing the >routers into clusters of routers. > >The approach is conceptually very simple - when a packet >arrives at a default free router, bearing a standard IP >address, one of three cases holds. Either there is no >route to the destination, and the packet is dropped, or >the destination is at some local connection, routing is >known, and the packet is forwarded locally, or the >destination is somewhere through the core of the internet, >traversing a default-free-router path to some exit point >where the destination is "local". > Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-236-1263 From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 02:25:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28816; Thu, 24 Aug 1995 02:25:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA02132; Thu, 24 Aug 1995 02:25:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02106; Thu, 24 Aug 1995 02:09:05 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27913; Thu, 24 Aug 1995 02:08:21 +1000 (from brian@dxcoms.cern.ch) Received: from dxmint.cern.ch by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA21973 Thu, 24 Aug 1995 02:08:06 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch id AA17402; Wed, 23 Aug 1995 18:05:15 +0200 Received: by dxcoms.cern.ch id AA11729; Wed, 23 Aug 1995 18:05:13 +0200 Message-Id: <9508231605.AA11729@dxcoms.cern.ch> Subject: Re: ownership, leasing, renumbering, and that draft To: kre@munnari.OZ.AU (Robert Elz) Date: Wed, 23 Aug 1995 18:05:12 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <12192.809185412@munnari.OZ.AU> from "Robert Elz" at Aug 23, 95 11:43:32 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 231 Precedence: bulk Robert, If understand it you are proposing IP-in-IP tunnelling, initially with manual management of the tunnels. How many tunnels will have to be created per day per gateway router? What MTU size are you recommending? Brian From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 03:05:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00577; Thu, 24 Aug 1995 03:05:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02183; Thu, 24 Aug 1995 03:05:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02177; Thu, 24 Aug 1995 02:58:55 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB00397; Thu, 24 Aug 1995 02:58:50 +1000 (from kre@munnari.OZ.AU) To: "Brian Carpenter CERN-CN" Cc: tli@cisco.com, big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Wed, 23 Aug 1995 18:05:12 +0200." <9508231605.AA11729@dxcoms.cern.ch> Date: Thu, 24 Aug 1995 02:58:27 +1000 Message-Id: <12307.809197107@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Wed, 23 Aug 1995 18:05:12 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Message-ID: <9508231605.AA11729@dxcoms.cern.ch> If understand it you are proposing IP-in-IP tunnelling, initially with manual management of the tunnels. Yes, or rather, kind of, but not with the connotations that "tunnel" usually implies. That is, there is no fixed (that is, configured) end to end management going on here. How many tunnels will have to be created per day per gateway router? Depending on how you count this, either zero, or one per packet transmitted through the core. If you're counting the latter way though the act of "creating a tunnel" is precisely the same act as encapsulating the packet and transmitting it. What MTU size are you recommending? Ah yes, thanks - that I had considered before, but forgot to mention it. It is relevant. The MTU will be (probably) smaller than it currently is, by 20 bytes (one IP header). It will also probably be necessary to agree on advance for a standard MTU for this virtual sub-net, so packets too large can be fragmented at entry, before encapsulation, and not need to be fragmented inside the cloud (which would require reassembly at the exit point, which is probably not possible, as there is no guarantee that the exit point is one unique host/router). A number for this I wouldn't like to say now, it basically needs to be the smallest current MTU of the core links, less 20, or perhaps, what that number will be at the time the scheme is adopted (assuming it is). kre From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 04:05:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02842; Thu, 24 Aug 1995 04:05:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA02256; Thu, 24 Aug 1995 04:05:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02249; Thu, 24 Aug 1995 03:57:17 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02456; Thu, 24 Aug 1995 03:57:08 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.59] (dial-cup2-11.iway.aimnet.com [204.118.88.41]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA22414; Wed, 23 Aug 1995 10:56:39 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Aug 1995 10:57:02 -0700 To: Robert Elz From: Dave Crocker Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk At 9:58 AM 8/23/95, Robert Elz wrote: >by 20 bytes (one IP header). It will also probably be >necessary to agree on advance for a standard MTU for this >virtual sub-net, so packets too large can be fragmented I was thinking about this yesterday. It was a focus in the original IPAE discussions. A strange thought occurred to me: what are the forcing functions for the CURRENT mtu? Is there any room to maneuver for INCREASING the "backbone" mtu to cover the extra envelope size? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 05:26:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06008; Thu, 24 Aug 1995 05:26:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA02387; Thu, 24 Aug 1995 05:25:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02357; Thu, 24 Aug 1995 05:08:00 +1000 Received: from foobar.Ipsilon.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05295; Thu, 24 Aug 1995 05:07:55 +1000 (from hinden@ipsilon.com) Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id MAA25530; Wed, 23 Aug 1995 12:07:19 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Aug 1995 12:10:08 -0700 To: Robert Elz From: hinden@Ipsilon.COM (Bob Hinden) Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk KRE, > What are the essential differences between your proposal and IPAE ? > >Basically, it is a much simpler problem, that has no impact >at all on any end user sites, and so avoids many of the >complexities. I think you have reinvented the IP Encaps proposal I made to the ROAD group way back when. If I can find a copy, I will send it to you. Given that I liked it then, I do like your proposal. I also agree that the main issue is to see if it is a workable solution. Bob From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 05:46:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06827; Thu, 24 Aug 1995 05:46:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA02430; Thu, 24 Aug 1995 05:45:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02410; Thu, 24 Aug 1995 05:32:31 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06336; Thu, 24 Aug 1995 05:32:15 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id MAA06762; Wed, 23 Aug 1995 12:31:40 -0700 Message-Id: <199508231931.MAA06762@hubbub.cisco.com> To: hinden@ipsilon.com (Bob Hinden) Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Wed, 23 Aug 95 12:10:08 PDT." Date: Wed, 23 Aug 95 12:31:40 PDT From: Yakov Rekhter Precedence: bulk Bob, > KRE, > > > What are the essential differences between your proposal and IPAE ? > > > >Basically, it is a much simpler problem, that has no impact > >at all on any end user sites, and so avoids many of the > >complexities. > > I think you have reinvented the IP Encaps proposal I made to the ROAD group > way back when. If I can find a copy, I will send it to you. It would also help if you'll send to Robert the list of issues that have been raised with IPAE. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 05:47:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06846; Thu, 24 Aug 1995 05:47:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA02450; Thu, 24 Aug 1995 05:46:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02401; Thu, 24 Aug 1995 05:27:07 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06109; Thu, 24 Aug 1995 05:26:50 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.59] (dial-cup2-21.iway.aimnet.com [204.118.88.51]) by aimnet.com (8.6.12/8.6.12) with SMTP id MAA00180; Wed, 23 Aug 1995 12:26:02 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Aug 1995 12:26:27 -0700 To: IAP@VMA.CC.ND.EDU, IETF@cnri.reston.va.us, nanog@MERIT.EDU, inet-access@earth.com, Big-Internet@munnari.OZ.AU, cidrd@iepg.org From: Dave Crocker Subject: Comments on draft-ietf-cidrd-ownership-01.txt Cc: IAP@VMA.CC.ND.EDU, IETF@cnri.reston.va.us, nanog@MERIT.EDU, inet-access@earth.com Precedence: bulk Folks, Last week I sent detailed comments on the "Ownership" I-D to the cidrd mailing list. Scott Bradner (Ops AD) asked me to submit the comments that I wrote as an I-D for wider dissemination. I added an introduction (summary) and an ending (recommendations) around the original comments on the Ownership (leasing) proposal. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the CIDR Deployment Working Group >of the IETF. > > Title : The Myth of Topological Hierarchy: Comments on > > Author(s) : D. Crocker > Filename : draft-ietf-cidrd-myth-00.txt > Pages : 4 > Date : 08/22/1995 > >This note offers comments on the technical and operational aspects of the >proposal for large-scale use of "address leasing" recommended in "On the >Implications of Address Ownership for Internet Routing", I-D >, by Rekhter & Li. The draft has been >produced within the cidrd working group and is intended for publication as >a Best Current Practices official IETF document. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-cidrd-myth-00.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-cidrd-myth-00.txt -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 05:48:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07082; Thu, 24 Aug 1995 05:48:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA02474; Thu, 24 Aug 1995 05:48:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02424; Thu, 24 Aug 1995 05:45:15 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06809; Thu, 24 Aug 1995 05:45:12 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzebm29492; Wed, 23 Aug 1995 15:44:46 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Comments on draft-ietf-cidrd-ownership-01.txt To: dcrocker@brandenburg.com (Dave Crocker) Date: Wed, 23 Aug 1995 15:44:46 -0400 (EDT) Cc: IAP@VMA.CC.ND.EDU, IETF@cnri.reston.va.us, nanog@MERIT.EDU, inet-access@earth.com, Big-Internet@munnari.OZ.AU, cidrd@iepg.org In-Reply-To: from "Dave Crocker" at Aug 23, 95 12:26:27 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 2352 Precedence: bulk > Last week I sent detailed comments on the "Ownership" I-D to the > cidrd mailing list. Scott Bradner (Ops AD) asked me to submit the comments > that I wrote as an I-D for wider dissemination. I added an introduction > (summary) and an ending (recommendations) around the original comments on > the Ownership (leasing) proposal. Comments on some of the parts of your draft: The document goes on to describe the nature and benefits of hierarchical addressing. It then, incorrectly, asserts that the Internet topology reflects a hierarchy and that addresses must be kept aligned with the hierarchy. This requirement is used to assert the need for enforcing addressing changes when (some) topological changes take place. The document makes no effort to deal with the very real difficulties this model creates for multi-homed organizations, including local service providers. Working group discussions have left the issue with citations to the original CIDR document, but it offers no real guidance either, since it largely presumes the NSFNet as the top of the Internet's topology. While the document may be lacking in various areas, it does not presume that the NSFNet is the top of Internet's topology. All of us that have been working on this draft have been intimately involved w/ the shutdown of the NSFNET. We know its gone. There is a loose hierarchy in the internet today - its made up of a partially meshed interconnection of several hundred ASs - not of an arbitrary mesh of a few 100,000s of organizations. [Note that a multihomed site (and there are few few of these today) are some of these ASs - they are a distinct piece of the hierarchy.] If we could reduce the routing entries to one (or a few) routes per AS, then we would have a major major win. (Yes, I did say experimental. Contrary to the comments on the cidrd mailing list there has been no large scale use of a leasing policy Several internet services providers are doing just this - PSI (for instance) charges differently for leased address space and has done so for a while now. AlterNet has always requested new customers to renumber into our space and for leaving customers to return address space; we actually have quite a good complience with this. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 07:05:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09930; Thu, 24 Aug 1995 07:05:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA02558; Thu, 24 Aug 1995 07:05:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA02541; Thu, 24 Aug 1995 06:52:03 +1000 Received: from foobar.Ipsilon.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09433; Thu, 24 Aug 1995 06:51:56 +1000 (from hinden@ipsilon.com) Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id NAA27066; Wed, 23 Aug 1995 13:51:20 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Aug 1995 13:54:09 -0700 To: Yakov Rekhter From: hinden@Ipsilon.COM (Bob Hinden) Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk Yakov, >It would also help if you'll send to Robert the list of issues that >have been raised with IPAE. I don't have any list of issues that were raised w/ IPAE and KRE's proposal is more like IP Encaps. IPAE had a different set of goals. Bob From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 08:05:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11974; Thu, 24 Aug 1995 08:05:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA02630; Thu, 24 Aug 1995 08:05:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA02613; Thu, 24 Aug 1995 07:48:09 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11354; Thu, 24 Aug 1995 07:48:05 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id OAA17729; Wed, 23 Aug 1995 14:48:01 -0700 Message-Id: <199508232148.OAA17729@hubbub.cisco.com> To: Robert Elz Cc: big-internet@munnari.OZ.AU, yakov@cisco.com Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Wed, 23 Aug 95 23:43:32 +0900." <12192.809185412@munnari.OZ.AU> Date: Wed, 23 Aug 95 14:48:00 PDT From: Yakov Rekhter Precedence: bulk Robert, One question about your proposal. Consider the following picture: ----------------------- ( ) /(R1 "core" R2)\ / ( ) \ S1-- P1 -----------------------) P2---S2 \ / \ / ------------------------- "private link" Routers R1 and R2 are part of the "core". There are two sites, S1, and S2. S1 is attached to provider P1, S2 is attached to provider P2. Neither P1, nor P2 are part of the "core", but both P1 and P2 are connected to the core. Also P1 and P2 have a private link. Under stable conditions routers in P1 are configured to prefer path through the "core" over the path through the private link. Now consider a host H1 in S1 that sends a packet to a host H2 in S2. A router X (not shown in the figure) in P1 forwards the packet to R1. R1 performs a lookup in its mapping table, and finds that it should send the packet to R2 (since path through the "core" is the preferred one). So, R1 encapsulates the packet and sends it to R2. But now assume that the path between R2 to P2 is broken. What mechanism will be used to notify the router X in P1 that the path through the "core" is no longer available, and that the router has to switch to the path via the "private link" ? Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 09:45:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17528; Thu, 24 Aug 1995 09:45:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02742; Thu, 24 Aug 1995 09:45:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02725; Thu, 24 Aug 1995 09:36:56 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17075; Thu, 24 Aug 1995 09:36:28 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.48] (dial-cup2-18.iway.aimnet.com [204.118.88.48]) by aimnet.com (8.6.12/8.6.12) with SMTP id QAA20606; Wed, 23 Aug 1995 16:35:50 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Aug 1995 16:36:11 -0700 To: hinden@ipsilon.com (Bob Hinden) From: Dave Crocker Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk At 1:54 PM 8/23/95, Bob Hinden wrote: >is more like IP Encaps. IPAE had a different set of goals. right. I fell into using IPAE as the citation due to some other references. IPAE wrapped IPv4 headers around a NEW addressing scheme. I.e., something like IPv6 addresses (full, global uniqueness) would be inside the backbone-routed layer. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 09:47:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17596; Thu, 24 Aug 1995 09:47:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02764; Thu, 24 Aug 1995 09:46:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02722; Thu, 24 Aug 1995 09:36:47 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17061; Thu, 24 Aug 1995 09:35:56 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.48] (dial-cup2-18.iway.aimnet.com [204.118.88.48]) by aimnet.com (8.6.12/8.6.12) with SMTP id QAA20564; Wed, 23 Aug 1995 16:35:26 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Aug 1995 16:35:48 -0700 To: Yakov Rekhter From: Dave Crocker Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk At 2:48 PM 8/23/95, Yakov Rekhter wrote: >What mechanism will be used to notify the router X in P1 that the path >through the "core" is no longer available, and that the router >has to switch to the path via the "private link" ? Yakov, isn't the scenario you describe very much the same as exists today for folks who are attached to the general Internet and use default routing to get to the core, but have private links? How do THEY discover that they should use the private link instead of the core? In other words, how would life NEED to be different for P1 in an encaps scheme versus real life today? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 10:05:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18527; Thu, 24 Aug 1995 10:05:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA02801; Thu, 24 Aug 1995 10:05:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA02795; Thu, 24 Aug 1995 10:03:58 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18332; Thu, 24 Aug 1995 10:03:51 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id RAA29770; Wed, 23 Aug 1995 17:03:17 -0700 Message-Id: <199508240003.RAA29770@hubbub.cisco.com> To: Dave Crocker Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Wed, 23 Aug 95 16:35:48 PDT." Date: Wed, 23 Aug 95 17:03:17 PDT From: Yakov Rekhter Precedence: bulk Dave, > Yakov, isn't the scenario you describe very much the same as exists > today for folks who are attached to the general Internet and use default > routing to get to the core, but have private links? How do THEY discover > that they should use the private link instead of the core? In addition to pointing default, providers can also acquire (via *dynamic* routing protocols) information about specific destinations. In the example I sent before, P1 would acquire and maintain (probably via BGP) routing information for both paths. As one path would go down, dynamic routing would indicated this to P1, so P1 would switch to another route. Note that in the encaps scheme the "core" *does not* propagate any routing information outside of the core. No routing information transits the core. That makes the encaps model quite different form the current Internet. Yakov. P.S. By the way, there is no such thing as "the core" in "the general Internet". From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 11:06:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21326; Thu, 24 Aug 1995 11:06:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA02873; Thu, 24 Aug 1995 11:05:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA02856; Thu, 24 Aug 1995 10:47:17 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20435; Thu, 24 Aug 1995 10:46:51 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.48] (dial-cup2-14.iway.aimnet.com [204.118.88.44]) by aimnet.com (8.6.12/8.6.12) with SMTP id RAA28124; Wed, 23 Aug 1995 17:46:21 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Aug 1995 17:46:43 -0700 To: Yakov Rekhter From: Dave Crocker Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk Yakov, At 5:03 PM 8/23/95, Yakov Rekhter wrote: >In addition to pointing default, providers can also acquire (via >*dynamic* routing protocols) information about specific destinations. >In the example I sent before, P1 would acquire and maintain (probably >via BGP) routing information for both paths. As one path would go down, In other words, P1 is doing non-default routing to the current provider-based cloud today? Why can it not continue to do that with Encaps being used within that cloud? Encaps isn't intended to prevent acquiring information, merely to eliminate the requirement for acquiring all of it. >Note that in the encaps scheme the "core" *does not* propagate any >routing information outside of the core. No routing information Doesn't have to, but can. That's the choice of the interfacing provider and the customer... >P.S. By the way, there is no such thing as "the core" in "the general >Internet". agree. completely. I've tried some alternate language, above. My previous usage was merely trying to keep in line with common practise. The quicker we get away from use of the term core the better. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 11:47:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23405; Thu, 24 Aug 1995 11:47:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA02933; Thu, 24 Aug 1995 11:45:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA02916; Thu, 24 Aug 1995 11:28:05 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22422; Thu, 24 Aug 1995 11:27:58 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id SAA06051; Wed, 23 Aug 1995 18:27:12 -0700 Message-Id: <199508240127.SAA06051@hubbub.cisco.com> To: Dave Crocker Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Wed, 23 Aug 95 17:46:43 PDT." Date: Wed, 23 Aug 95 18:27:12 PDT From: Yakov Rekhter Precedence: bulk Dave, > >Note that in the encaps scheme the "core" *does not* propagate any > >routing information outside of the core. No routing information > > Doesn't have to, but can. If it can, then someone has to describe how, and also estimate the impact of such propagation on the reduction of the routing overhead provided by the encaps scheme. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 12:08:39 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24377; Thu, 24 Aug 1995 12:08:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA02972; Thu, 24 Aug 1995 12:05:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA02953; Thu, 24 Aug 1995 11:51:35 +1000 From: bound@zk3.dec.com Received: from mail1.digital.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23551; Thu, 24 Aug 1995 11:50:53 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA19780; Wed, 23 Aug 1995 18:37:17 -0700 Received: by xirtlu.zk3.dec.com; id AA01061; Wed, 23 Aug 1995 21:37:16 -0400 Message-Id: <9508240137.AA01061@xirtlu.zk3.dec.com> To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Wed, 23 Aug 95 23:43:32 +1000." <12192.809185412@munnari.OZ.AU> Date: Wed, 23 Aug 95 21:37:10 -0400 X-Mts: smtp Precedence: bulk Robert, >There the question of whether the current internet draft >draft-ietf-cidrd-ownership-01.txt should be forwarded to the >IESG with a recommendation that it be published as a BCP (see >RFC1818) has been being debated. Where is this being debated? The entire concept needs review and we need to be careful here as we are a technical community to create stds not a management committee for the Internet. I have brought this up on POISED too as an item for discussion. >One of the reasons used to support the draft, which calls for >all IP addresses in the future to be leased, rather than >allocated in perpetuity, is that the Internet has no alternative, >it must do this or the routing infrastructure will simply >break. Read the draft for more arguments this way. In draft-ietf-cidrd-myth-00.txt its stated that the strategy though not stated is to require the reclamation of IPv4 address space. If this is the case that is WRONG, and should be kaboshed right now as any kind of policy thought. I also think leasing addresses is bogus and don't like it at all. Not a good solution. >I am not a supporter of the draft, for many reasons, the >most basic of which is that I believe there is a better way. >On the cidrd list, discussion of this alternative has been >ruled out of order - on several grounds - one being that it >is unproven (true, but so is the draft, whatever its >proponents may say), another that cidrd is purely for the >deployment of cidr, and anything which is not that is >irrelevant there (which apparently includes showing that the >proposed solution is not necessary, or attempting to do that). Sounds like you should use the documented RFC 1602 appeals process if this is happening in the WG. This is not good and does not appear to be using "fair practices" in pursuing this standards work. That is grounds for an appeal to WG Chair, then IESG, then IAB, and then ISOC Board possibly. Bottom line is I think your idea now being discussed technically is a sound idea to check out, before we run out and create policy for addresses and leasing. I also fear that with draft-ietf-cidrd-ownership-01 and RFC 1818 (BCP) we could end up trying to build an entity or elevate an existing entity to mandate addresses be returned or something worse. Lets watch carefully for the chicken little syndrome of CIDR and what we really need to do here prior to getting to IPv6. I also think we can deploy IPv6 by 1998 so at most all we need to do is make it survive for 5 years (or until the year 2000). I prefer we solve this problem technically until we can get IPv6 deployed on the Internet. We don't need leasing for IPv6 just proper addressing architecture and deployment. Good job on the counter technical proposal we all owe you for that. This is the best way to avoid the "ownership" proposal. Also IPAE will work. /jim From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 12:27:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25532; Thu, 24 Aug 1995 12:27:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA03020; Thu, 24 Aug 1995 12:25:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA02967; Thu, 24 Aug 1995 12:00:53 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24017; Thu, 24 Aug 1995 11:58:43 +1000 (from deering@parc.xerox.com) Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14726(1)>; Wed, 23 Aug 1995 18:58:08 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 23 Aug 1995 18:58:00 -0700 To: Yakov Rekhter Cc: Dave Crocker , big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: yakov's message of Wed, 23 Aug 95 17:03:17 -0800. <199508240003.RAA29770@hubbub.cisco.com> Date: Wed, 23 Aug 1995 18:57:59 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Aug23.185800pdt.75270@digit.parc.xerox.com> Precedence: bulk Yakov, > P.S. By the way, there is no such thing as "the core" in "the general > Internet". I think the thing being referred to as "the core" is the connected graph of default-free routers. It spans multiple ISPs and IXs. Are you saying that such a thing does not exist, or are you simply objecting to the term "core"? If the latter, how about calling it the DFZ (default-free zone)? Steve From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 13:46:59 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29230; Thu, 24 Aug 1995 13:46:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15421 Thu, 24 Aug 1995 13:29:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA03093; Thu, 24 Aug 1995 13:22:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA03072; Thu, 24 Aug 1995 13:03:20 +1000 Received: from valinor.barrnet.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27099; Thu, 24 Aug 1995 13:03:07 +1000 (from vaf@valinor.barrnet.net) Received: (from vaf@localhost) by valinor.barrnet.net (8.6.8/8.6.6) id UAA03083; Wed, 23 Aug 1995 20:04:31 -0700 Date: Wed, 23 Aug 95 20:04:31 PDT From: Vince Fuller To: Robert Elz Cc: Tony Li , big-internet@munnari.OZ.AU Phone: (415) 528-7227 Usmail: 3801 East Bayshore Rd, Palo Alto, CA, 94303 Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of Wed, 23 Aug 1995 23:43:32 +1000 Message-Id: Precedence: bulk The first question I have about this proposal is: how do you deal with multi- homed sites? Their existance means that the translation from /24 IP addresses to 10.x.x.x "core" addresses is not a simple table lookup. Here's an example: let's say provider X has been assigned the "core" address range 10.X.0.0/16 while provider Y has 10.Y.0.0/16. Network 15.0.0.0/8 is connected to both of these providers. Provider X uses 10.X.0.1/32 to represent 15.0.0.0/8 in the "core" routing table while provider Y uses 10.Y.0.2/32. How does provider Z get from 15.0.0.0/8 to one of these values and which one does he choose? Offhand, it looks to me like the "core" database will have to be more than just a simple index of the /24 part of an IP address into a 2^24 entry array (and yes, I know that's not how it is expected to be implemented initially, but that is the conceptual model you have proposed). It will also have to contain policy information and is also likely not to be global in scope. The key is: my translation for 15.0.0.0 may not be the same as yours. How is this database going to be organized? Remember that the output from it has to be something that can be aggregated or else we're back to flat-routing a "core" address space with up to 2^24 different routing entries. --Vince From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 13:49:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29318; Thu, 24 Aug 1995 13:49:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA03145; Thu, 24 Aug 1995 13:45:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA03128; Thu, 24 Aug 1995 13:38:04 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28675; Thu, 24 Aug 1995 13:37:01 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06093; Wed, 23 Aug 95 22:43:21 -0400 Date: Wed, 23 Aug 95 22:43:21 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508240243.AA06093@ginger.lcs.mit.edu> To: bound@zk3.dec.com, kre@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk From: bound@zk3.dec.com > On the cidrd list, discussion of this alternative has been ruled out of > order ... cidrd is purely for the deployment of cidr, and anything which > is not that is irrelevant there (which apparently includes showing that > the proposed solution is not necessary, or attempting to do that). Sounds like you should use the documented RFC 1602 appeals process if this is happening in the WG. This is not good and does not appear to be using "fair practices" in pursuing this standards work. That is grounds for an appeal to WG Chair, then IESG, then IAB, and then ISOC Board possibly. Gee, Jim, nice to hear you think that. I'm off to the IESG shortly, as soon as I have manufactured the grounds to complain, to protest that discussion about how IPv6 is utter drivel is being ruled out of order on the IPv6 mailing list... Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 13:53:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29543; Thu, 24 Aug 1995 13:53:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA03169; Thu, 24 Aug 1995 13:51:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA03125; Thu, 24 Aug 1995 13:36:35 +1000 From: bound@zk3.dec.com Received: from mail1.digital.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28655; Thu, 24 Aug 1995 13:36:31 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA08721; Wed, 23 Aug 1995 20:29:08 -0700 Received: by xirtlu.zk3.dec.com; id AA02489; Wed, 23 Aug 1995 23:29:07 -0400 Message-Id: <9508240329.AA02489@xirtlu.zk3.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Wed, 23 Aug 95 22:43:21 EDT." <9508240243.AA06093@ginger.lcs.mit.edu> Date: Wed, 23 Aug 95 23:29:00 -0400 X-Mts: smtp Precedence: bulk Noel, >Gee, Jim, nice to hear you think that. I'm off to the IESG shortly, as soon as > have manufactured the grounds to complain, to protest that discussion about >ow IPv6 is utter drivel is being ruled out of order on the IPv6 mailing >list... Go for it. Though I have not seen any contribution from you on IPv6 of late? I did not think you were even on the list? My mistake! Pretty nice folks of late though, once we got past which was the right protocol for the next generation Internet protocol decision in the IETF. Oh and implementations are appearing in the industry at a good rate now. Should even have an IPv6 router and test address space up by Dec 95. Also a couple of root name servers for IP6.INT. But if IPv6 is doing to you what I hear is being done to some on CIDR then by all means appeal, I would. The process is documented in RFC 1602. All IETF members have rights to appeal. If your not happy with the IESG you can also then go to the IAB and even to ISOC Board of Trustees. thanks for the heads up, /jim From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 14:08:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00327; Thu, 24 Aug 1995 14:08:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA03206; Thu, 24 Aug 1995 14:05:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA03200; Thu, 24 Aug 1995 14:00:42 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29745; Thu, 24 Aug 1995 13:59:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06490; Wed, 23 Aug 95 23:58:00 -0400 Date: Wed, 23 Aug 95 23:58:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508240358.AA06490@ginger.lcs.mit.edu> To: kre@munnari.OZ.AU, vaf@valinor.barrnet.net Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, tli@cisco.com Precedence: bulk From: Vince Fuller how do you deal with multi-homed sites? ... Provider X uses 10.X.0.1/32 to represent 15.0.0.0/8 in the "core" routing table while provider Y uses 10.Y.0.2/32. How does provider Z get from 15.0.0.0/8 to one of these values and which one does he choose? ... How is this database going to be organized? Remember that the output from it has to be something that can be aggregated or else we're back to flat-routing a "core" address space with up to 2^24 different routing entries. Why do I have this intense urge to strangle every last single person in the entire IETF? I am so unbelievably sick of going over this stuff again, and again, and again, and again.... Anyway, for once in this debate, I'm going to stop beating up KRE and defend him. :-) The problem here is *not* caused by the mapping step, but by the multi-homing. Even if you map into a new address space which is perfectly topologically organized, you will still have the exact same problem. It's not quite as bad as full flat routing (as you mention above), but for multi-homing to be useful, the destination has to be separately visible over some scope which is larger than either of the two entities which it is connected to. In your example, BTW, 15.0.0.0 would not be mapped to 10.X... or 10.Y, but rather to some other address which is not part of either one, and is separately visible (ie. not aggreagted) over some larger scope. That scope does not have to be global, but exactly how large is is depends on the topology around X and Y. This was discussed in some detail in my note on multi-homing to the CIDRD mailing list, although a full discussion of the ramifications of multi-homing is a N page very technical paper. Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 14:27:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01447; Thu, 24 Aug 1995 14:27:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA03256; Thu, 24 Aug 1995 14:25:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA03239; Thu, 24 Aug 1995 14:21:34 +1000 Received: from valinor.barrnet.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01060; Thu, 24 Aug 1995 14:21:27 +1000 (from vaf@valinor.barrnet.net) Received: (from vaf@localhost) by valinor.barrnet.net (8.6.8/8.6.6) id VAA03284; Wed, 23 Aug 1995 21:22:57 -0700 Date: Wed, 23 Aug 95 21:22:57 PDT From: Vince Fuller To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: kre@munnari.OZ.AU, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, tli@cisco.com Phone: (415) 528-7227 Usmail: 3801 East Bayshore Rd, Palo Alto, CA, 94303 Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of Wed, 23 Aug 95 23:58:00 -0400 Message-Id: Precedence: bulk Why do I have this intense urge to strangle every last single person in the entire IETF? I am so unbelievably sick of going over this stuff again, and again, and again, and again.... Sorry to stress you, Noel. I just wanted confirmation that, as I suspected, multi-homed sites will still need to be flat-routed in KRE's scheme. No big surprise there. Believe it or not, I'm actually NOT knocking KRE's scheme - back when IP Encaps was first proposed, I thought it was a reasonable short-term approach. I'm trying to remember, though, what the faults with it were that caused it to fail and which of them apply to KRE's scheme as well. Essentially, what KRE's scheme does is the same as what IP Encaps did - it separates the IPv4 address space into a set of inter-AS addresses (the "core addresses") and things that look sort of like endpoint identifiers, except that they have local routing significance (where "local" = the bordering non-"core" network that originated the route). What it doesn't do, which Encaps tried to do, is eliminate the restriction that IPv4 addresses remain global. This gets around some of Encaps' problems having to do with IP address use upper-layer protocols (FTP "port" command, etc.) and ICMP semantics (I think). Does anyone have a summary of the reasons why IP Encaps was determined to be unimplementable? I'd be interested to see which of these apply to KRE's scheme (maybe we should call it Simple IP Encaps, or seomthing like that). --Vince From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 15:06:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03167; Thu, 24 Aug 1995 15:06:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA03308; Thu, 24 Aug 1995 15:05:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA03304; Thu, 24 Aug 1995 15:04:14 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02925; Thu, 24 Aug 1995 15:03:29 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.47] (dial-cup2-17.iway.aimnet.com [204.118.88.47]) by aimnet.com (8.6.12/8.6.12) with SMTP id WAA20230; Wed, 23 Aug 1995 22:00:33 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Aug 1995 22:00:56 -0700 To: Vince Fuller From: Dave Crocker Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk At 8:04 PM 8/23/95, Vince Fuller wrote: >while provider Y has 10.Y.0.0/16. Network 15.0.0.0/8 is connected to both of >these providers. Provider X uses 10.X.0.1/32 to represent 15.0.0.0/8 in the Umm, Robert... did you intend to have user addresses mapped to short-term unique "cloud" addresses? My own model has been very much like we use for ANY underlying network layer, like X.25, so that multiple IP addresses are mapped to one "next hop" network address. When we send an IP datagram to a remote location, the next hop is a router. We keep the final destination address in the IP datagram but put the address of the next hop (the router) in the lower-layer envelope. This is a standard model. Why should we do anything differently when using an Encaps scheme to make the public cloud be one large subnet. (Hinden used the phrase to me recently; don't know if others have suggested it.) d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 15:08:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03237; Thu, 24 Aug 1995 15:08:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA03332; Thu, 24 Aug 1995 15:07:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA03301; Thu, 24 Aug 1995 14:59:44 +1000 Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02669; Thu, 24 Aug 1995 14:58:01 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA21022; Thu, 24 Aug 95 00:56:36 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9508240456.AA21022@wizard.gsfc.nasa.gov> Subject: Re: ownership, leasing, renumbering, and that draft To: yakov@cisco.com (Yakov Rekhter) Date: Thu, 24 Aug 1995 00:56:36 -0400 (EDT) Cc: kre@munnari.OZ.AU, big-internet@munnari.OZ.AU, dcrocker@brandenburg.com In-Reply-To: <199508232148.OAA17729@hubbub.cisco.com> from "Yakov Rekhter" at Aug 23, 95 02:48:00 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 8175 Precedence: bulk > Robert, > > One question about your proposal. > > Consider the following picture: > > ----------------------- > ( ) > /(R1 "core" R2)\ > / ( ) \ > S1-- P1 -----------------------) P2---S2 > \ / > \ / > ------------------------- > "private link" > > Routers R1 and R2 are part of the "core". There are two sites, S1, and S2. > S1 is attached to provider P1, S2 is attached to provider P2. Neither P1, nor P2 > are part of the "core", but both P1 and P2 are connected to the core. > Also P1 and P2 have a private link. > > Under stable conditions routers in P1 are configured to prefer path > through the "core" over the path through the private link. > > Now consider a host H1 in S1 that sends a packet to a host H2 in S2. A > router X (not shown in the figure) in P1 forwards the packet to R1. R1 > performs a lookup in its mapping table, and finds that it should send > the packet to R2 (since path through the "core" is the preferred one). > So, R1 encapsulates the packet and sends it to R2. But now assume that > the path between R2 to P2 is broken. > > What mechanism will be used to notify the router X in P1 that the path > through the "core" is no longer available, and that the router > has to switch to the path via the "private link" ? > > Yakov. Yakov, You can have similar problems with hierarchical addressing and routing. Say R1 and R2 are higher layer providers with prefixes of R1/m and R2/m, and P1 and P2 are lower layer providers contained within the addressing spaces of R1 and R2 respectively, with prefixes of P1-R1/n and P2-R2/n, where n > m. Then it may well be that the only routes exchanged over the "core" between R1 and R2 are the aggregated prefixes R1/m and R2/m. Then, R1-P1 would have 2 paths to R2-P2, one via R1 and the "core" to the aggregated region R2/m, and the more specific path to R2-P2/n via the direct "private link" to P2. The normal case would be to prefer the more specific "private" path with a fallback to the "core" path. However, you wanted to consider the case where the "core" was the preferred route and the "private link" was only used as a backup. In that case, R1 and hence P1 would have active routes to the region R2/m as long as the link between R1 and R2 was up, with no specific knowledge of the state of the link between R2 and P2. P1 would thus forward packets to R1 which would send them via the "core" to R2. If the link between R2 and P2 happened to be down, the packets would effectively go into a black hole at that point. The "private link" would only be used as a backup path in this case if the "core" path between R1 and R2 failed for some reason. This is just a fundamental facet of hierarchical addressing and route aggregation, namely the loss of more specific routing information when performing the route aggregation. Now let's suppose that P1 and P2 are atomic routing entities, with prefixes of P1/n and P2/n respectively, i.e. their prefixes are carried "as is" through the "core" without any further route aggregation (this basically assumes that they are at the highest level of the hierarchical addressing). Then, P1 would once again have 2 paths to P2, one via R1 and the "core" to the provider P2/n, and the direct path to P2/n via their "private link". Since both paths have the same granularity of routing information, i.e. P2/n, it would be possible to automatically fallback from the "core" path to the "private" path in the case of a failure in the link between R2 and P2 (or more generally a failure anywhere in the path P1-R1-R2-P2). However, the exact same mechanisms could still be employed when using route mapping to handle "exception" cases of sites that didn't fall within the "natural" address space of their provider. Consider the following case where a site S3 in region R2 has switched providers from P3 to P2: ----------------------- ( ) /(R1 "core" R2)\ / ( ) \ S1-- P1 -----------------------) P2-----S2 = P2-S2/o \ / \ \ / \ ------------------------- ---S3 = P3-S3/o "private link" I think this scenario is the crux of the matter. P1 and P2 have prefixes P1/n and P2/n respectively, while S1, S2, and S3 have prefixes P1-S1/o, P2-S2/o, and P3-S3/o, where o > n. Specifically, the address space for site S3, namely P3-S3/o, does not fall within the address space for provider P2, which is P2/n. This means that provider P2 cannot aggregate the route for S3 within the route for its own address space. Now, in the mapping scheme, all that is required is to install in P1, R1, and R2 the following mapping: P3-S3/o via P2/n If P1-S1 wants to send to P3-S3, the packet will be forwarded normally to P1 (via the default route). P1 will notice the existence of the mapping for P3-S3/o via P2/n. It will then detect that there are 2 paths for P2/n, the "core" path of R1-R2-P2, and the direct path via the "private link". If the "core" path is preferred and is up, then it will be used. If the "core" path failed for any reason, there would be an automatic fallback to the direct, "private" path. P1 would use IP-in-IP encapsulation to transmit the packet to P2. The source IP address would be the IP address of the interface on P1 on which the packet is to be transmitted and the destination IP address would be the IP address of the region P2/n. One possible way to represent this would be as P2-0-n, where n would be encoded in the low order 5 bits of the IP address (this means this technique could not be used to handle subnets with a prefix length greater than 27 but I don't consider that a significant drawback). Another possible method would be to use a modified version of the IP-in-IP encapsulation and put P2-0 as the destination IP address with the prefix length n simply placed in a 4-byte field (to maintain alignment) immediately following the modified IP-in-IP IP header. Normal IP routing would be used to forward the packet to P2. P2 would recognize an IP-in-IP packet addressed to itself, i.e. that it was a border router for the region P2/n (there could be several for redundancy purposes). It would decapsulate the packet and extract the original destination IP address P3-S3-x, notice that it had a route for the region P3-S3/o, and use normal IP routing to forward the decapsulated packet toward its ultimate destination. Having said all that, I will now reiterate my personal preference for geographic based addressing which I feel has better overall properties than either a provider based scheme or a mapping/encapsulation scheme. The major drawback I see to the provider based scheme is that it is still very difficult to do renumbering on any significant scale with current protocols and tools. In my opinion, this would require a tight integration of DNS and DHCP functionality, a reworking of DNS to decouple the provider part of the IP address from the local part, and changes to host TCP/IP software to easily accomodate the transition from old to new IP addresses. I don't even see all this coming together in the current IPv6 efforts and haven't seen anything at all to address these issues in IPv4. The major drawback I see to the mapping/encapsulation scheme is the manual configuration of the mapping tables, and the resultant danger of long lived routing loops. However, it would certainly be better than the possibility of losing connectivity altogether if the "core" Internet routers can't in fact keep pace with the ongoing routing explosion. > P.S. By the way, there is no such thing as "the core" in "the general Internet". I would agree there isn't any single entity or autonomous system that is the "core" of the Internet. However, I conceptually think of the "core" of the Internet as being those routers and their interconnections that maintain full Internet routing tables. -Bill From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 15:26:54 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04028; Thu, 24 Aug 1995 15:26:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA03399; Thu, 24 Aug 1995 15:25:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA03363; Thu, 24 Aug 1995 15:10:55 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03349; Thu, 24 Aug 1995 15:10:38 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06788; Thu, 24 Aug 95 01:10:22 -0400 Date: Thu, 24 Aug 95 01:10:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508240510.AA06788@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, vaf@valinor.barrnet.net Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Vince Fuller > Why do I have this intense urge to strangle every last single person in > the entire IETF? Sorry to stress you Sigh. I wish I could force-feed a bunch of graph and routing theory (e.g. Kleinrock and Kamoun's landmark paper on hierarchical routing) to everyone who wants to argue about routing. It would make the debates at least one order of magnitude more producive. multi-homed sites will still need to be flat-routed in KRE's scheme Well, not flat-routed, but rather visible over a scope which is larger than a single aggregate, but smaller than global. It's hard to quantify how big a scope without knowing more about the topology of a particular instance, how efficient you want the resting routes to be, etc, etc, etc. Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 15:45:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05172; Thu, 24 Aug 1995 15:45:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA03438; Thu, 24 Aug 1995 15:45:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA03421; Thu, 24 Aug 1995 15:28:13 +1000 Received: from valinor.barrnet.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB04061; Thu, 24 Aug 1995 15:26:41 +1000 (from vaf@valinor.barrnet.net) Received: (from vaf@localhost) by valinor.barrnet.net (8.6.8/8.6.6) id WAA03489; Wed, 23 Aug 1995 22:27:41 -0700 Date: Wed, 23 Aug 95 22:27:41 PDT From: Vince Fuller To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Phone: (415) 528-7227 Usmail: 3801 East Bayshore Rd, Palo Alto, CA, 94303 Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of Thu, 24 Aug 95 01:10:22 -0400 Message-Id: Precedence: bulk Sigh. I wish I could force-feed a bunch of graph and routing theory (e.g. Kleinrock and Kamoun's landmark paper on hierarchical routing) to everyone who wants to argue about routing. It would make the debates at least one order of magnitude more producive. Yup. But many aspects of graph theory are rather subtle, which makes it a difficult subject to force-feed. Well, not flat-routed, but rather visible over a scope which is larger than a single aggregate, but smaller than global. It's hard to quantify how big a scope without knowing more about the topology of a particular instance, how efficient you want the resting routes to be, etc, etc, etc. Well, the first cut at his definition talks about a two-level hierarchy, with flat routing between AS's. One could imaging aggregation happening among parts of the "core", though causing that to happen in a way so as to aggregate multi-homed sites will require the sort of careful coordination as using CIDR to accomplish the same thing (except that only the "core" addresses will have to be coordinated, not the end-sites). No surprise here, since the same graph "circles" are being drawn, their just named a little differently. Do you have any critique of his scheme as to whether it is workable in a short time frame and scalable enough to be useful? And how about the typical faults and complications associated with NAT's, of which this is but one example? --Vince From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 16:05:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06044; Thu, 24 Aug 1995 16:05:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA03480; Thu, 24 Aug 1995 16:05:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA03471; Thu, 24 Aug 1995 16:03:39 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05891; Thu, 24 Aug 1995 16:02:48 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23203 Thu, 24 Aug 1995 16:01:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06888; Thu, 24 Aug 95 01:58:24 -0400 Date: Thu, 24 Aug 95 01:58:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508240558.AA06888@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bill@wizard.gsfc.nasa.gov Subject: Re: ownership, leasing, renumbering, and that draft Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: bill@wizard.gsfc.nasa.gov (Bill Fink) This is just a fundamental facet of hierarchical addressing and route aggregation, namely the loss of more specific routing information when performing the route aggregation. Note that it's that loss of information (specifically, the loss of the differing metrics to pieces of an aggregate) which causes non-optimal routing with hierarchical addressing... I will now reiterate my personal preference for geographic based addressing which I feel has better overall properties than either a provider based scheme Geographic addressing only works by constraining the topology. If you let me constraint the topology, I can make topology-based addresses (the term "provider-based" is inaccurate, as the message I sent to CIDRD explains; will resend to Big-I) work really well too. The major drawback I see to the mapping/encapsulation scheme ... it would certainly be better than the possibility of losing connectivity altogether if the "core" Internet routers can't in fact keep pace with the ongoing routing explosion. Unfortunately, these mapping schemes are all non-options. To get something organized (since this solution cannot be imposed piecemeal, but has to be applied throughout the core), implemented, and deployed, will take at least a year, I would guess, and probably longer. We don't have that time. To repeat, this problem was obviously coming 5 years ago. The IETF decided that the solution was CIDR. The implications of that (topology-based addresses -> renumbering) were obvious. The Internet, to use my favourite analogy, is in the position of some who has jumped off a 50-story building, and about the 10th story decides it's going to hurt. Bit late now, guys... Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 16:07:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06107; Thu, 24 Aug 1995 16:07:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA03502; Thu, 24 Aug 1995 16:06:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA03474; Thu, 24 Aug 1995 16:04:43 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05979; Thu, 24 Aug 1995 16:04:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07096; Thu, 24 Aug 95 02:03:19 -0400 Date: Thu, 24 Aug 95 02:03:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508240603.AA07096@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: "Provider-based addresses" is bad terminology Cc: jnc@ginger.lcs.mit.edu Precedence: bulk Here's a resend of the message (originally to CIDRD) which explains why "provider-based addressing" is, err, technically inappropriate terminology. (If we stop using it, I won't be forced to emit any nastier characterizations of it! :-) -------- By calling it "provider-based addressing", we are causing people to have the wrong mental model of what's going on. In general, the model you need to work with is "if I can draw a circle around a bunch of stuff on a map, it needs to have a single 'address' which can refer to the whole thing" - in CIDR, of course, the 'address' would be an xxx/y type construct. A provider and their singly homed clients are *an example* of such an area, but *not the only one*. Allocating a chunk of address space to an exchange point, and the stuff hanging off it, is another example. --> The point is that we need to be able to refer to a contiguous area of the --> map (i.e. connectivity graph) by a single name. (In fact, I'd prefer it if people stuck to drawing circles on map, and got out of "assigning" addreses completely; the procedure of handing out numbers, etc, tends to obscure pretty completely what's really going on, or what *ought* to be really going on, which is drawing those circles; everything else is mechanical bookkeeping. For reasons I don't have time to get into now, drawing the circles is the only interesting part of addressing; i.e. the place where you really make a difference.) As a final aside, I always refer to this approach as "topologically sensitive addressing", not "provider-based addressing"; the latter just isn't transmitting the fundamental idea, it's an example of the fundamental idea. Plus to which, of course, it sounds like an ISP marketing gimmick; it thus forms a natural trap for those who have missed the technical point... :-( Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 16:25:54 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB07015; Thu, 24 Aug 1995 16:25:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA03569; Thu, 24 Aug 1995 16:25:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA03554; Thu, 24 Aug 1995 16:15:53 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06514; Thu, 24 Aug 1995 16:15:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23840 Thu, 24 Aug 1995 16:14:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07124; Thu, 24 Aug 95 02:12:00 -0400 Date: Thu, 24 Aug 95 02:12:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508240612.AA07124@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, vaf@valinor.barrnet.net Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Vince Fuller > Well, not flat-routed, but rather visible over a scope which is ... > smaller than global. Well, the first cut at his definition talks about a two-level hierarchy, with flat routing between AS's. Ah, good point. One could imaging aggregation happening among parts of the "core", though causing that to happen in a way so as to aggregate multi-homed sites will require the sort of careful coordination as using CIDR to accomplish the same thing (except that only the "core" addresses will have to be coordinated, not the end-sites). No surprise here, since the same graph "circles" are being drawn, their just named a little differently. Exactly. Do you have any critique of his scheme as to whether it is workable in a short time frame I don't see that it can be. As I have said on numerous occasions, to get this working means we have to get the entire "core" to adopt it (i.e. it's not like VJCC, which you could deploy on a host-by-host basis), and that means we'd have to go through a design/specify/implement/deploy cycle, and the Internet seems to take about 3 years to do that. scalable enough to be useful? Hmmm. Well, modulo running out of 32-bit addresses, it should work. The translation tables might be an issue. And how about the typical faults and complications associated with NAT's, of which this is but one example? Well, it's not quite a NAT. You're still sharing (at least in IP_Encaps-type schemes) a single global 32-bit address space. If you try to go to IPAE-type schemes, yes, it has the same problems as NAT with embedded addresses. Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 17:26:06 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09992; Thu, 24 Aug 1995 17:26:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA03687; Thu, 24 Aug 1995 17:25:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA03649; Thu, 24 Aug 1995 17:24:37 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09910; Thu, 24 Aug 1995 17:24:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07423; Thu, 24 Aug 95 03:24:07 -0400 Date: Thu, 24 Aug 95 03:24:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508240724.AA07423@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU, IAP@vma.cc.nd.edu, IETF@cnri.reston.va.us, cidrd@iepg.org, dcrocker@brandenburg.com, inet-access@earth.com, nanog@merit.edu Subject: Re: Comments on draft-ietf-cidrd-ownership-01.txt Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker Last week I sent detailed comments on the "Ownership" I-D to the cidrd mailing list. Your document has many problems. Here are a few: The document goes on to describe the nature and benefits of hierarchical addressing. It then, incorrectly, asserts that the Internet topology reflects a hierarchy and that addresses must be kept aligned with the hierarchy. Well, in fact it says that "the topology of the network is not strictly hierarchical". I suppose you could read that as saying that the network topology is basically hierarchical, but it turns out this is a moot point. You appear to have missed the distinction between a hierarchical topology, and an address hierarchy. One can apply hierarchical addressing to a perfectly regular topology, e.g. a North-East-West-South mesh in which each node has precisely four neighbours. (True, one doesn't need full-blown dynamic routing for that case, but it's a useful test case.) This disproves your implicit suggestion that one cannot use hierarchical routing in a network which does not have a hierarchical topology. This requirement is used to assert the need for enforcing addressing changes when (some) topological changes take place. The point remains that use of hierarchical addressing is the *only* way known to control the growth of routing overhead costs in a very large network, and that an addressing hierarchy that is loosely isomorphic to the conectivity topology is the *only* one that will do that. As such, if it of course true that as the topology changes, the addressing hierarchy will have to, as well. The document makes no effort to deal with the very real difficulties this model creates for multi-homed organizations Multi-homing provides extra capability, but it does not come without a cost (in terms of routing overhead), and this is true no matter which addressing scheme is used. Since this topic is lengthy and complex, I will pass on. The document asserts the model of customer "leasing" of addressing rather than "owning" them but does not discuss the problems this creates with large-scale requirements for renumbering, generally viewed as difficult, but potentially quite insidious for local providers who change transit providers. Renumbering is indeed painful. However, given past decisions, no other option is now available to us if we wish the keep the Internet i) growing, and ii) functioning. In the next paragraph the paper states the importance of having an address reflect the topology of the network. Since the Internet is not a simple tree, but instead is a messy mesh one must ask by what procrustean process the Internet is to be represented by (relatively) stable hierarchical addresses? Exactly. There is no way to represent a dynamic topology like the Internet with stable hierachical addresses. The paper also says that changing an address is required as the network topology changes. This simply isn't true ... Internet topology changes all the time and sites are not required to change their addresses. At best this paragraph is seriously imprecise. At worst it is seriously wrong. This is a subtle and complex technical point, one that is not possible to quantify, and certainly not in a paper intended for a non-technical audience. A given address hierarchy, for a given topology, will produce a certain degree of routing overhead (as well as non-optimal routes). If the topology is then changed, wihtout changing the addressing, the routing overhead will grow. Eventually, it will grow to the degree that changes to the address hierarchy are needed to bring routing overhead back to reasonable bounds. The problem is exactly that no single change is deadly, but rather it is the accumulation of many small changes that cannot be supported. The end effect is to aid in the myth of Internet topological hierarchy. There is no myth of toplogical hierarchy that I know of, except in this paper. The first paragraph cites concerns for routing system scaling. However there is no concern expressed for Internet local providers or users. Presumably, an Internet which no longer worked because of routing system scaling problems would be a severe concern for Internet local providers or users. It is time to consider alternatives to CIDR. Unfortunately, it's too late to consider alternatives. The Internet has a real problem with routing table growth. To get something organized (since the solution to this problem cannot be imposed piecemeal, but has to be applied throughout the core), implemented, and deployed, will take at least a year, I would guess, and probably a fair amount longer. (It took almost 3 years to get CIDR, a relatively simple solution, deployed, BTW.) We don't have that time. CIDR was chosen with the expectation that it would be a sufficient near-term answer for routing table compression. CIDR was intended to handle "[growth] of routing tables in Internet routers beyond the ability of current software, hardware, and people to effectively manage". It indicated that "[the] proposed solution is to topologically allocate future IP address assignment". That is what we are doing now. After some considerable initial success it is proving inadequate. No, it's perfectly adequate, just painful. However, no other tool is available to handle growth in the network. The Internet, to use my favourite analogy, is in the position of some who has jumped off a 50-story building, and about the 10th story decides it's going to hurt. Bit late now, guys... Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 18:05:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12346; Thu, 24 Aug 1995 18:05:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA03739; Thu, 24 Aug 1995 18:05:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA03720; Thu, 24 Aug 1995 17:51:28 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB11593; Thu, 24 Aug 1995 17:50:46 +1000 (from bmanning@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Thu, 24 Aug 1995 00:47:26 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199508240747.AA12927@zephyr.isi.edu> Subject: Re: ownership, leasing, renumbering, and that draft To: deering@parc.xerox.com (Steve Deering) Date: Thu, 24 Aug 1995 00:47:25 -0700 (PDT) Cc: yakov@cisco.com, dcrocker@brandenburg.com, big-internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: <95Aug23.185800pdt.75270@digit.parc.xerox.com> from "Steve Deering" at Aug 23, 95 06:57:59 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 788 Precedence: bulk > I think the thing being referred to as "the core" is the connected graph > of default-free routers. It spans multiple ISPs and IXs. Are you saying > that such a thing does not exist, or are you simply objecting to the term > "core"? If the latter, how about calling it the DFZ (default-free zone)? > > Steve > out of curiousity steve, can you define "default-free" please. If I have suppressed longer prefixes into smaller prefixes in my router, is it still a DF router? I expect not, since the effect is to proxy aggregate over a potentially prefered (and working!) path over a shorter prefix (and down!) path. I've just black holed part of the net because I am not carrying the more specific, correct path. Under some terms, this is still a default free router. -- --bill From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 18:46:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14267; Thu, 24 Aug 1995 18:46:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA03799; Thu, 24 Aug 1995 18:45:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA03782; Thu, 24 Aug 1995 18:28:15 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13499; Thu, 24 Aug 1995 18:28:09 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29236 Thu, 24 Aug 1995 18:27:54 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA13812; Thu, 24 Aug 1995 01:22:47 -0700 Date: Thu, 24 Aug 1995 01:22:47 -0700 From: Tony Li Message-Id: <199508240822.BAA13812@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: <12192.809185412@munnari.OZ.AU> (message from Robert Elz on Wed, 23 Aug 1995 23:43:32 +1000) Subject: Re: ownership, leasing, renumbering, and that draft Precedence: bulk Robert, First, thanks, I think, for waking up this list - at least it allowed me to find a bunch of dead addresses and get them deleted... You're welcome. And my apologies for pulling a kinda nasty trick to get the discussion moved over here. First, the problem - the Internet default-free routing tables are growing, and growing rapidly, and will sometime be beyond the capacities of current routers. Even if the hardware vendors were willing to do it, essentially everyone recognises that simply building bigger hardware is not a solution that can possibly work, even in the relatively short term. To be more precise, the routing tables were (and still can) grow at a rate that is faster than the rate at which the computer industry can grow new hardware. The question of whether even this will be sufficient, or whether existing connections may need to be required to be renumbered as well is still open (the draft says that is outside its scope). It all depends on compliance, which is out of our control. Note that even if the draft does become an Internet policy, there is still no force of law behind it. The approach is conceptually very simple - when a packet arrives at a default free router, bearing a standard IP address, one of three cases holds. Either there is no route to the destination, and the packet is dropped, or the destination is at some local connection, routing is known, and the packet is forwarded locally, or the destination is somewhere through the core of the internet, traversing a default-free-router path to some exit point where the destination is "local". It is the last of those cases that is of interest here. Now I'm very much lost already. If such a thing as a default free router exists, then what is the gain by tunneling other destinations? And if we can scale a default free router, why do we need to do tunneling? The result of this change would be to trade a growing routing table for a growing mapping table, which at first glance doesn't seem like such a big win, however it has in fact two major advantages. The first is that a mapping table changes very infrequently - only as frequently as sites change their connectivity, network outages are irrelevant, and in any case is very easy and cheap to update (there are no calculations, just entries to install in the table), so the cpu problems we currently have go away. Fine, but that's hardly worth this pain. Second, the mapping table, at its very worst, needs be just a simple straight linear array, indexed by /24 network prefixes, and returning a 32 bit IP address. There are only ("only") 2^24 (16M) /24 network prefixes, which means the mapping table has a maximum size of 64Mb. That's too big for current routers, but current routers don't need nearly that big a table (nor would they implement it as a single linear array, until that became the cost-effective way). And this fails when we get to IPv6. How about something that scales? 4) We need to have this actually implemented in the border core routers, and deployed by their operators. Implementation will just take pressure upon the router vendors, indicating to them that this is something that the Internet needs. Yes, I can hear it now: "Fuck the Internet. It's not worth the development cost. We'll just make the access routers. That's where the money is." Besides the fact that the development time for this is longer than we have if aggregation gets out of hand. Just so you don't get me wrong: if your scheme works, then we have enough aggregation to make the net work anyhow. If enough aggregation doesn't happen, then your scheme explodes too. This proposal fails the cost-benefit test and the schedule test. Tony From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 19:06:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB15076; Thu, 24 Aug 1995 19:06:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA03836; Thu, 24 Aug 1995 19:05:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA03813; Thu, 24 Aug 1995 18:48:48 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14341; Thu, 24 Aug 1995 18:48:19 +1000 (from kre@munnari.OZ.AU) To: Big-Internet@munnari.OZ.AU Subject: IP Encapsulation growth proposal Date: Thu, 24 Aug 1995 18:47:51 +1000 Message-Id: <12434.809254071@munnari.OZ.AU> From: Robert Elz Precedence: bulk First thanks to all those people who responded to queries on the proposal while I slept - much speeding up the turnaround. There are still a few outstanding issues for me to address which I will try to do in subsequent messages, after I re-read the relevant mail. However, there are a few simple things that I can easily clear up, and will do now. First ... Message-Id: Date: Wed, 23 Aug 1995 12:10:08 -0700 From: hinden@Ipsilon.COM (Bob Hinden) I think you have reinvented the IP Encaps proposal I made .. Ah, no. Not that the proposal isn't basically the same, its just that I didn't invent, or reinvent this - all I did here was express it as a possibile way to move. I really hope I didn't give the impression this was an idea I claimed any rights over - I tried to avboid that. Thanks for sending (me) the IP Encaps draft - if we get to the stage of deciding that this is worth pursuing (which largely probably depends on an issue later in this message), then I would suggest starting by re-issuing that draft, of course, with you (Bob) remaining as author, if you're willing. Yakov asked about the word "core" - Steve Deering's reply duplicated what I would have sent, except I wouldn't have thought of DFZ (though I wish that were pronounceable) mine. I probably didn't explain it in the B-I message, but somewhere in this thread, either on cidrd or in private mail perhaps, I did think I had explained that I was using core as a shorthand way of saying "that part of the internet that operates without default routes". If there was some way to make two such areas exist, and be disjoint, and work, the proposed scheme would work in each of those areas independantly. My "core", or Steve's DFZ is simply one of those areas. Date: Wed, 23 Aug 95 22:27:41 PDT From: Vince Fuller Message-Id: Well, the first cut at his definition talks about a two-level hierarchy, with flat routing between AS's. (with which Noel agreed, but he was probably asleep by then). No, not at all, it didn't actually talk about routing between the AS's at all - for that matter, it didn't mention AS's. AS's might be the right sized units to be considered as the "areas" I did mention, or they might not, I suspect it might vary on a case by case basis. Certainly there would be a relationship. Routing in this space however was "using techniques we currently use". That was most certainly meant to mean CIDR. The very point of this scheme is to allow the techniques of CIDR to be used to their fullest possible extent, but without requiring the pain of renumbering at end sites. On the other hand, renumbering of the "area addresses" is to be very much expected, so they match topology as well as is practicable. That's why those addresses need to come from a new space, and not simply be some existing address, which would be just as hard to alter as any other existing address. Otherwise using existing addresses would avoid needing a new set of allocations. Also, routing co-ordination here will certainly be as complex as it currently is - this "solution" is not intended as a panacea, just as a stop-gap. It is not intended to reduce anyone's work load, except those end sites that would no longer be required to renumber if their connectivity alters. Perhaps being able to co-ordinate the area addresses may make the role or working out how to aggregate them fractionally easier, but I wouldn't depend upon it. And how about the typical faults and complications associated with NAT's, of which this is but one example? No, this is most certainly nothing like a NAT scheme. There is no packet modification here at all. This is much more like an ARP scheme (as one of Dave Crocker's messages suggested). Consider replacing (figuratively) the entire core (DFZ) of the Internet (any internet with a big enough DFZ to be a problem) with a giant FDDI ring (or some isomorphic technology that could make a ring that big). The scheme proposed is exactly equivalent to turning on proxy-ARP on the routers connected to the ring, and having each install a default route to the FDDI interface. Upon receiving a packet for the a default destination, ARP for it on the ring, the destination sees itself as the (an) exit point, and replies with its MAC address. The packet is then encapsulated in an FDDI frame and transmitted, where it is decapsulated and continues across whatever other links are needed. The proposed scheme is exactly the same, except that lacking a good way to do internet wide ARP broadcasts (even if we would ever consider doing such a thing) we instead use a mapping table to the same effect (any of the equivalent techniques, such as using a server to return the exit point address would work too, with the same advantages and disadvantages they usually have). We also use IP as the link level framework as we have that deployed already (if the core, that is, the DFZ, can all route CLNP, we could use that just as easily, except the NSAPs would make the mapping table bigger). And finally, for this message, the big question ... Date: Thu, 24 Aug 95 01:58:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508240558.AA06888@ginger.lcs.mit.edu> Unfortunately, these mapping schemes are all non-options. To get something organized (since this solution cannot be imposed piecemeal, but has to be applied throughout the core), implemented, and deployed, will take at least a year, I would guess, and probably longer. We don't have that time. I would also guess a year (though I note in a later message Noel upped his estimate to 3 years - for a scheme with as limited effect as this has, I believe that is way too high). I believe that we do have that year however. Note that this scheme is not intended to be "the" answer, there is no intent that all other work on this problem stop. That is, CIDR should go ahead and plan on reducing the routing table sizes the way it currently is, though allowing perhaps just a few more exceptions than currently planned - ie: allow numbers to be retained if a site really feels it has to (charge them for injecting the route to provide an incentive not to do that without real justification). It has been stated (in cidrd, on its list) many times that ultimately the market will decide all of this. That is undoutably true. My worry is that even if we succeed in implementing forced renumbering (perhaps "you" rather than "we" there), and that works initially, after being asked to renumber more than a very small number of times, the marketplace will rebel, and simply insist on a scheme that doesn't require that. That means - pay for such a thing, and where the market has $'s, someone will appear to take them away. I believe that we absolutely must be planning for that eventuality, we must have a mechanism planned, and started to be deployed, for when this happens (it will happen). This scheme might be that backup plan, if nothing else. The question must be whether it can work technically, and if so, let's make it work (or find an alternative that is better) as quickly as possible. If that is too late, the Internet will already be "dead" (fragmented, or whatever), as that would also indicate that CIDR has also failed. There really is no use throwing up our hands, and crying that the Internet (aka IETF) already comitted suicide by following the path selected, but just hasn't hit the pavement yet. If we're still falling, we have time to find a net. Or at least to try. If to make more time we have to start digging through the pavement a little, then so be it, but we can't plan on digging forever. kre From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 20:08:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB17271; Thu, 24 Aug 1995 20:08:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA03908; Thu, 24 Aug 1995 20:05:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA03902; Thu, 24 Aug 1995 19:57:20 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16831; Thu, 24 Aug 1995 19:56:55 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 1995 01:22:47 MST." <199508240822.BAA13812@greatdane.cisco.com> Date: Thu, 24 Aug 1995 19:56:32 +1000 Message-Id: <12445.809258192@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Thu, 24 Aug 1995 01:22:47 -0700 From: Tony Li Message-ID: <199508240822.BAA13812@greatdane.cisco.com> Now I'm very much lost already. If such a thing as a default free router exists, then what is the gain by tunneling other destinations? We no longer need routing information for most of the net. We end up with no routers that have to deal with full routing tables, on any scale, and we don't require sites to renumber as agressively in order to be able to aggregate routes to make this possible. And if we can scale a default free router, why do we need to do tunneling? If we can scale a default free router, without changing the current Internet models, we don't have to do anything at all. The whole point, apparently (I don't build routers) is that we can't do that. The proposal makes all routers go back to using "default" routes, for the vast majority of destinations, keeping their routing tables smaller. What changes is the mechanism by which they use this "default route". [On saving cpu used dealing with global routing] Fine, but that's hardly worth this pain. I had been led to believe that it was cpu scaling that was the really hard problem with growing the routing tables. Growing memory sizes (enough for a considerable time into the future) is really pretty trivial (I know enough about hardware to know that). If we could make the CPU problem tractable, asking for a bunch more memory, especially if we can bound that at 64Mb absolute maximum (for this), required in a few years, doesn't seem like too much to ask. Pain there will certainly be, the wuestion is just how much, and where the pain should fall. Forcing renumbering can put immense pain at the end points, allowing the net to survive while not requiring quite that much end point pain is to me worth any pain at all imposed on those whose business is the internet (and yes, I know that since that is not me, that is easy to say). And this fails when we get to IPv6. Oh absolutely. I thought I had been very clear about that, but perhaps again not in that message. Sigh... This is absolutely a stop-gap measure designed to assist keep IPv4 working until IPv6 can be implemented. That is it, period. We still need IPv6 scalable routing, but that we can do working with an clean slate, no existing assignments, and no assumptions that assignments once made are irrevocable. Besides the fact that the development time for this is longer than we have if aggregation gets out of hand. If aggregation gets out of hand we're dead anyway, right. So, lets assume that we continue to get some aggregation benefits at least until the scheme can be employed. Just so you don't get me wrong: if your scheme works, then we have enough aggregation to make the net work anyhow. If enough aggregation doesn't happen, then your scheme explodes too. No, I don't believe it does. The encapsulation scheme, once deployed, can function with no aggregation (for IPv4) at all. The limited size of the IPv4 address space guarantees that. We do need aggregation to keep us alive until it can be deployed, but we don't need to depend on it continuing to be possible in order to survive. Given that we have exponential growth, the greatest number of new routes, and consequently, the greatest demand for aggregation (currently) will occur in the last days of IPv4, if we can avoid requiring absolute aggregation at that stage, we can allow IPv4 to die out gracefully, rather than with screams of agony. This proposal fails the cost-benefit test We haven't yet really measured the costs, which is probably possible, or the benefits, which are probably impossible to quantify anyway, so I suspect you are a little premature there. and the schedule test. This I dispute - but perhaps you are assuming this is a replacement for CIDR, which it is not. kre From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 20:26:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18088; Thu, 24 Aug 1995 20:26:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA03956; Thu, 24 Aug 1995 20:25:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA03910; Thu, 24 Aug 1995 20:06:40 +1000 Received: from diablo.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17189; Thu, 24 Aug 1995 20:06:14 +1000 (from doleary@cisco.com) Received: (doleary@localhost) by diablo.cisco.com (8.6.10/CISCO.SERVER.1.1) id DAA01365 for big-internet@munnari.oz.au; Thu, 24 Aug 1995 03:03:34 -0700 Date: Thu, 24 Aug 1995 03:03:34 -0700 From: "Dave O'Leary" Message-Id: <199508241003.DAA01365@diablo.cisco.com> To: big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal Precedence: bulk Robert responded to Vince (I think?) > The proposed scheme is exactly the same, except that lacking > a good way to do internet wide ARP broadcasts (even if we would > ever consider doing such a thing) we instead use a mapping > table to the same effect (any of the equivalent techniques, > such as using a server to return the exit point address would > work too, with the same advantages and disadvantages they > usually have). We also use IP as the link level framework as > we have that deployed already (if the core, that is, the DFZ, > can all route CLNP, we could use that just as easily, except the > NSAPs would make the mapping table bigger). Isn't this effectively the problem that (possibly) being solved in ROLC with NHRP? And Robert responds to Noel: > It has been stated (in cidrd, on its list) many times that > ultimately the market will decide all of this. That is > undoutably true. My worry is that even if we succeed in > implementing forced renumbering (perhaps "you" rather than "we" > there), and that works initially, after being asked to renumber > more than a very small number of times, the marketplace will > rebel, and simply insist on a scheme that doesn't require that. > That means - pay for such a thing, and where the market has $'s, > someone will appear to take them away. Another alternative, which I also believe has been pointed out at least by Vadim, is that maybe if we would just make renumbering a little (or a lot) easier then the users wouldn't be "rebelling". The market can insist (via not buying them) that products don't do stupid things like tie licenses to fixed IP addresses. The market can create demand for a real commercial DHCP server, tools for managing DNS (etc.), a bind (or equivalent) implementation that allows for more dynamic updates, NATs that just solve the problem, etc. dave From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 20:45:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19080; Thu, 24 Aug 1995 20:45:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA03991; Thu, 24 Aug 1995 20:45:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA03976; Thu, 24 Aug 1995 20:28:53 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18171; Thu, 24 Aug 1995 20:28:10 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id DAA06502; Thu, 24 Aug 1995 03:26:02 -0700 Message-Id: <199508241026.DAA06502@hubbub.cisco.com> To: Steve Deering Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Wed, 23 Aug 95 18:57:59 PDT." <95Aug23.185800pdt.75270@digit.parc.xerox.com> Date: Thu, 24 Aug 95 03:26:01 PDT From: Yakov Rekhter Precedence: bulk > Yakov, > > > P.S. By the way, there is no such thing as "the core" in "the general > > Internet". > > I think the thing being referred to as "the core" is the connected graph > of default-free routers. It spans multiple ISPs and IXs. Are you saying > that such a thing does not exist, or are you simply objecting to the term > "core"? If the latter, how about calling it the DFZ (default-free zone)? My main objection was to the term "core". Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 21:06:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19948; Thu, 24 Aug 1995 21:06:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA04046; Thu, 24 Aug 1995 21:05:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA04028; Thu, 24 Aug 1995 21:02:01 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19714; Thu, 24 Aug 1995 21:01:50 +1000 (from kre@munnari.OZ.AU) To: "Dave O'Leary" Cc: big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Thu, 24 Aug 1995 03:03:34 MST." <199508241003.DAA01365@diablo.cisco.com> Date: Thu, 24 Aug 1995 21:01:22 +1000 Message-Id: <12455.809262082@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Thu, 24 Aug 1995 03:03:34 -0700 From: "Dave O'Leary" Message-ID: <199508241003.DAA01365@diablo.cisco.com> Isn't this effectively the problem that (possibly) being solved in ROLC with NHRP? Possibly, I'm afraid that isn't a group I follow. But if it is, then great, the more parts already being solved, the better. Another alternative, which I also believe has been pointed out at least by Vadim, is that maybe if we would just make renumbering a little (or a lot) easier then the users wouldn't be "rebelling". Unfortunately, here we do have timing problems. That will work just fone for IPv6, but for IPv4 the time scale in which we have to work is now inside the lifetime of currently deployed equipment. Making renumbering easier can no longer be done by vendors shipping new products, it would have to somehow be retrofitted into what exists already. Further, it is not just the technology that matters, it is the culture. Don't let this stop work on making that happen though, easier renumbering is a worthwhile objective in any case, it can be required for lots of reasons beyond cidr. kre From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 21:08:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20044; Thu, 24 Aug 1995 21:08:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA04068; Thu, 24 Aug 1995 21:07:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA04040; Thu, 24 Aug 1995 21:04:11 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19825; Thu, 24 Aug 1995 21:04:01 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id EAA07320; Thu, 24 Aug 1995 04:03:41 -0700 Message-Id: <199508241103.EAA07320@hubbub.cisco.com> To: bmanning@isi.edu (Bill Manning) Cc: deering@parc.xerox.com (Steve Deering), big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 95 00:47:25 PDT." <199508240747.AA12927@zephyr.isi.edu> Date: Thu, 24 Aug 95 04:03:41 PDT From: Yakov Rekhter Precedence: bulk Bill, > > I think the thing being referred to as "the core" is the connected graph > > of default-free routers. It spans multiple ISPs and IXs. Are you saying > > that such a thing does not exist, or are you simply objecting to the term > > "core"? If the latter, how about calling it the DFZ (default-free zone)? > > > > Steve > > > > out of curiousity steve, can you define "default-free" please. > If I have suppressed longer prefixes into smaller prefixes in my > router, is it still a DF router? I expect not, since the effect > is to proxy aggregate over a potentially prefered (and working!) > path over a shorter prefix (and down!) path. I've just black holed > part of the net because I am not carrying the more specific, correct > path. Under some terms, this is still a default free router. Just to add to what you said. A default route is just an instance of route aggregation. So, what is so special about a set of routers that does not carry one particular aggregate - default ? Or may be we need to talk about "aggregation-free zone" (afz) -- the connected graph of routers that do not perform any aggregation ? Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 21:11:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20176; Thu, 24 Aug 1995 21:11:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA04093; Thu, 24 Aug 1995 21:09:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA04024; Thu, 24 Aug 1995 20:58:01 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19468; Thu, 24 Aug 1995 20:56:17 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04544 Thu, 24 Aug 1995 20:54:45 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id DAA20058; Thu, 24 Aug 1995 03:52:12 -0700 Date: Thu, 24 Aug 1995 03:52:12 -0700 From: Tony Li Message-Id: <199508241052.DAA20058@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: <12445.809258192@munnari.OZ.AU> (message from Robert Elz on Thu, 24 Aug 1995 19:56:32 +1000) Subject: Re: ownership, leasing, renumbering, and that draft Precedence: bulk We no longer need routing information for most of the net. Bug, not a feature. It means that core failures are catastrophic. We end up with no routers that have to deal with full routing tables, on any scale, and we don't require sites to renumber as agressively in order to be able to aggregate routes to make this possible. I must be in Kansas. You wrote: "The approach is conceptually very simple - when a packet arrives at a default free router, bearing a standard IP address, one of three cases holds." That sure sounds like a router that has a full table. And if we can scale a default free router, why do we need to do tunneling? If we can scale a default free router, without changing the current Internet models, we don't have to do anything at all. We're backwards. You're presuming that we can scale routing so that a default-free router can even exist. If it does exist at any point in the net, then why not use it. How did you get to this point where you can have a default free router? The whole point, apparently (I don't build routers) is that we can't do that. No. We can't do that if we don't get enough aggregation. The proposal makes all routers go back to using "default" routes, for the vast majority of destinations, keeping their routing tables smaller. But there's still this one router that has this non-scalable table. Fine, but that's hardly worth this pain. I had been led to believe that it was cpu scaling that was the really hard problem with growing the routing tables. This is incorrect. CPU scaling is ONE problem that we have, to be sure. Note that routing table CPU usage (as opposed to switching CPU usage) scales as the number of routes times the probability of flap times the flap rate. Yes, the number of routes hurts. However, thanks to the damping code that is currently being debugged, it looks like we can get the flap rate way down. Also, if people aggregate, the probability of flapping goes way down, as it requires all components of the aggregate to go down to flap the aggregate. "really hard" is an overstatement. Yes, it's a problem. Growing memory sizes (enough for a considerable time into the future) is really pretty trivial (I know enough about hardware to know that). This is the key point. No, it's not trivial (tho I know less than enough about hardware than you apparently). Recall that the requirement is to double the switching table (not the protocol memory, which is just straight DRAM) every nine months. The switching table, even if completely _static_, needs to be accessed at line rate. You may recall that computer memories double roughly every two years or so. How long before router memory subsystems exceed those of high-end workstations? And recall, that the Internet is the SOLE consumer of such a product. Forcing renumbering can put immense pain at the end points, It's pretty clear from the statements that we've heard that "immense pain" is not a reasonable characterization. And this fails when we get to IPv6. Oh absolutely. I thought I had been very clear about that, but perhaps again not in that message. Sigh... This is absolutely a stop-gap measure designed to assist keep IPv4 working until IPv6 can be implemented. That is it, period. We still need IPv6 scalable routing, but that we can do working with an clean slate, no existing assignments, and no assumptions that assignments once made are irrevocable. Ok. But then I put it to you that you're now setting folks up for a rude shock when they get to IPv6 and the rules change. Besides the fact that the development time for this is longer than we have if aggregation gets out of hand. If aggregation gets out of hand we're dead anyway, right. So, lets assume that we continue to get some aggregation benefits at least until the scheme can be employed. If we get enough aggregation benefits so that we can deploy this (and that aggregation level continues) then we don't need this at all. Maybe I haven't made things sufficiently clear: if we can get enough aggregation such that the switching table grows at some reasonably slow rate (linear would be nice), then we have NO problems. Zero. Zip. Nada. Remember that (at least for the forseeable future) link speeds are headed up, so new hardware is going to get deployed. No one is (or has) said that things can't get bigger. It is the current _exponential rate_ that cannot be sustained. and the schedule test. This I dispute - but perhaps you are assuming this is a replacement for CIDR, which it is not. Well, if it's not a replacement for CIDR, why do we need it? Either we have CIDR and it works and we're done (until [and if ;-)] we install IPv6), and people are renumbering or we use your technique and people don't renumber and CIDR doesn't work. Tony From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 21:46:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21836; Thu, 24 Aug 1995 21:46:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA04151; Thu, 24 Aug 1995 21:45:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA04147; Thu, 24 Aug 1995 21:41:59 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21595; Thu, 24 Aug 1995 21:41:52 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id EAA08203; Thu, 24 Aug 1995 04:40:25 -0700 Message-Id: <199508241140.EAA08203@hubbub.cisco.com> To: bill@wizard.gsfc.nasa.gov (Bill Fink) Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 95 00:56:36 EDT." <9508240456.AA21022@wizard.gsfc.nasa.gov> Date: Thu, 24 Aug 95 04:40:25 PDT From: Yakov Rekhter Precedence: bulk Bill, > > Now let's suppose that P1 and P2 are atomic routing entities, with > prefixes of P1/n and P2/n respectively, i.e. their prefixes are carried > "as is" through the "core" without any further route aggregation (this > basically assumes that they are at the highest level of the hierarchical > addressing). Then, P1 would once again have 2 paths to P2, one via R1 > and the "core" to the provider P2/n, and the direct path to P2/n via > their "private link". Since both paths have the same granularity of > routing information, i.e. P2/n, it would be possible to automatically > fallback from the "core" path to the "private" path in the case of a > failure in the link between R2 and P2 (or more generally a failure > anywhere in the path P1-R1-R2-P2). The above described a solution to the problem that I pointed out to in my note. This solution is used presently in the Internet. So, at this point it should be clear that within the current model the problem I brought up can be solved (as you just demonstrated). > > However, the exact same mechanisms could still be employed when using > route mapping to handle "exception" cases of sites that didn't fall > within the "natural" address space of their provider. I don't think so. See my comments below. > Consider the > following case where a site S3 in region R2 has switched providers > from P3 to P2: > > ----------------------- > ( ) > /(R1 "core" R2)\ > / ( ) \ > S1-- P1 -----------------------) P2-----S2 = P2-S2/o > \ / \ > \ / \ > ------------------------- ---S3 = P3-S3/o > "private link" > > If P1-S1 wants to send to P3-S3, the packet will be forwarded normally > to P1 (via the default route). P1 will notice the existence of the > mapping for P3-S3/o via P2/n. It will then detect that there are 2 This does not match /kre's proposal, as P1 is NOT part of the "core". So, P1 has no mapping information AT ALL. > paths for P2/n, the "core" path of R1-R2-P2, and the direct path via > the "private link". If the "core" path is preferred and is up, then > it will be used. If the "core" path failed for any reason, there would > be an automatic fallback to the direct, "private" path. P1 is NOT in the "core". This does not match /kre's proposal. Please explain how would a router in P1 find out that the path through the "core" is down. > > P1 would use IP-in-IP encapsulation to transmit the packet to P2. P1 is NOT part of the "core", and thus does not do IP-in-IP encapsulation. This again does not match /kre's proposal. > The source IP address would be the IP address of the interface on > P1 on which the packet is to be transmitted and the destination > IP address would be the IP address of the region P2/n. One possible In /kre's proposal the destination address in the outer header is set to R2, and NOT to "the IP address of the region P2/n". This again does not match /kre's proposal. > way to represent this would be as P2-0-n, where n would be encoded > in the low order 5 bits of the IP address (this means this technique > could not be used to handle subnets with a prefix length greater > than 27 but I don't consider that a significant drawback). Another > possible method would be to use a modified version of the IP-in-IP > encapsulation and put P2-0 as the destination IP address with the > prefix length n simply placed in a 4-byte field (to maintain alignment) > immediately following the modified IP-in-IP IP header. > > Normal IP routing would be used to forward the packet to P2. P2 would > recognize an IP-in-IP packet addressed to itself, i.e. that it was a > border router for the region P2/n (there could be several for > redundancy purposes). It would decapsulate the packet and extract > the original destination IP address P3-S3-x, notice that it had a > route for the region P3-S3/o, and use normal IP routing to forward > the decapsulated packet toward its ultimate destination. In /kre's proposal the packet would be forwarded to R2, and R2 would perform decapsulation. Again, your description does not match /kre's proposal. P2 is not a part of the "core". Therefore P2 would not be involved in decapsulation. To sum things up: (a) you explained how the problem I brought up can be solved within the current Internet model (b) you didn't explain how the problem I brought up can be solved within the encaps model (the model described in /kre's message) (c) your description of how to handle routes to P3-S3 does not seem to match the encaps model (/kre's proposal) Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 22:06:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22731; Thu, 24 Aug 1995 22:06:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04188; Thu, 24 Aug 1995 22:05:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04184; Thu, 24 Aug 1995 22:00:38 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22416; Thu, 24 Aug 1995 22:00:29 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id FAA08723; Thu, 24 Aug 1995 05:00:12 -0700 Message-Id: <199508241200.FAA08723@hubbub.cisco.com> To: doleary@cisco.com Cc: Big-Internet@munnari.OZ.AU Subject: encaps and NHRP Date: Thu, 24 Aug 95 05:00:12 PDT From: Yakov Rekhter Precedence: bulk Dave, There is one important difference between ROLC/NHRP and the encaps scheme. In the ROLC/NHRP model dynamic routing information is carried over the "cloud". In the encaps scheme dynamic routing information is NOT carried over the "core". Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 22:27:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23448; Thu, 24 Aug 1995 22:27:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04245; Thu, 24 Aug 1995 22:25:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04227; Thu, 24 Aug 1995 22:12:45 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22891; Thu, 24 Aug 1995 22:12:26 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id IAA06895; Thu, 24 Aug 1995 08:12:33 -0400 (EDT) Date: Thu, 24 Aug 1995 08:12:33 -0400 (EDT) From: Scott Bradner Message-Id: <199508241212.IAA06895@newdev.harvard.edu> To: doleary@cisco.com, kre@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk > That will work just fone for IPv6 ... (renumbering technology) a new mailing list was just announced by Bill manning to look into this issue for IPv4 pier-request@isi.edu to subscribe Scott From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 22:27:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23446; Thu, 24 Aug 1995 22:27:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04267; Thu, 24 Aug 1995 22:27:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04190; Thu, 24 Aug 1995 22:06:08 +1000 Received: from diablo.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22723; Thu, 24 Aug 1995 22:06:05 +1000 (from doleary@cisco.com) Received: (doleary@localhost) by diablo.cisco.com (8.6.10/CISCO.SERVER.1.1) id FAA22273 for big-internet@munnari.oz.au; Thu, 24 Aug 1995 05:05:10 -0700 Date: Thu, 24 Aug 1995 05:05:10 -0700 From: "Dave O'Leary" Message-Id: <199508241205.FAA22273@diablo.cisco.com> To: big-internet@munnari.OZ.AU Subject: Re: encaps and NHRP Precedence: bulk Hi Yakov, > To: doleary@cisco.com > cc: Big-Internet@munnari.oz.au > Subject: encaps and NHRP > Date: Thu, 24 Aug 95 05:00:12 PDT > From: Yakov Rekhter > > Dave, > > There is one important difference between ROLC/NHRP and the encaps > scheme. In the ROLC/NHRP model dynamic routing information is carried > over the "cloud". In the encaps scheme dynamic routing information is > NOT carried over the "core". hmmm, I was thinking that the mapping of networks to next hop addresses is not a static mapped table but that it gets updated somehow (i.e. via a routing-protocol-like-thing, like NHRP server-server). But then again I am probably just hallucinating due to lack of sleep. dave From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 22:28:39 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23469; Thu, 24 Aug 1995 22:28:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04291; Thu, 24 Aug 1995 22:28:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04230; Thu, 24 Aug 1995 22:20:30 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23094; Thu, 24 Aug 1995 22:20:27 +1000 (from kre@munnari.OZ.AU) To: Yakov Rekhter Cc: doleary@cisco.com, Big-Internet@munnari.OZ.AU Subject: Re: encaps and NHRP In-Reply-To: Your message of "Thu, 24 Aug 1995 05:00:12 PDT." <199508241200.FAA08723@hubbub.cisco.com> Date: Thu, 24 Aug 1995 22:20:04 +1000 Message-Id: <12474.809266804@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Thu, 24 Aug 95 05:00:12 PDT From: Yakov Rekhter Message-ID: <199508241200.FAA08723@hubbub.cisco.com> There is one important difference between ROLC/NHRP and the encaps scheme. I don't know the former, so can't comment on differences, however... In the encaps scheme dynamic routing information is NOT carried over the "core". Is not true. Routing is certainly carried over the core, just not the routes to the eventual IP end point destinations. Routing for the addresses used to traverse the core still exists. Further, the mechanism by which te mapping table is distributed can evolve into anything. If ROLC already has a nicer solution to this than a file to FTP and install, then I'm entirely willing to adopt it. kre From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 22:29:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23504; Thu, 24 Aug 1995 22:29:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04313; Thu, 24 Aug 1995 22:29:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04214; Thu, 24 Aug 1995 22:10:03 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22777; Thu, 24 Aug 1995 22:09:59 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 1995 03:52:12 MST." <199508241052.DAA20058@greatdane.cisco.com> Date: Thu, 24 Aug 1995 22:09:37 +1000 Message-Id: <12468.809266177@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Thu, 24 Aug 1995 03:52:12 -0700 From: Tony Li Message-ID: <199508241052.DAA20058@greatdane.cisco.com> Bug, not a feature. It means that core failures are catastrophic. I believe to exactly the same extent they would be otherwise. Nothing is changing about the paths that packets take, or can take, purely the mechanism by which those pths are chosen (and the actual bits in the packets as they cross the paths). I must be in Kansas. Is it nice? You wrote: "The approach is conceptually very simple - when a packet arrives at a default free router, bearing a standard IP address, one of three cases holds." That sure sounds like a router that has a full table. OK, yet again, my attempts at explanations fail me. The idea was (is) that right now, today, some router has a full routing table (whatever that actually means - perhaps just that there is at least one IP address, not on a net directly connected to the router, that the router can authoritatively say it cannot reach - though don't hold me to that off the cuff definition). In practice we know which routers we are talking about here. The problem is that that full routing table is growing, and that router is not going to be able to cope with the load, right? Now we have two proposals on the table, one is to cause those routing tables to remain small, by forcing each entry to represent more end-points, so that the router can continue to cope. The other (which doesn't have to exclude the first operating, but frees that from the need to be as comprehensive), operates by removing most of the routing table from the router completely, replacing that by a much smaller routing table that can be very much cidrised, and a mapping table, which has an absolute upper bound on size (cannot grow at all). Now you can call this a default-free router, or a router with default routing, and a weird way of reaching the default route, I don't care, what counts is that this clearly does scale enough to cope with IPv4 (the bounded address size simply guarantees that). You're presuming that we can scale routing so that a default-free router can even exist. No, I want to get rid of default free routers with scaling problems. But there's still this one router that has this non-scalable table. Clearly one of us is missing something important here. Which router with which non scalable table is this? Also, if people aggregate, the probability of flapping goes way down, Yes, but there is that assumption again. What do we do if people don't aggregate, or not enough, consistently enough, and far enough into the future, to keep to the targets. Recall that the requirement is to double the switching table (not the protocol memory, which is just straight DRAM) every nine months. That is true, assuming current growth rates. But recall that the table I propose adding, which will grow, is of bounded size, needs to be accessed (if implemented the dumb way) exactly once per packet, at most (local packets avoid it completely, which includes all packets coming from the core). 60ns access time DRAMs are common now, one 64Mb DRAM array will implement the whole mapping table needed for all time. One DRAM access while forwarding a packet isn't going to kill things (it implies that encapsulation would be required, which implies lots more work than one DRAM access - which is certainly a cost of the proposal). Also note that however effective caching can be will be just as effective here, and all the standard tricks, like pre calculating the link level header to be prepended to packets work just the same way (except the preamble inclues an IPv4 header, so is bigger). How long before router memory subsystems exceed those of high-end workstations? Who cares? We have lots more workstations than routers. And recall, that the Internet is the SOLE consumer of such a product. Yes, I know this is a problem, it's hard to generate the market pressure to cause this to happen. If you recall, I alluded to this in my original message (which inspired the "all go build access routers" comment...) It's pretty clear from the statements that we've heard that "immense pain" is not a reasonable characterization. No, it has been shown that it is not always true, and which is indisputable (I can renumber my house in minutes), not that it never is. But then I put it to you that you're now setting folks up for a rude shock when they get to IPv6 and the rules change. Only if we try to hide this - be open about what is happening, make sure everyone knows what the situation will be, and there will be no problem - or not that matters. I am not in the least concerned about people who simply have to have their current number, because it is the neatest number on the planet (123.456 or something, except that's an unallocated ex-class A). Ego trips aren't interesting. What we need to do is make sure the traps which assuming stable numbering has led us into are not repeated. Maybe I haven't made things sufficiently clear: if we can get enough aggregation such that the switching table grows at some reasonably slow rate (linear would be nice), then we have NO problems. Oh good, because for IPv4 I think we can easily get to a stage where the size grows very very slowly indeed, basically proportional to new local routes (if that gets too big, "local" can simply be subdivided), plus new areas, which are highly aggregatable (by design). The entire mapping table grows not at all, ever, for the rest of IPv4. Zero growth rate. There is one big step to get to that point, but absolutely no continuing growth. Well, if it's not a replacement for CIDR, why do we need it? It is a companion for CIDR, to allow CIDR to continue to operate as it has been doing, particularly recently, but without requiring much in the way of extra impositions on end sites. Once it is deployed, CIDR, as far as route aggregations goes, and to /24 or shorter prefixes, can simply be ignored (certainly renumbering would cease to be an issue). CIDR for address assignments (assigning classless blocks) and aggregating longer than /24 prefixes would remain. Either we have CIDR and it works and we're done We have CIDR now, to a point. CIDR isn't a yes or no option, it can be applied with varying degrees of dilligence. The aim is to avoid the need for the extremes that cause the problems. kre From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 22:48:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24262; Thu, 24 Aug 1995 22:48:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04384; Thu, 24 Aug 1995 22:45:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04339; Thu, 24 Aug 1995 22:37:00 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23893; Thu, 24 Aug 1995 22:36:56 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id FAA09804; Thu, 24 Aug 1995 05:36:34 -0700 Message-Id: <199508241236.FAA09804@hubbub.cisco.com> To: "Dave O'Leary" Cc: big-internet@munnari.OZ.AU Subject: Re: encaps and NHRP In-Reply-To: Your message of "Thu, 24 Aug 95 05:05:10 PDT." <199508241205.FAA22273@diablo.cisco.com> Date: Thu, 24 Aug 95 05:36:34 PDT From: Yakov Rekhter Precedence: bulk Dave, > > hmmm, I was thinking that the mapping of networks to next hop addresses > is not a static mapped table but that it gets updated somehow (i.e. via > a routing-protocol-like-thing, like NHRP server-server). No, it is a *static* mapped table. FTP was suggested as a possible mechanism to update the tables across the "core". Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 22:54:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24479; Thu, 24 Aug 1995 22:54:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04412; Thu, 24 Aug 1995 22:50:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04380; Thu, 24 Aug 1995 22:44:40 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24061; Thu, 24 Aug 1995 22:43:57 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id FAA10116; Thu, 24 Aug 1995 05:43:47 -0700 Message-Id: <199508241243.FAA10116@hubbub.cisco.com> To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 95 22:34:07 +0900." <12479.809267647@munnari.OZ.AU> Date: Thu, 24 Aug 95 05:43:47 PDT From: Yakov Rekhter Precedence: bulk Robert, > Yakov, my proposal is a very rough first cut. It should not be > treated as if it was a finished specification. If P1 wants > to be a part of the core, it can be, there is no reason any > router can't hold the mapping table if it wants to. > Further, there's no particular reason a router couldn't keep a > default route (/0) and at the same time a subset of the > mapping table for certain destinations. I guess I should wait till there will be a finished specification. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 22:58:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24749; Thu, 24 Aug 1995 22:58:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04434; Thu, 24 Aug 1995 22:54:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04333; Thu, 24 Aug 1995 22:33:23 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23666; Thu, 24 Aug 1995 22:33:10 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id FAA09670; Thu, 24 Aug 1995 05:32:53 -0700 Message-Id: <199508241232.FAA09670@hubbub.cisco.com> To: Robert Elz Cc: doleary@cisco.com, Big-Internet@munnari.OZ.AU Subject: Re: encaps and NHRP In-Reply-To: Your message of "Thu, 24 Aug 95 22:20:04 +0900." <12474.809266804@munnari.OZ.AU> Date: Thu, 24 Aug 95 05:32:53 PDT From: Yakov Rekhter Precedence: bulk Robert, > In the encaps scheme dynamic routing information is > NOT carried over the "core". > > Is not true. Routing is certainly carried over the core, > just not the routes to the eventual IP end point destinations. > Routing for the addresses used to traverse the core still exists. That is correct - the only *dynamic* routing information that is carried over the "core" is the information about destinations *within* the core. In contrast, with ROLC/NHRP model routers connected to the "cloud" exchange among themselves *dynamic* routing information about destinations that are not in the "cloud". Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 23:00:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24817; Thu, 24 Aug 1995 23:00:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04470; Thu, 24 Aug 1995 22:57:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04374; Thu, 24 Aug 1995 22:40:56 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23979; Thu, 24 Aug 1995 22:40:46 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 24 Aug 1995 08:40:39 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 24 Aug 1995 08:40:39 -0400 Received: from kasten.europa by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA12076; Thu, 24 Aug 95 08:38:49 EDT Date: Thu, 24 Aug 95 08:38:49 EDT Message-Id: <9508241238.AA12076@mailserv-D.ftp.com> To: bound@zk3.dec.com Subject: Re: ownership, leasing, renumbering, and that draft From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: kre@munnari.OZ.AU, big-internet@munnari.OZ.AU Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Thu Aug 24 08:38:46 1995] Originating-Client: europa Content-Length: 1166 Precedence: bulk > >There the question of whether the current internet draft > >draft-ietf-cidrd-ownership-01.txt should be forwarded to the > >IESG with a recommendation that it be published as a BCP (see > >RFC1818) has been being debated. > > Where is this being debated? The entire concept needs review and we > need to be careful here as we are a technical community to create stds > not a management committee for the Internet. I have brought this up on > POISED too as an item for discussion. Jim, Speaking with my IESG hat on... Our primary goal is to create standards and technology for the Internet. However, quite often, in order to properly use that technology, additional "instructions" are needed for the "users." The BCP series is meant to be a set of documents that bascially are how we, the developers of the technology, feel that it can best be utilized -- sort of the equivalent to the users manuals that are shipped with software... -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 23:02:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24911; Thu, 24 Aug 1995 23:02:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA04492; Thu, 24 Aug 1995 22:59:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04376; Thu, 24 Aug 1995 22:41:13 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23985; Thu, 24 Aug 1995 22:40:54 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 24 Aug 1995 08:40:51 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 24 Aug 1995 08:40:51 -0400 Received: from kasten.europa by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA12088; Thu, 24 Aug 95 08:39:02 EDT Date: Thu, 24 Aug 95 08:39:02 EDT Message-Id: <9508241239.AA12088@mailserv-D.ftp.com> To: jnc@ginger.lcs.mit.edu, bound@zk3.dec.com Subject: Re: ownership, leasing, renumbering, and that draft From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Thu Aug 24 08:38:56 1995] Originating-Client: europa Content-Length: 1423 Precedence: bulk (IESG Hat On -- again...) Children - and I do mean the both of you. Statements such as these are not productive. Why don't you save the nastygrams for private email. > Noel, > > >Gee, Jim, nice to hear you think that. I'm off to the IESG shortly, as soon as > > have manufactured the grounds to complain, to protest that discussion about > >ow IPv6 is utter drivel is being ruled out of order on the IPv6 mailing > >list... > > Go for it. Though I have not seen any contribution from you on IPv6 of > late? I did not think you were even on the list? My mistake! Pretty > nice folks of late though, once we got past which was the right protocol > for the next generation Internet protocol decision in the IETF. Oh and > implementations are appearing in the industry at a good rate now. > Should even have an IPv6 router and test address space up by Dec 95. > Also a couple of root name servers for IP6.INT. But if IPv6 is doing to > you what I hear is being done to some on CIDR then by all means appeal, > I would. The process is documented in RFC 1602. All IETF members have > rights to appeal. If your not happy with the IESG you can also then go > to the IAB and even to ISOC Board of Trustees. -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 23:08:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25251; Thu, 24 Aug 1995 23:08:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA04512; Thu, 24 Aug 1995 23:03:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04336; Thu, 24 Aug 1995 22:34:38 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23850; Thu, 24 Aug 1995 22:34:28 +1000 (from kre@munnari.OZ.AU) To: Yakov Rekhter Cc: bill@wizard.gsfc.nasa.gov (Bill Fink), big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 1995 04:40:25 PDT." <199508241140.EAA08203@hubbub.cisco.com> Date: Thu, 24 Aug 1995 22:34:07 +1000 Message-Id: <12479.809267647@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Thu, 24 Aug 95 04:40:25 PDT From: Yakov Rekhter Message-ID: <199508241140.EAA08203@hubbub.cisco.com> This does not match /kre's proposal, as P1 is NOT part of the "core". So, P1 has no mapping information AT ALL. Yakov, my proposal is a very rough first cut. It should not be treated as if it was a finished specification. If P1 wants to be a part of the core, it can be, there is no reason any router can't hold the mapping table if it wants to. Further, there's no particular reason a router couldn't keep a default route (/0) and at the same time a subset of the mapping table for certain destinations. The poin of this discussion is to try to work out first whether the scheme is workable, and then second, if appropriate, the details. Let's see if we can avoid quibbling about nits until after if it is decided if there is any point continuing this discussion at all. In /kre's proposal the destination address in the outer header is set to R2, and NOT to "the IP address of the region P2/n". No it isn't. I didn't ever specify exactly what the address would be, beyond that it would identify an exit point. I didn't want to say it (yet) for fear of muddying the waters, and because it isn't important, but my idea would have been for the address to be what is probably best described as an anycast address. Its not important at this stage. Bill's explanations seemed perfectly feasible to me. I was going to say that we could make minor changes to the proposal to make it feasible if necessary, except that we really can't yet, as we don't yet have a proposal that detailed to work with. kre From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 23:28:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26435; Thu, 24 Aug 1995 23:28:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA04580; Thu, 24 Aug 1995 23:25:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA04548; Thu, 24 Aug 1995 23:12:39 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25331; Thu, 24 Aug 1995 23:11:09 +1000 (from yakov@cisco.com) Received: from hubbub.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08282 Thu, 24 Aug 1995 23:09:20 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id GAA11148; Thu, 24 Aug 1995 06:06:42 -0700 Message-Id: <199508241306.GAA11148@hubbub.cisco.com> To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 95 22:09:37 +0900." <12468.809266177@munnari.OZ.AU> Date: Thu, 24 Aug 95 06:06:41 PDT From: Yakov Rekhter Precedence: bulk > Date: Thu, 24 Aug 1995 03:52:12 -0700 > From: Tony Li > Message-ID: <199508241052.DAA20058@greatdane.cisco.com> > > Bug, not a feature. It means that core failures are catastrophic. > > I believe to exactly the same extent they would be otherwise. I don't think so. > Nothing is changing about the paths that packets take, or > can take, purely the mechanism by which those pths are chosen > (and the actual bits in the packets as they cross the paths). And as you change the mechanisms by which paths are chosen you may introduce new failure modes. Partitioning the "core" may be one of them. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 23:31:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26617; Thu, 24 Aug 1995 23:31:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA04605; Thu, 24 Aug 1995 23:29:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04391; Thu, 24 Aug 1995 22:47:53 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24222; Thu, 24 Aug 1995 22:47:28 +1000 (from kre@munnari.OZ.AU) To: Yakov Rekhter Cc: doleary@cisco.com, Big-Internet@munnari.OZ.AU Subject: Re: encaps and NHRP In-Reply-To: Your message of "Thu, 24 Aug 1995 05:32:53 PDT." <199508241232.FAA09670@hubbub.cisco.com> Date: Thu, 24 Aug 1995 22:47:06 +1000 Message-Id: <12490.809268426@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Thu, 24 Aug 95 05:32:53 PDT From: Yakov Rekhter Message-ID: <199508241232.FAA09670@hubbub.cisco.com> In contrast, with ROLC/NHRP model routers connected to the "cloud" exchange among themselves *dynamic* routing information about destinations that are not in the "cloud". In the encaps model that would be the aim too, not "routing" information as such, but the mapping (which achieves the same effect I guess). The only reason for the static tables was to avoid having to develop a protocol to do this in order to get started. If a protocol that can be used exists, and if it is feasible in this situation, then we may be able to use it. kre From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 23:33:29 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26746; Thu, 24 Aug 1995 23:33:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA04625; Thu, 24 Aug 1995 23:31:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA04557; Thu, 24 Aug 1995 23:20:45 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25881; Thu, 24 Aug 1995 23:20:02 +1000 (from kre@munnari.OZ.AU) To: Yakov Rekhter Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 1995 06:06:41 PDT." <199508241306.GAA11148@hubbub.cisco.com> Date: Thu, 24 Aug 1995 23:19:30 +1000 Message-Id: <12523.809270370@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Thu, 24 Aug 95 06:06:41 PDT From: Yakov Rekhter Message-ID: <199508241306.GAA11148@hubbub.cisco.com> > Bug, not a feature. It means that core failures are catastrophic. > I believe to exactly the same extent they would be otherwise. I don't think so. Then this is something that should be discussed now. Explain the catastrophic failure, and how it differs from cidr routing. And as you change the mechanisms by which paths are chosen you may introduce new failure modes. Partitioning the "core" may be one of them. I wasn't planning to change the method by which the path was chosen, just the method by which the information is distributed. As I said before, I really don't know whether the ROLC work fits or not. At this stage let's assume that the mapping table can be distributed, we can work out ways that this can be done, without leaving gaps for new complex failure modes later. Perhaps much later if this looks to be a difficult problem. kre From owner-Big-Internet@munnari.OZ.AU Thu Aug 24 23:42:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27386; Thu, 24 Aug 1995 23:42:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA04523; Thu, 24 Aug 1995 23:06:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA04437; Thu, 24 Aug 1995 22:55:07 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24475; Thu, 24 Aug 1995 22:54:12 +1000 (from kre@munnari.OZ.AU) To: Yakov Rekhter Cc: big-internet@munnari.oz.au Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 1995 05:43:47 PDT." <199508241243.FAA10116@hubbub.cisco.com> Date: Thu, 24 Aug 1995 22:52:30 +1000 Message-Id: <12501.809268750@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Thu, 24 Aug 95 05:43:47 PDT From: Yakov Rekhter Message-ID: <199508241243.FAA10116@hubbub.cisco.com> I guess I should wait till there will be a finished specification. For the kind of detailed question you have been asking, yes. Even if for no other reason that it may be decided that there is a basic fundamental problem (as Tony has been trying to suggest), and the whole scheme is worthless anyway. If that is true, your time in dreaming up these hard cases, and that of whoever has the time to figure out solutions would all be wasted... kre From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 00:09:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29427; Fri, 25 Aug 1995 00:09:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA04713; Fri, 25 Aug 1995 00:05:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA04694; Thu, 24 Aug 1995 23:47:48 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27721; Thu, 24 Aug 1995 23:47:29 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id GAA13849; Thu, 24 Aug 1995 06:47:15 -0700 Message-Id: <199508241347.GAA13849@hubbub.cisco.com> To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 95 23:19:30 +0900." <12523.809270370@munnari.OZ.AU> Date: Thu, 24 Aug 95 06:47:15 PDT From: Yakov Rekhter Precedence: bulk Robert, > > I believe to exactly the same extent they would be otherwise. > > I don't think so. > > Then this is something that should be discussed now. Explain > the catastrophic failure, and how it differs from cidr routing. In the current Internet there is no such thing as the "core". So the notion of partitioning the "core" is not applicable. In the encaps model there is a notion of the "core". If a provider is attached to the "core" at more than one point (multihomed provider), and if the "core" partitions (so that one attachement point is in one partition, and the other attachment point is in another), then only a subset of the "core" (and therefore the destinations connected through the "core") would be reachable through a particular attachment point. So, either (a) the provider would need to figure out what destinations are reachable through each attachment point (just pointing default to the "core" would not be sufficient), or (b) blackholes may occur. > And as you change the mechanisms by which paths are chosen you may > introduce new failure modes. Partitioning the "core" may be one of > them. > > I wasn't planning to change the method by which the path was > chosen, just the method by which the information is distributed. > As I said before, I really don't know whether the ROLC work > fits or not. At this stage let's assume that the mapping table > can be distributed, we can work out ways that this can be done, > without leaving gaps for new complex failure modes later. > Perhaps much later if this looks to be a difficult problem. As we all know, "the evil is in the details". As I said before, I am looking forward to see specifications. Yakov. From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 01:49:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05267; Fri, 25 Aug 1995 01:49:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA05026; Fri, 25 Aug 1995 01:45:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA05002; Fri, 25 Aug 1995 01:31:10 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04433; Fri, 25 Aug 1995 01:31:07 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.53] (dial-cup2-23.iway.aimnet.com [204.118.88.53]) by aimnet.com (8.6.12/8.6.12) with SMTP id IAA28515; Thu, 24 Aug 1995 08:30:33 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 08:30:59 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk At 10:58 PM 8/23/95, Noel Chiappa wrote: >Geographic addressing only works by constraining the topology. If you let me you mean the way that our national and local road system is constrained? The way our air traffic system is constrained? So my postal address really dictates all those constraints? I don't think so, Noel. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 01:53:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05385; Fri, 25 Aug 1995 01:53:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA05050; Fri, 25 Aug 1995 01:51:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA05011; Fri, 25 Aug 1995 01:31:55 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04452; Fri, 25 Aug 1995 01:31:46 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.53] (dial-cup2-23.iway.aimnet.com [204.118.88.53]) by aimnet.com (8.6.12/8.6.12) with SMTP id IAA28652; Thu, 24 Aug 1995 08:31:14 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 08:31:40 -0700 To: "Dave O'Leary" From: Dave Crocker Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 3:03 AM 8/24/95, Dave O'Leary wrote: >least by Vadim, is that maybe if we would just make renumbering a >little (or a lot) easier then the users wouldn't be "rebelling". Dave, this is a good goal. Unfortunately discussions around this same idea keep uncovering a laundry list of places that have built-in (and from modern perspective, inappropriate) use of IP addresses. At the least, yes we need to put some focus on the goal, no matter what. Manning's PIER discussion is starting for that purpose. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 02:00:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05646; Fri, 25 Aug 1995 02:00:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA05083; Fri, 25 Aug 1995 01:56:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA05005; Fri, 25 Aug 1995 01:31:33 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04442; Fri, 25 Aug 1995 01:31:29 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.53] (dial-cup2-23.iway.aimnet.com [204.118.88.53]) by aimnet.com (8.6.12/8.6.12) with SMTP id IAA28553; Thu, 24 Aug 1995 08:30:46 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 08:31:12 -0700 To: Tony Li From: Dave Crocker Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk At 3:52 AM 8/24/95, Tony Li wrote: > Forcing renumbering can put immense pain at the end points, > >It's pretty clear from the statements that we've heard that "immense >pain" is not a reasonable characterization. I'm inclined to agree with you. "disastrous pain" would probably be a better characterization. In effect it causes organizations of any significant size to be unable to afford the cost of changing providers. Then again, maybe the problem is with the word 'pain'. For local providers unable to change transit providers, it's definitely not strong enough. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 02:05:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05797; Fri, 25 Aug 1995 02:05:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA05105; Fri, 25 Aug 1995 02:02:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA05008; Fri, 25 Aug 1995 01:31:44 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04446; Fri, 25 Aug 1995 01:31:36 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.53] (dial-cup2-23.iway.aimnet.com [204.118.88.53]) by aimnet.com (8.6.12/8.6.12) with SMTP id IAA28597; Thu, 24 Aug 1995 08:30:59 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 08:31:25 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: "Provider-based addresses" is bad terminology Cc: big-internet@munnari.OZ.AU Precedence: bulk Noel, At 11:03 PM 8/23/95, Noel Chiappa wrote: >By calling it "provider-based addressing", we are causing people to have the we're causing people to have exactly the RIGHT model, otherwise they wouldn't have to change addresses when they change providers. Also we wouldn't have a problem with large-scale use of multi-homing (multiple providers). >In general, the model you need to work with is "if I can draw a circle around >a bunch of stuff on a map, it needs to have a single 'address' which can refer The debate is about the layout of the map. >A provider and their singly homed clients are *an example* of such an area, >but *not the only one*. Allocating a chunk of address space to an exchange >point, and the stuff hanging off it, is another example. This REQUIRES that the exchange points be common points in the topology, "up stream". Still doesn't handle aggressive multi-homing. >As a final aside, I always refer to this approach as "topologically sensitive Provider-based highlights the requirement for renumbering when you change providers. Topologically sensitive highlights the failure to handle multi-homing well. The former term is limited but reasonably accurate. The latter term is accurate in describing a large portion (maybe even the bulk) of the Internet today but elides fundamental realities which were highlighted by Bill Mannings comments over the last few days, concerning public vs. private networks. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 02:07:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05872; Fri, 25 Aug 1995 02:07:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA05118; Fri, 25 Aug 1995 02:05:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA04999; Fri, 25 Aug 1995 01:30:53 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04419; Fri, 25 Aug 1995 01:30:49 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.53] (dial-cup2-23.iway.aimnet.com [204.118.88.53]) by aimnet.com (8.6.12/8.6.12) with SMTP id IAA28442; Thu, 24 Aug 1995 08:30:13 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 08:30:40 -0700 To: Noel Chiappa From: Dave Crocker Subject: Re: Comments on draft-ietf-cidrd-ownership-01.txt Cc: Big-Internet@munnari.OZ.AU, IETF@cnri.reston.va.us, cidrd@iepg.org, inet-access@earth.com, nanog@merit.edu Precedence: bulk Noel, I see that you copied all of the lists. In my original posting to them I requested that discussion move to the cidrd mailing list. Folks should send to majordomo@iepg.org and have subscribe cidrd in the body. I request that you and other responders follow up to cidrd (after reading my retort...) In reply to your message stating: > addressing. It then, incorrectly, asserts that the Internet topology > >Well, in fact it says that "the topology of the network is not strictly The statement in the ownership draft you quote is an afterthought completely offset by the bulk of the draft. My comments draft mentions that quote (and dismisses it.) Please re-read both documents more carefully. >You appear to have missed the distinction between a hierarchical topology, and >an address hierarchy. One can apply hierarchical addressing to a perfectly No, that's exactly what CIDR has gotten wrong. It uses an imaginary topological hierarchy to define the address hierarchy. As a result of this confusion it handles multi-homing in a fashion which does not scale and which requires users and intermediate providers to renumber every time they change suppliers. How would YOU like to change phone numbers every time you change long-distance carriers? >The point remains that use of hierarchical addressing is the *only* way known Noel, I LIKE hierarchical addressing. The problem is with the current choice of hierarchy made by cidr. >that an addressing hierarchy that is loosely isomorphic to the connectivity Too loose for comfort, Noel. Our pants are starting to fall down. >Renumbering is indeed painful. However, given past decisions, no other option CIDR was chosen, yes. Consideration of alternatives was terminated. After initial success, CIDR is now failing. The Leasing proposal is part of an effort to save cidr, but at the expense of intolerable effects on much/most of the Internet's participants. Time to review the alternatives. Multi-homing and renumbering issues make cidr just as experimental as the alternatives. Hmmm. Perhaps not. We KNOW cidr has show-stopping problems. > It is time to consider alternatives to CIDR. > >Unfortunately, it's too late to consider alternatives. The Internet has a real >problem with routing table growth. To get something organized (since the Noel, this was the claim 3 years ago, too. It's time to stop letting that line of crisis abuse be used on the community. We need to focus on finding a mechanism that works. > After some considerable initial success it is proving inadequate. > >No, it's perfectly adequate, just painful. However, no other tool is available The effect of the requirement for large-scale and REPEATED renumbering is considerably worse than just painful. The failure to handle large-scale multi-homing is considerably worse than just painful. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 02:28:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06784; Fri, 25 Aug 1995 02:28:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA05179; Fri, 25 Aug 1995 02:25:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA05162; Fri, 25 Aug 1995 02:11:25 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB06037; Fri, 25 Aug 1995 02:11:12 +1000 (from bmanning@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Thu, 24 Aug 1995 09:10:47 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199508241610.AA04295@zephyr.isi.edu> Subject: Re: IP Encapsulation Growth Proposal To: sob@newdev.harvard.edu (Scott Bradner) Date: Thu, 24 Aug 1995 09:10:47 -0700 (PDT) Cc: doleary@cisco.com, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <199508241212.IAA06895@newdev.harvard.edu> from "Scott Bradner" at Aug 24, 95 08:12:33 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 305 Precedence: bulk > > > That will work just fone for IPv6 ... (renumbering technology) > > a new mailing list was just announced by Bill manning to look into > this issue for IPv4 > > pier-request@isi.edu to subscribe > > Scott > One hopes that the methods developed for IPv4 would be applicable to IPv6. -- --bill From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 02:34:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07124; Fri, 25 Aug 1995 02:34:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA05202; Fri, 25 Aug 1995 02:32:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA05146; Fri, 25 Aug 1995 02:10:00 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06021; Fri, 25 Aug 1995 02:09:49 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.53] (dial-cup2-2.iway.aimnet.com [204.118.88.32]) by aimnet.com (8.6.12/8.6.12) with SMTP id JAA04069; Thu, 24 Aug 1995 09:09:18 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 09:09:45 -0700 To: Yakov Rekhter From: Dave Crocker Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk At 6:47 AM 8/24/95, Yakov Rekhter wrote: >In the current Internet there is no such thing as the "core". So >the notion of partitioning the "core" is not applicable. The current cidr scheme specifies a derivable addressing hierarchy, coming through a set of providers. I believe this set is the same as applies to any discussion of an encaps scheme. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 02:47:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07633; Fri, 25 Aug 1995 02:47:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA05238; Fri, 25 Aug 1995 02:45:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA05189; Fri, 25 Aug 1995 02:28:47 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06789; Fri, 25 Aug 1995 02:28:22 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id MAA08088; Thu, 24 Aug 1995 12:28:32 -0400 (EDT) Date: Thu, 24 Aug 1995 12:28:32 -0400 (EDT) From: Scott Bradner Message-Id: <199508241628.MAA08088@newdev.harvard.edu> To: bmanning@ISI.EDU, sob@newdev.harvard.edu Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU, doleary@cisco.com, kre@munnari.OZ.AU Precedence: bulk > One hopes that the methods developed for IPv4 would be applicable to IPv6. learning is a good thing :-) Scott From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 04:08:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10977; Fri, 25 Aug 1995 04:08:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA05365; Fri, 25 Aug 1995 04:05:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA05356; Fri, 25 Aug 1995 04:04:14 +1000 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10671; Fri, 25 Aug 1995 04:03:57 +1000 (from kre) Date: Fri, 25 Aug 1995 04:03:57 +1000 From: Robert Elz Message-Id: <9508241803.10671@munnari.oz.au> To: yakov@cisco.com Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk Message-Id: <199508241347.GAA13849@hubbub.cisco.com> Date: Thu, 24 Aug 95 06:47:15 PDT From: Yakov Rekhter In the encaps model there is a notion of the "core". The "core" is not an entity that exists, it is a description of a part of the net. It exists now, it just doesn't have the label. In fact, that it exists now is part of the definition of the proposal, the plan is to alter the boundaries of that part that now exists. If a provider is attached to the "core" at more than one point (multihomed provider), and if the "core" partitions (so that one attachement point is in one partition, and the other attachment point is in another), then only a subset of the "core" (and therefore the destinations connected through the "core") would be reachable through a particular attachment point. So happens now. Such a provider is necessarily using default routing (or in the encaps model, they are part of the "core"). Using default routing, with the current cidr model, sending to an attatchment point that is not connected to all the rest of the net will result in sending to a black hole, just the same as it will in the new model. I am not aiming at improving this, which has been an artifact of using default routes ever since they were invented. That nothing is different here is not a surprise, there is no fundamental change to operations, just a different way to learn the paths in that part of the net we label the "core" (both now and later - and if I choose to label some part of the net "core" now, that you don't like the term doesn't change that I use it). As we all know, "the evil is in the details". Too true. As I said before, I am looking forward to see specifications. When (if) we get some kind of rough consensus that the model has at least the appearance (possibility) of some potential, and that no-one sees any fatal flaws. If Noel and Tony are right that no matter how quickly we attempt to get this done, it cannot be quick enough to be useful, then frankly, I have better things to do with my time. Sim if there is some other basic problem. At the minute I can't see how timing can be a real problem (the net will have to be funictioning with or without this work), and don't yet see any fundamental flaws, but it has only been on this list a day or two. kre From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 04:27:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11794; Fri, 25 Aug 1995 04:27:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA05432; Fri, 25 Aug 1995 04:25:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA05417; Fri, 25 Aug 1995 04:19:19 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11508; Fri, 25 Aug 1995 04:19:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09153; Thu, 24 Aug 95 14:18:59 -0400 Date: Thu, 24 Aug 95 14:18:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508241818.AA09153@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk > Geographic addressing only works by constraining the topology. I'm talking about geographic addressing as a proposal for address assignment in the network, not geographic addressing in general. We aren't designing a road network. you mean the way that our national and local road system is constrained? Well, last time I looked, it wasn't possible to unplug I-95 from Boston and plug it into San Francisco. On the other hand, you can move DS3 lines around. Noel From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 04:47:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12793; Fri, 25 Aug 1995 04:47:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA05474; Fri, 25 Aug 1995 04:45:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA05468; Fri, 25 Aug 1995 04:43:31 +1000 From: bound@zk3.dec.com Received: from mail2.digital.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12638; Fri, 25 Aug 1995 04:43:21 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA09085; Thu, 24 Aug 1995 11:30:42 -0700 Received: by xirtlu.zk3.dec.com; id AA19545; Thu, 24 Aug 1995 14:30:35 -0400 Message-Id: <9508241830.AA19545@xirtlu.zk3.dec.com> To: bmanning@ISI.EDU (Bill Manning) Cc: sob@newdev.harvard.edu (Scott Bradner), doleary@cisco.com, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Thu, 24 Aug 95 09:10:47 PDT." <199508241610.AA04295@zephyr.isi.edu> Date: Thu, 24 Aug 95 14:30:29 -0400 X-Mts: smtp Precedence: bulk >One hopes that the methods developed for IPv4 would be applicable >to IPv6. No way. IPv6 should be more advanced. Clearly renumbering is part of the IPv6 capability. /jim From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 05:08:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13646; Fri, 25 Aug 1995 05:08:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA05517; Fri, 25 Aug 1995 05:05:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA05494; Fri, 25 Aug 1995 04:48:24 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12813; Fri, 25 Aug 1995 04:48:10 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id OAA08623; Thu, 24 Aug 1995 14:48:13 -0400 (EDT) Date: Thu, 24 Aug 1995 14:48:13 -0400 (EDT) From: Scott Bradner Message-Id: <199508241848.OAA08623@newdev.harvard.edu> To: bmanning@ISI.EDU, bound@zk3.dec.com Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU, doleary@cisco.com, kre@munnari.OZ.AU, sob@newdev.harvard.edu Precedence: bulk > No way. IPv6 should be more advanced. Jim, I would hope that the new mailing list will also be looking at aspects of renumbering in addition to dealing with the hosts. IPv6 autoconf etc does not currentlly try and deal with renumbering routers, DHCP servers and the like. Scott From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 05:10:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13716; Fri, 25 Aug 1995 05:10:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA05541; Fri, 25 Aug 1995 05:08:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA05497; Fri, 25 Aug 1995 04:50:06 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12953; Fri, 25 Aug 1995 04:49:54 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id LAA09559; Thu, 24 Aug 1995 11:49:45 -0700 Message-Id: <199508241849.LAA09559@hubbub.cisco.com> To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Fri, 25 Aug 95 04:03:57 +0900." <9508241803.10671@munnari.oz.au> Date: Thu, 24 Aug 95 11:49:44 PDT From: Yakov Rekhter Precedence: bulk Robert, > So happens now. Does not have to happen now (see below). > Such a provider is necessarily using default routing > (or in the encaps model, they are part of the "core"). Such a provider may certainly point a default to another provider, but it may also receive specific routes from the other provider. These specific routes allow for dynamic re-routing in presence of failures. On a related topic, it would help if you'll be able to state precisely the rules that are used to determine whether a router could be outside the "core", or whether it has to be within the "core". Yakov. From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 05:14:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13930; Fri, 25 Aug 1995 05:14:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA05574; Fri, 25 Aug 1995 05:12:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA05513; Fri, 25 Aug 1995 05:03:14 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13449; Fri, 25 Aug 1995 05:02:56 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.54] (dial-cup2-28.iway.aimnet.com [204.118.88.58]) by aimnet.com (8.6.12/8.6.12) with SMTP id MAA21323; Thu, 24 Aug 1995 12:02:07 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 12:02:35 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk At 11:18 AM 8/24/95, Noel Chiappa wrote: >I'm talking about geographic addressing as a proposal for address assignment YOU might be talking about geographic addressing, but the CIDRD working group is NOT. Personally, I think a geographic scheme is exactly the right choice. As with any other scheme, it has some difficulties, but I've come to believe that the tradeoffs work better for it than for provider-based. >Well, last time I looked, it wasn't possible to unplug I-95 from Boston and >plug it into San Francisco. On the other hand, you can move DS3 lines >around. That's ok, Noel. We don't WANT 95. But the technical issues for doing road construction and the fact that one can remove and create communication (and airline) paths more easily than hard roadbed doesn't change the similarity of the models. Roads do come and go (so to speak) but rarely, if ever, cause an address to change. Simply put, addressing does NOT need to correlate highly with routing. It needs to permit reasonable aggregations for searching, but that's quite different. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 05:46:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15522; Fri, 25 Aug 1995 05:46:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA05635; Fri, 25 Aug 1995 05:45:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA05622; Fri, 25 Aug 1995 05:41:07 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15187; Fri, 25 Aug 1995 05:40:32 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17432 Fri, 25 Aug 1995 05:25:15 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.54] (dial-cup2-28.iway.aimnet.com [204.118.88.58]) by aimnet.com (8.6.12/8.6.12) with SMTP id MAA23044; Thu, 24 Aug 1995 12:17:35 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 12:18:02 -0700 To: bound@zk3.dec.com From: Dave Crocker Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 11:30 AM 8/24/95, bound@zk3.dec.com wrote: >No way. IPv6 should be more advanced. Clearly renumbering is part of >the IPv6 capability. not REPEATED renumbering, I hope. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 05:47:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15561; Fri, 25 Aug 1995 05:47:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA05659; Fri, 25 Aug 1995 05:46:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA05628; Fri, 25 Aug 1995 05:44:55 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB15417; Fri, 25 Aug 1995 05:44:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17280 Fri, 25 Aug 1995 05:19:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09531; Thu, 24 Aug 95 15:16:35 -0400 Date: Thu, 24 Aug 95 15:16:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508241916.AA09531@ginger.lcs.mit.edu> To: kre@munnari.OZ.AU, yakov@cisco.com Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz If Noel and Tony are right that no matter how quickly we attempt to get this done, it cannot be quick enough to be useful Well, I'm depending on others for an assessment of how soon we need something, and what I hear is "Yesterday". I cheerfully admit I'm not expert on that half of the equation. As to how long it would take such a solution to get done and deployed, there I feel competent to make an assessment, and I'd say two years minimum, because there are always lots of little nits you have to deal with here, and one thing we've all been glossing over in this disccussion is that translation from the IPv4 "address" (really more of an EID, with some local routing significance though) to the new topological-based address (presumably of the exit point). That's going to be a big table, it's going to have to have copies all over (since packets to a given destination can come from anywhere), it probably wants to be updated dynamically, etc, etc, etc. Not a weekend special. At the minute I can't see how timing can be a real problem (the net will have to be funictioning with or without this work) Exactly. And it's going to take renumbering to keep it going. Since at that point we've bitten the bullet, why waste extra energy going backward? Noel From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 05:48:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15603; Fri, 25 Aug 1995 05:48:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA05679; Fri, 25 Aug 1995 05:48:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA05608; Fri, 25 Aug 1995 05:32:56 +1000 From: bound@zk3.dec.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14685; Fri, 25 Aug 1995 05:31:28 +1000 (from bound@zk3.dec.com) Received: from mail2.digital.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17705 Fri, 25 Aug 1995 05:30:34 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA05998; Thu, 24 Aug 1995 12:15:11 -0700 Received: by xirtlu.zk3.dec.com; id AA20431; Thu, 24 Aug 1995 15:15:02 -0400 Message-Id: <9508241915.AA20431@xirtlu.zk3.dec.com> To: Scott Bradner Cc: bmanning@ISI.EDU, bound@zk3.dec.com, big-internet@munnari.OZ.AU, doleary@cisco.com, kre@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Thu, 24 Aug 95 14:48:13 EDT." <199508241848.OAA08623@newdev.harvard.edu> Date: Thu, 24 Aug 95 15:14:54 -0400 X-Mts: smtp Precedence: bulk Scott, I just joined that mailing list I think (bill I can't wait bound@zk3.dec.com). This is really important as one who is implementing renumbering in hosts (various specs have the aspect). One thing I just stated on cidr is that in IPv4 this will take time. First DHCPv4 needs to add the concept of the change to permit renumbering. DNSIND is another part that permits dynamic updates of DNS. For end-users (not vendors who can hack code to renumber quickly) to have products at a fast pace from the now just discussion additions to the IPv4 specs to fully tested deployed host products is most likely two years. We could have IPv6 on the street close to then if all really wanted to move as fast as possible at least for providers and what I will call border DHCPv6 and DNSINDv6 Host servers. But this will come on Bills list I sure (which I hope has other implementors and not just architects who don't look at code ever). So renumbering when you change providers with IPv6 will be much easier if that is the model of tomorrow. Providers who can avoid renumbering with a change will have a large part of the market for provider too. As far as routers I don't see them as a big player in the actual renumbering simply because they don't support the server software or are built to do what a high-end workstation server does. I do think with IPV6 ND and addrconf it can be made easier and routers clearly we decided will assist in renumbering that way. But thats for Bills list and I am not going to put the cycles here to get into it any further. /jim From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 05:50:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15675; Fri, 25 Aug 1995 05:50:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA05703; Fri, 25 Aug 1995 05:50:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA05625; Fri, 25 Aug 1995 05:43:25 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15258; Fri, 25 Aug 1995 05:42:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09669; Thu, 24 Aug 95 15:40:34 -0400 Date: Thu, 24 Aug 95 15:40:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508241940.AA09669@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu Subject: Re: "Provider-based addresses" is bad terminology Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Dave Crocker we're causing people to have exactly the RIGHT model, otherwise they wouldn't have to change addresses when they change providers. Pah. Then we'd better call street addresses "garbage-collection-service- based-addressing", since around here, when you move to a different township, you usually get a different (private) garbage hauler. > the model you need to work with is "if I can draw a circle around > a bunch of stuff on a map, it needs to have a single 'address' The debate is about the layout of the map. Huh? Last time I looked, the connetivity topology is what it is, and while you can chose to draw it in black ink or green, it won't change what is connected to what, and *that's* what's in the map I'm talking about. E.g. Sprint is connected to MCI as MAE-East, and you can draw the layout of the map any way you want, but unless it's *wrong*, it still has to show that as the place Sprint connects to MCI. > Allocating a chunk of address space to an exchange point, and the stuff > hanging off it, is another example. This REQUIRES that the exchange points be common points in the topology, "up stream". Huh? An exchange point is a common point between the entities which are connected to that exchange point. That's a tautology. My statement is isomorphic to saying "draw a circle around the exhange point and all the small things connected to it". Anyway, there is no "upstream"; you can draw the connectivity graph any way you like, and there is no direction to it. It's just a flat graph. The abstarction hierarchy has a "direction", yes, but the abstraction hierarchy is totally different from the topology. You seem to keep not keeping this in mind: let me send that IPv6 book chapter that explains the relationship between the two to the list. Provider-based highlights the requirement for renumbering when you change providers. You're looking at one aspect of what the user sees. I'd hope that the engineers who build the system have some idea how it works inside. Perhaps I'm being naive. I can't wait to see cars designed by people who don't know anything about engines, just care about how soft the seats are. Topologically sensitive highlights the failure to handle multi-homing well. No, it points out that if you multi-home in an unconstrainted way, there are costs for doing so in routing overhead. A system which limited multi-homing to a restricted scope of the topology would provide multihoming at a bounded cost. This statement of course is equally applicable to topologically sensitive address structures as well as geographic addressing. Noel From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 06:06:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16590; Fri, 25 Aug 1995 06:06:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA05738; Fri, 25 Aug 1995 06:05:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA05734; Fri, 25 Aug 1995 06:03:32 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16352; Fri, 25 Aug 1995 06:02:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09832; Thu, 24 Aug 95 16:01:27 -0400 Date: Thu, 24 Aug 95 16:01:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508242001.AA09832@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker YOU might be talking about geographic addressing, but the CIDRD working group is NOT. Yes, they've got too much sense. the fact that one can remove and create communication (and airline) paths more easily than hard roadbed doesn't change the similarity of the models It's easy to take two nodes in the network and make them direct neighbours. Try doing that with Boston and San Francisco. Roads do come and go (so to speak) but rarely, if ever, cause an address to change. Perhaps this is not unconnected with the fact that we haven't yet mastered the technology to fold and cut the earth's crust. Just a thought. Simply put, addressing does NOT need to correlate highly with routing. Sure, if you don't care about routign overhead. Heck, if you throw that out the window, we can use flat addressing. Everyone's IP address is a the bottom 32 bits of their Ehternet address. Problem solved. Dave, go study some routing papers. Try starting with Kleinrock. Here's the citation to get you started: [Kleinrock] Leonard Kleinrock and Farouk Kamoun, "Hierarchical Routing for Large Networks: Performance Evaluation and Optimization", Computer Networks 1 (1977), North-Holland Publishing Co., pp. 155- 174. It includes such topics as "finding an optimal clustering [i.e. addressing - JNC] structure". Noel From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 06:07:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16650; Fri, 25 Aug 1995 06:07:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA05760; Fri, 25 Aug 1995 06:07:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA05636; Fri, 25 Aug 1995 05:45:41 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15457; Fri, 25 Aug 1995 05:44:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09675; Thu, 24 Aug 95 15:43:53 -0400 Date: Thu, 24 Aug 95 15:43:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508241943.AA09675@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Abstraction Hierarchy Cc: jnc@ginger.lcs.mit.edu Precedence: bulk Here's the book section which describes it: ... The "address abstraction hierarchy" is what we call the organization of hierarchical topological units that are used in topological addresses. To give you a concrete example of this concept, if you look at the geographic equivalent, the geographic address abstraction hierarchy is the set of hierarchical geographical units - countries, states/provinces, cities, etc, etc - organized in a way which shows the relationships between them. Obviously, not all of these boundaries are of equal importance; a given set of state/province boundaries are in one country, etc, etc, and have a more local meaning and utility. So, you can draw a diagram of the "tree" of the geographic boundary hierarchy (much like the diagrams you may be familiar with, of tree-structured file systems), in which all the states/provinces which are part of one country are depicted underneath that country, connected to it, but "hanging" from it, and so on. The diagram starts from a base, the "root", under which are all the highest level entities; countries in this case. The ends of the lowest level branches, the "leaves", are individual geographic street addresses. The full hierarchical geographic address is given by concatenating the names of the geographic entities along the path from the root to the individual leaf. In an essentially identical manner, one can draw the address abstraction hierarchy for the topology of a communication network, with lower level entities (i.e. part of the network) hanging from the higher level entity (i.e. a larger part of the network) of which they are a part. The hierarchical address of a given place in that network is given by the concatenation of the names of the topological entities along the path from the root to the individual leaf. To make this more concrete, imagine drawing a map of the network (or at least a part of it) on a piece of paper. (Obviously, to draw a map of the whole network would take a very, very large piece of paper!) First, draw (probably in a separate color, to make it clearer) non-overlapping circles around small pieces of the network; these are the lowest level entities. Now, draw circles (again, in a different color) which include groups of the circles you drew previously. You have drawn a hierarchy of topological boundaries, just as state boundaries enclose groups of counties, etc. Noel From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 06:26:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17470; Fri, 25 Aug 1995 06:26:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA05810; Fri, 25 Aug 1995 06:25:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA05793; Fri, 25 Aug 1995 06:20:40 +1000 From: bound@zk3.dec.com Received: from mail2.digital.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17213; Fri, 25 Aug 1995 06:20:14 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA05734; Thu, 24 Aug 1995 13:13:10 -0700 Received: by xirtlu.zk3.dec.com; id AA21911; Thu, 24 Aug 1995 16:12:57 -0400 Message-Id: <9508242012.AA21911@xirtlu.zk3.dec.com> To: Dave Crocker Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Thu, 24 Aug 95 12:18:02 PDT." Date: Thu, 24 Aug 95 16:12:51 -0400 X-Mts: smtp Precedence: bulk > not REPEATED renumbering, I hope. I don't think in the norm, but only as the exception. /jim From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 06:45:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB18379; Fri, 25 Aug 1995 06:45:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA05848; Fri, 25 Aug 1995 06:45:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA05833; Fri, 25 Aug 1995 06:36:21 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB17966; Fri, 25 Aug 1995 06:36:18 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id NAA19105; Thu, 24 Aug 1995 13:33:29 -0700 Message-Id: <199508242033.NAA19105@hubbub.cisco.com> To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Thu, 24 Aug 95 16:12:51 EDT." <9508242012.AA21911@xirtlu.zk3.dec.com> Date: Thu, 24 Aug 95 13:33:29 PDT From: Yakov Rekhter Precedence: bulk Jim, > > > not REPEATED renumbering, I hope. > > I don't think in the norm, but only as the exception. Current IPv6 Address Allocation Architecture document assumes that if a site changes its providers the site has to renumber. Whether site changing its provider is viewed as a "norm" or as the "exception" is a matter of opinion. Yakov. From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 07:05:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19284; Fri, 25 Aug 1995 07:05:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA05901; Fri, 25 Aug 1995 07:05:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA05884; Fri, 25 Aug 1995 06:52:32 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18691; Fri, 25 Aug 1995 06:52:23 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 24 Aug 1995 16:52:14 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 24 Aug 1995 16:52:14 -0400 Received: from kasten.europa by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19657; Thu, 24 Aug 95 16:50:27 EDT Date: Thu, 24 Aug 95 16:50:27 EDT Message-Id: <9508242050.AA19657@mailserv-D.ftp.com> To: dcrocker@brandenburg.com, big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Thu Aug 24 16:50:20 1995] Originating-Client: europa Content-Length: 438 Precedence: bulk > Simply put, addressing does NOT need to correlate highly with routing. I believe that when the addressing architecture does not correlate highly with the packet switching architecture the packet switches are called bridges. -- Frank Kastenholz "The dogmas of the quiet past are inadequate to the stormy present... As our case is new, so we must think anew, and act anew" - A. Lincoln From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 07:25:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20053; Fri, 25 Aug 1995 07:25:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA05949; Fri, 25 Aug 1995 07:25:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA05943; Fri, 25 Aug 1995 07:25:06 +1000 Received: from valinor.barrnet.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20027; Fri, 25 Aug 1995 07:25:01 +1000 (from vaf@valinor.barrnet.net) Received: (from vaf@localhost) by valinor.barrnet.net (8.6.8/8.6.6) id OAA05396; Thu, 24 Aug 1995 14:23:26 -0700 Date: Thu, 24 Aug 95 14:23:26 PDT From: Vince Fuller To: bound@zk3.dec.com Cc: Dave Crocker , bound@zk3.dec.com, big-internet@munnari.OZ.AU Phone: (415) 528-7227 Usmail: 3801 East Bayshore Rd, Palo Alto, CA, 94303 Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of Thu, 24 Aug 95 16:12:51 -0400 Message-Id: Precedence: bulk > not REPEATED renumbering, I hope. I don't think in the norm, but only as the exception. OK, I'll bite: if IPv6 isn't going to require automatic, regular, repeated renumbering when networks move around in the topology? Exponential growth of 128-bit prefixes is certainly not going to be better than exponential growth of 32-bit prefixes. Have you found a better way to make routing scale than using hierarchical addressing? If so, I'm sure there is much fame and glory (not to mention riches) to be had. --Vince From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 08:05:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21485; Fri, 25 Aug 1995 08:05:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA05998; Fri, 25 Aug 1995 08:05:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA05981; Fri, 25 Aug 1995 07:47:50 +1000 Received: from valinor.barrnet.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20712; Fri, 25 Aug 1995 07:47:42 +1000 (from vaf@valinor.barrnet.net) Received: (from vaf@localhost) by valinor.barrnet.net (8.6.8/8.6.6) id OAA05487; Thu, 24 Aug 1995 14:49:13 -0700 Date: Thu, 24 Aug 95 14:49:13 PDT From: Vince Fuller To: big-internet@munnari.OZ.AU, bound@zk3.dec.com Phone: (415) 528-7227 Usmail: 3801 East Bayshore Rd, Palo Alto, CA, 94303 Subject: Re: IP Encapsulation Growth Proposal Message-Id: Precedence: bulk Hmm, it looks like I left off a phrase in my note. Here is is again. > not REPEATED renumbering, I hope. I don't think in the norm, but only as the exception. OK, I'll bite: if IPv6 isn't going to require automatic, regular, repeated renumbering when networks move around in the topology, then how is routing supposed to scale? Exponential growth of 128-bit prefixes is certainly not going to be better than exponential growth of 32-bit prefixes. Have you found a better way to make routing scale than using hierarchical addressing? If so, I'm sure there is much fame and glory (not to mention riches) to be had. --Vince From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 08:46:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23452; Fri, 25 Aug 1995 08:46:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA06056; Fri, 25 Aug 1995 08:45:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA06052; Fri, 25 Aug 1995 08:41:49 +1000 Received: from foobar.Ipsilon.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23148; Fri, 25 Aug 1995 08:41:37 +1000 (from hinden@ipsilon.com) Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id PAA12691; Thu, 24 Aug 1995 15:41:02 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 15:43:52 -0700 To: Robert Elz From: hinden@Ipsilon.COM (Bob Hinden) Subject: Re: IP Encapsulation growth proposal Cc: Big-Internet@munnari.OZ.AU Precedence: bulk kre, >Ah, no. Not that the proposal isn't basically the same, its >just that I didn't invent, or reinvent this - all I did here >was express it as a possibile way to move. I really hope I >didn't give the impression this was an idea I claimed any >rights over - I tried to avboid that. > >Thanks for sending (me) the IP Encaps draft - if we get to the >stage of deciding that this is worth pursuing (which largely >probably depends on an issue later in this message), then I >would suggest starting by re-issuing that draft, of course, >with you (Bob) remaining as author, if you're willing. To also be very clear, I am pleased to see you put this proposal forward. I would be happy to reissue the original document, update it with you as a co-author, or whatever seems appropriate. It strikes me after reading some of this discussion that there are common elements between encaps and cidr. They both attempt to create more scalable IPv4 routing by aggregation of routing information. This aggregation has both advantages and disadvantages. There are also some important differences between the two approaches. The most important IMHO is that cidr attempts to improve the efficiency by asking the edges (e.g., the users) to renumber while encaps attempts (via mapping) to renumber in the middle (e.g., backbones, DFZ, core, etc) without changing the edges. Bob From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 09:46:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26400; Fri, 25 Aug 1995 09:46:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA06132; Fri, 25 Aug 1995 09:45:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA06115; Fri, 25 Aug 1995 09:35:02 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25742; Fri, 25 Aug 1995 09:34:42 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23741 Fri, 25 Aug 1995 09:33:11 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzeft16545; Thu, 24 Aug 1995 19:29:06 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: IP Encapsulation Growth Proposal To: dcrocker@brandenburg.com (Dave Crocker) Date: Thu, 24 Aug 1995 19:29:06 -0400 (EDT) Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU In-Reply-To: from "Dave Crocker" at Aug 24, 95 12:18:02 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 241 Precedence: bulk > not REPEATED renumbering, I hope. And why not? Renumbering solves a lot of problems. IPv6 had better have as one of its goals really easy renumbering. Otherwise its just not going to cut it. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 10:26:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28629; Fri, 25 Aug 1995 10:26:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA06192; Fri, 25 Aug 1995 10:25:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA06175; Fri, 25 Aug 1995 10:11:31 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27691; Fri, 25 Aug 1995 10:09:25 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.com (aimnet.aimnet.com) by shark.mel.dit.csiro.au with SMTP id AA01930 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 25 Aug 1995 10:09:03 +1000 Received: from [204.118.88.30] (dial-cup1-30.iway.aimnet.com [204.118.88.30]) by aimnet.com (8.6.12/8.6.12) with SMTP id RAA19595; Thu, 24 Aug 1995 17:04:42 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 17:05:11 -0700 To: asp@uunet.uu.net (Andrew Partan) From: Dave Crocker Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 4:29 PM 8/24/95, Andrew Partan wrote: >> not REPEATED renumbering, I hope. > >And why not? Renumbering solves a lot of problems. IPv6 had better >have as one of its goals really easy renumbering. Otherwise its just >not going to cut it. well, Andrew, it's like this. With current technology, renumbering is very, very painful for end-user organizations. It is painful enough that an organization of any size will have to incur a very large internal operations expense, indeed, when changing providers. this constitutes a rather considerable disincentive to changing providers. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 10:47:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29825; Fri, 25 Aug 1995 10:47:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA06230; Fri, 25 Aug 1995 10:45:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA06212; Fri, 25 Aug 1995 10:27:03 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28565; Fri, 25 Aug 1995 10:24:43 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id UAA09932; Thu, 24 Aug 1995 20:24:28 -0400 (EDT) Date: Thu, 24 Aug 1995 20:24:28 -0400 (EDT) From: Scott Bradner Message-Id: <199508250024.UAA09932@newdev.harvard.edu> To: asp@uunet.uu.net, dcrocker@brandenburg.com Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com Precedence: bulk > IPv6 had better have as one of its goals really easy renumbering. it does, working out the details is the main thing that has delayed the final specs - we think it is rather important Scott From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 10:50:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29995; Fri, 25 Aug 1995 10:50:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA06256; Fri, 25 Aug 1995 10:48:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA06215; Fri, 25 Aug 1995 10:33:40 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28965; Fri, 25 Aug 1995 10:31:37 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzefx23409; Thu, 24 Aug 1995 20:25:36 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: IP Encapsulation Growth Proposal To: dcrocker@brandenburg.com (Dave Crocker) Date: Thu, 24 Aug 1995 20:25:36 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: from "Dave Crocker" at Aug 24, 95 05:05:11 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 2321 Precedence: bulk > well, Andrew, it's like this. With current technology, renumbering > is very, very painful for end-user organizations. It is painful enough > that an organization of any size will have to incur a very large internal > operations expense, indeed, when changing providers. this constitutes a > rather considerable disincentive to changing providers. Hey there - I was talking about IPv6, not IPv4. I know that current tools are nearly non existant. I hope that this changes & I really hope that IPv6 has its act together in the renumbering area. [If you are into business opportunities - here is one for you.] As far as size of organizations go, the greatest number of sites connected to the Internet are *small* (say way less than 100 hosts). Renumbering those sites is almost trivial. If we can get all of them to renumber when they connect or change providers, we have had a major major win. [We request that all new customers renumber into our space and all custmers that leave us to return their address space to us. We have fairly good complience with this. I would guess that just 5% of our new customers don't renumber into our space.] Btw, I just did some stats on current AlterNet customers to see how many are multihomed. Note I assumed that we are doing active routing with all of our multihomed customerrs and that we are doing active routing with just our multihomed customers. I assume that we have some multihomed customers that we are not doing active routing with (I don't know how they expect backup routing to correctly work, but..), and I know that we have a certain number of singly homed sites that we are doing active routing with (one of our current tasks is identifying those customers that we are doing active routing with that are just singly homed to us and turning off active routing with them). In any case, with the above assumptions, just 8% of our customers are multihomed. If I just look at our customers that are providers, then 32% of them are multihomed. If I just look at our customers that are not providers, then just 3% of them are multihomed. If we can come up with a solution that deals with the 92% of our customers that have no other connections, then we have a major major win in reducing the routing tables. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 11:06:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01160; Fri, 25 Aug 1995 11:06:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA06292; Fri, 25 Aug 1995 11:05:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA06288; Fri, 25 Aug 1995 11:01:05 +1000 Received: from cu.nih.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00728; Fri, 25 Aug 1995 10:59:28 +1000 (from RAF@CU.NIH.GOV) Message-Id: <9508250059.728@munnari.oz.au> To: asp@uunet.uu.net, dcrocker@brandenburg.com Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU From: "Roger Fajman" Date: Thu, 24 Aug 1995 20:57:04 EDT Subject: Re: IP Encapsulation Growth Proposal Precedence: bulk > > not REPEATED renumbering, I hope. > > And why not? Renumbering solves a lot of problems. IPv6 had better > have as one of its goals really easy renumbering. Otherwise its just > not going to cut it. > --asp@uunet.uu.net (Andrew Partan) It's a goal, but all the technology needed to make it really happen hasn't been developed yet. Address autoconfiguration and DNS dynamic update are steps in that direction, but are not enough by themselves. Discussion of what's needed should take place on the PIER list. From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 11:08:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01277; Fri, 25 Aug 1995 11:08:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA06314; Fri, 25 Aug 1995 11:07:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA06248; Fri, 25 Aug 1995 10:48:49 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29877; Fri, 25 Aug 1995 10:48:05 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id UAA09993; Thu, 24 Aug 1995 20:46:42 -0400 (EDT) Date: Thu, 24 Aug 1995 20:46:42 -0400 (EDT) From: Scott Bradner Message-Id: <199508250046.UAA09993@newdev.harvard.edu> To: asp@uunet.uu.net, dcrocker@brandenburg.com Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk Dave, *if* IPv6 has host renumbering that is almost painless (as is the intention) and the pier effort develops easy or easy-ish procedures for dealing with outher things (like routers & servers), *then* renumbering should not be a big deal. Andrew said "IPv6 had better have as one of its goals really easy renumbering." -- it does. The discussion we have been having on the cidrd & this list could be a whole lot less passioned if the cost of host renumbering were low to non existant and the cost of renumbering the rest of a site's infrastructure were reasonable. Scott From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 12:09:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04751; Fri, 25 Aug 1995 12:09:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA06397; Fri, 25 Aug 1995 12:06:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA06371; Fri, 25 Aug 1995 11:53:28 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03716; Fri, 25 Aug 1995 11:52:38 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29723 Fri, 25 Aug 1995 11:52:08 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzegd03842; Thu, 24 Aug 1995 21:50:52 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: CIDR savings for AlterNet To: big-internet@munnari.OZ.AU Date: Thu, 24 Aug 1995 21:50:52 -0400 (EDT) X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 367 Precedence: bulk I just did a bit more poking at our routing tables. Today, we have 3246 AlterNet routes w/in AlterNet. Of these, we send just 1113 out to the rest of the Internet - a savings of 2133 routes (or 66%). CIDR is working. [I need to look at the rest of our routes to see if they are aggregatable further - I suspect that more are.] --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 12:23:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05663; Fri, 25 Aug 1995 12:23:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA06434; Fri, 25 Aug 1995 12:20:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA06391; Fri, 25 Aug 1995 12:02:43 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04194; Fri, 25 Aug 1995 11:59:51 +1000 (from bsimpson@morningstar.com) Received: from LapTop.Simpson.DialUp.Mich.Net (pm012-23.dialip.mich.net [141.211.7.191]) by merit.edu (8.6.12/merit-2.0) with SMTP id VAA16201 for ; Thu, 24 Aug 1995 21:56:46 -0400 Date: Fri, 25 Aug 95 01:38:39 GMT From: "William Allen Simpson" Message-Id: <1447.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft Precedence: bulk > From: Robert Elz > When (if) we get some kind of rough consensus that the model has at > least the appearance (possibility) of some potential, and that no-one > sees any fatal flaws. If Noel and Tony are right that no matter how > quickly we attempt to get this done, it cannot be quick enough to be > useful, then frankly, I have better things to do with my time. Sim > if there is some other basic problem. At the minute I can't see how > timing can be a real problem (the net will have to be funictioning with > or without this work), and don't yet see any fundamental flaws, but > it has only been on this list a day or two. > Well, I see no fundamental flaws. Let me add to the rough consensus. As to time to field, I think that we are already on the way. When this was proposed before, there were no concrete plans for a world-wide database mapping IP numbers to AS numbers. Now, there is! We are well on our way to deploying the Policy Routing Database everywhere. It has all the information needed. It has an active maintainer. It would be easy to map the AS directly into a reserved set of 64K IP addresses, and periodically adjust every AS based on actual topology (which already has to be done for the PRDB). The lookups have to be done anyway for BGP, so there won't be any added latency. And, we get whatever benefits there are to adjustable policy as a side effect, too. So, let's hop to it! Shouldn't take more than a few weeks to code, and a month to test. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 12:27:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB05800; Fri, 25 Aug 1995 12:27:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA06480; Fri, 25 Aug 1995 12:25:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA06429; Fri, 25 Aug 1995 12:17:37 +1000 Received: from ns.iij.ad.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05149; Fri, 25 Aug 1995 12:16:34 +1000 (from davidc@iij.ad.jp) Received: from argus.iij.ad.jp (argus.iij.ad.jp [192.244.176.41]) by ns.iij.ad.jp (8.6.12+2.4W/3.3W9-NS) with SMTP id LAA02258; Fri, 25 Aug 1995 11:13:20 +0900 Message-Id: <199508250213.LAA02258@ns.iij.ad.jp> To: bound@zk3.dec.com Cc: Dave Crocker , big-internet@munnari.OZ.AU, davidc@ns.iij.ad.jp Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Thu, 24 Aug 1995 16:12:51 -0400." <9508242012.AA21911@xirtlu.zk3.dec.com> Date: Fri, 25 Aug 1995 11:14:53 +0900 From: David R Conrad Precedence: bulk >> not REPEATED renumbering, I hope. >I don't think in the norm, but only as the exception. Ummm. Why? Painless transparent renumbering solves a whole raft of problems. Why not design v6 renumbering with that goal in mind? If you don't make it easy, I would imagine the great unwashed out there won't do it and you'll run into the same problems you have trying to route v4... Regards, -drc it does. The discussion we have been having >on the cidrd & this list could be a whole lot less passioned if >the cost of host renumbering were low to non existant and the cost >of renumbering the rest of a site's infrastructure were reasonable. As you mention IPv6 does have the goal of easy renumbering and I think we have made considerable progress engineering the host part of renumbering (the hardest part I think) with the neighbor discovery work and the addressing architecture (e.g., nodes must be able to support multiple addresses, etc.). We also have a lot of ideas how to make it work over a complete site/organization using the IPv6 link local addresses. The use of the link-local addresses make it possible to renumber while maintaining host-router and router-router communication. So I think we have a good handle on IPv6 renumbering at the IP level and are getting it in all implementations from the start. We are also STRONGLY encouraging people working on higher level protocols which currently embed IPv4 addresses to NOT embed IPv6 addresses for the obvious reasons. Given that they have to be modified to support IPv6, there is some hope. There is still much work to be done in things like DNS, network management, how to tell the routers to stop/start advertising a prefix, etc. I agree that we are close to the goal of making the cost host renumbering non existand and other costs reasonable. I think we have learned from designing IPv6 renumbering that automatic renumbering is hard stuff but possible if it is done right from the start. What worries me about the discussion about IPv4 renumbering is without major changes/additions to IPv4 stacks automatic renumbering is not possible. Given the installed base of IPv4 (plus WIN95 shipping today w/ TCP/IP bundled), I don't think this kind of change (to IPv4 stacks) is going to happen. Bob From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 12:28:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05896; Fri, 25 Aug 1995 12:28:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA06494; Fri, 25 Aug 1995 12:26:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA06385; Fri, 25 Aug 1995 11:58:27 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03964; Fri, 25 Aug 1995 11:57:10 +1000 (from bsimpson@morningstar.com) Received: from LapTop.Simpson.DialUp.Mich.Net (pm012-23.dialip.mich.net [141.211.7.191]) by merit.edu (8.6.12/merit-2.0) with SMTP id VAA16197 for ; Thu, 24 Aug 1995 21:56:42 -0400 Date: Fri, 25 Aug 95 01:13:08 GMT From: "William Allen Simpson" Message-Id: <1446.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: Re: "Provider-based addresses" is bad terminology Precedence: bulk > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Huh? Last time I looked, the connetivity topology is what it is, and while you > can chose to draw it in black ink or green, it won't change what is connected > to what, and *that's* what's in the map I'm talking about. > You know, I do wish that you two (Noel and Dave) would quit agreeing with each other so Vehemently! Both of you seem to agree that it is the real topology that matters. Both of you agree that some amount of heirarchy is needed for scaling, although Dave has a tendency to look at the connecting points, and Noel the connection boundaries. There are many other agreements, just that you keep talking past each other with terminology. > E.g. Sprint is connected to MCI as MAE-East, and you can draw the layout of > the map any way you want, but unless it's *wrong*, it still has to show that > as the place Sprint connects to MCI. > Actually, Sprint is also connected to MCI at Chicago NAP, and probably many other places. That's why "provider-based" is utterly worthless as a topology assignment base, which is what Dave seems to be getting at. But, Noel agreed in his message (starting this subject). > Topologically sensitive highlights the failure to handle multi-homing > well. > > No, it points out that if you multi-home in an unconstrainted way, there are > costs for doing so in routing overhead. A system which limited multi-homing > to a restricted scope of the topology would provide multihoming at a bounded > cost. This statement of course is equally applicable to topologically > sensitive address structures as well as geographic addressing. > So, we all agree with this, too.... Multi-home has tradeoffs, depending on the topological "distance" of the disparate connections. For example, Arbornet (a local freenet BBS) is multihomed at MichNet and MSEN, which are mere physical (geographic) blocks apart. But MichNet is connected to MCInet (among others), and MSEN is connected to PSInet. Those two nets only peer in DC, 26 hops apart. Meanwhile, World Wide Access is multi-homed with MCInet and SprintNet. They peer in Chicago (which is also where WWA headquarters is located), a mere 2 hops apart. In fact, the WWA multihome is relatively useless topologically, as a connection directly to Chicago NAP would give the same effect. It does provide some redundancy when the Chicago NAP falls over (as it was doing on a regular basis). So, to have good topological numbering, Arbornet needs to get its address space from DC. WWA should get its address space from Chicago NAP. Instead, they each have addresses unrelated to any NAP or their "providers", and the routing is skewed. Perfect examples of why provider-based addresses don't work in a mesh (network). Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 12:31:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06029; Fri, 25 Aug 1995 12:31:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA06530; Fri, 25 Aug 1995 12:29:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA06414; Fri, 25 Aug 1995 12:10:09 +1000 Received: from relay2.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04676; Fri, 25 Aug 1995 12:08:43 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.com by relay2.UU.NET with SMTP id QQzege09528; Thu, 24 Aug 1995 22:07:42 -0400 Received: from [204.118.88.30] (dial-cup2-22.iway.aimnet.com [204.118.88.52]) by aimnet.com (8.6.12/8.6.12) with SMTP id TAA29537; Thu, 24 Aug 1995 19:02:45 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 19:03:14 -0700 To: Scott Bradner From: Dave Crocker Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk Scott, In reply to your message stating: > *if* IPv6 has host renumbering that is almost painless (as >is the intention) and the pier effort develops easy or easy-ish >procedures for dealing with outher things (like routers & servers), >*then* renumbering should not be a big deal. It certainly is more appealing. On continued thought, however, I find myself back to wondering whether it still doesn't handle multi-homing very well and I'd guess it will still hurt intermediate providers enormously. Given prevailing opinion, I'm no doubt wrong about this, but it would be helpful if someone took me (us) through the details that show how easy renumbering handles these two issues well. You see, I'm increasingly suspecting a case of mass hypnosis on the operational realities associated with this. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 12:50:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07096; Fri, 25 Aug 1995 12:50:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA06577; Fri, 25 Aug 1995 12:46:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA06572; Fri, 25 Aug 1995 12:44:55 +1000 From: presotto@plan9.att.com Received: from plan9.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06789; Fri, 25 Aug 1995 12:43:29 +1000 (from presotto@plan9.att.com) Message-Id: <9508250243.6789@munnari.oz.au> To: big-internet@munnari.OZ.AU Date: Thu, 24 Aug 1995 22:22:43 EDT Subject: numbering/address spaces Precedence: bulk Tell me to sod off if this is inappropriate for this list (and mention one it would be appropriate to). Assume: - a large telecommunications company is getting into the Internet business - it has a class A address - it wants to number its << 16 million SLIP/PPP customers using its Class A - a certain NIC told it to use its Class A or give it back. What could it do with its Class A address? CIDR would be nice but it seems meant for aggregating class C's and not for chunking up a Class A. Does anyone even support CIDR for Class A's? Multilevel subnetting seems doable using OSPF but this wastes a good chunk of the space. I also don't know who supports it. The only reference I found in a Cisco manual just said 'be careful'. Any suggestions? From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 12:55:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07429; Fri, 25 Aug 1995 12:55:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA06601; Fri, 25 Aug 1995 12:52:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA06556; Fri, 25 Aug 1995 12:35:07 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06304; Fri, 25 Aug 1995 12:34:30 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00335 Fri, 25 Aug 1995 12:03:42 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.30] (dial-cup2-22.iway.aimnet.com [204.118.88.52]) by aimnet.com (8.6.12/8.6.12) with SMTP id TAA29382; Thu, 24 Aug 1995 19:00:29 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 19:00:58 -0700 To: asp@uunet.uu.net (Andrew Partan) From: Dave Crocker Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 5:25 PM 8/24/95, Andrew Partan wrote: >> well, Andrew, it's like this. With current technology, renumbering > >Hey there - I was talking about IPv6, not IPv4. I know that current oh. I thought the discussion was about problems with cidr and CURRENT use of provider-based addresses. >If we can come up with a solution that deals with the 92% of our >customers that have no other connections, then we have a major major >win in reducing the routing tables. assuming the 8% holds -- which I expect it will not -- there are still two issues remaining. One is that 8% is becoming a very large number and the other is that doing something spiffy for 92% isn't good enough if you kill the 8%. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 12:57:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07533; Fri, 25 Aug 1995 12:57:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA06635; Fri, 25 Aug 1995 12:55:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA06570; Fri, 25 Aug 1995 12:42:46 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06387; Fri, 25 Aug 1995 12:36:11 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id WAA10340; Thu, 24 Aug 1995 22:36:07 -0400 (EDT) Date: Thu, 24 Aug 1995 22:36:07 -0400 (EDT) From: Scott Bradner Message-Id: <199508250236.WAA10340@newdev.harvard.edu> To: dcrocker@brandenburg.com, sob@newdev.harvard.edu Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk Dave, One basic question here is just what level of multi-homing there is and will be, not multi-homing within a provider (since that does not have a CIDR impact) but multi-homing with two (or more) providers. As was just pointed out by Andrew, the current level of multi-homing at the site level is quite low, many providers are multi-homed but not many sites. I would actually be kind of surprised if there were all that many, I don't think that many sites get multi-homed on their telephone service, some big ones do, but I don't think many small or medium sized one do. If there is not much site multi-homing then I don't see why one should spend a whole lot of effort on the issue. But in any case, there has been thought given to this in the IPng working group even if fully developed plans have not been made. A tactic that a number of people have suggested is to distribute the prefixes for both providers within the organization (since IPv6 supports multiple addresses per interface). There are some questions about how should a host select which address to use in the source field in the packet header and under what conditions could one preserve on-going sessions in the face of a failure of one or two links. These are open issues but not un-discussed. If the best we could do was to aggregate the routes for the customers of a provider and could not figure out a way to aggregate any providers, CIDR-style route aggregation would still be a very big win, providing (in the ideal case which one postulates IPv6 will be) reductions in the table size by an order of magnitude, and even in the non-ideal case that the current IPv4 world represents, CIDR has cut in half the size of the current routing table (according to the 29,000 Vs. 65,000 cidr FAQ). It would seem to me, even though I do not operate any networks, that cutting the table in half when basically no assignments older than 2 or 3 years can be aggregated is rather good proof of concept for CIDR. As is the news that Alternet is currently getting a 66% reduction in their routing advertisement. Things will only be better with IPv6 when renumbering is much easier. Scott From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 13:10:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08252; Fri, 25 Aug 1995 13:10:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA06662; Fri, 25 Aug 1995 13:06:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA06603; Fri, 25 Aug 1995 12:53:30 +1000 From: bound@zk3.dec.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07194; Fri, 25 Aug 1995 12:52:17 +1000 (from bound@zk3.dec.com) Received: from mail2.digital.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00799 Fri, 25 Aug 1995 12:16:39 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA30882; Thu, 24 Aug 1995 19:08:42 -0700 Received: by xirtlu.zk3.dec.com; id AA27242; Thu, 24 Aug 1995 22:08:40 -0400 Message-Id: <9508250208.AA27242@xirtlu.zk3.dec.com> To: Yakov Rekhter Cc: big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Thu, 24 Aug 95 13:33:29 PDT." <199508242033.NAA19105@hubbub.cisco.com> Date: Thu, 24 Aug 95 22:08:34 -0400 X-Mts: smtp Precedence: bulk Yakov, |> |> > not REPEATED renumbering, I hope. |> |> I don't think in the norm, but only as the exception. | >Current IPv6 Address Allocation Architecture document assumes that >if a site changes its providers the site has to renumber. Whether >site changing its provider is viewed as a "norm" or as the "exception" >is a matter of opinion. Well I understand that clearly and think the spec should move to proposed std but we lost that battle at Danvers I guess. But nothing in the spec prevents a provider being smart enough to make sure in the negotiations with a very large customer to work out a deal where the addresses do not have to be renumbered. Free enterprise so to speak. I also think the spec should maybe say that subscribers should be prepared to renumber rather than will have to, per the option I site above. /jim From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 14:12:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11295; Fri, 25 Aug 1995 14:12:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA06773; Fri, 25 Aug 1995 14:06:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06757; Fri, 25 Aug 1995 14:03:47 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10895; Fri, 25 Aug 1995 14:01:18 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04982 Fri, 25 Aug 1995 13:48:35 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzegl16010; Thu, 24 Aug 1995 23:45:32 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: CIDR savings for AlterNet To: dcrocker@brandenburg.com (Dave Crocker) Date: Thu, 24 Aug 1995 23:45:32 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: from "Dave Crocker" at Aug 24, 95 08:19:49 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 343 Precedence: bulk > Andrew, you've been citing statistics in some recent notes, all of > which have been snapshots. It's important to look for trends. If you want to see trends, then look at the info presented at the last few IETF on routing table sizes & address utilization. They also show that CIDR is working. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 14:32:54 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12362; Fri, 25 Aug 1995 14:32:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA06842; Fri, 25 Aug 1995 14:26:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06821; Fri, 25 Aug 1995 14:18:34 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11515; Fri, 25 Aug 1995 14:17:50 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06503 Fri, 25 Aug 1995 14:16:40 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzegm18852; Fri, 25 Aug 1995 00:13:24 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: "Provider-based addresses" is bad terminology To: bsimpson@MorningStar.Com (William Allen Simpson) Date: Fri, 25 Aug 1995 00:13:24 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <1446.bsimpson@morningstar.com> from "William Allen Simpson" at Aug 25, 95 01:13:08 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 402 Precedence: bulk > Actually, Sprint is also connected to MCI at Chicago NAP, and probably > many other places. That's why "provider-based" is utterly worthless as > a topology assignment base, which is what Dave seems to be getting at. Huh? This does not follow. I think that this shows just the opposite - that "provider-based" address allocation does work & works rather well. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 14:47:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13160; Fri, 25 Aug 1995 14:47:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA06875; Fri, 25 Aug 1995 14:42:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06818; Fri, 25 Aug 1995 14:16:33 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11387; Fri, 25 Aug 1995 14:15:15 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzegm18584; Fri, 25 Aug 1995 00:11:23 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: numbering/address spaces To: presotto@plan9.att.com Date: Fri, 25 Aug 1995 00:11:23 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9508250243.6789@munnari.oz.au> from "presotto@plan9.att.com" at Aug 24, 95 10:22:43 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 549 Precedence: bulk CIDR can also be used for carving up classical A/B/Cs into smaller pieces. Its being done now (several providers are allocationg sub-Cs to their customers; there is an experiment w/ net 39 being split amoung a number of providers). There are some folks collecting the experiences we have had so far w/ splitting net 39 up into smaller pieces. Contact the group at exp39@isi.edu. There is an RFC on this experiment (don't recall the exact refernece offhand) and there is a (draft?) rfc on carving up class As. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 14:53:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13502; Fri, 25 Aug 1995 14:53:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA06901; Fri, 25 Aug 1995 14:50:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06824; Fri, 25 Aug 1995 14:23:27 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11806; Fri, 25 Aug 1995 14:21:49 +1000 (from louie@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06266 Fri, 25 Aug 1995 14:11:31 +1000 (from louie@uunet.uu.net) Received: from localhost by rodan.UU.NET with SMTP id QQzegm18475; Fri, 25 Aug 1995 00:08:52 -0400 Message-Id: To: Dave Crocker Cc: asp@uunet.uu.net (Andrew Partan), big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Thu, 24 Aug 1995 17:05:11 PDT." Date: Fri, 25 Aug 1995 00:08:52 -0400 From: "Louis A. Mamakos" Precedence: bulk > At 4:29 PM 8/24/95, Andrew Partan wrote: > >> not REPEATED renumbering, I hope. > > > >And why not? Renumbering solves a lot of problems. IPv6 had better > >have as one of its goals really easy renumbering. Otherwise its just > >not going to cut it. > > well, Andrew, it's like this. With current technology, renumbering > is very, very painful for end-user organizations. It is painful enough > that an organization of any size will have to incur a very large internal > operations expense, indeed, when changing providers. this constitutes a > rather considerable disincentive to changing providers. So what's this got to do with IPv6, which is what Andrew's comment was about? I think we're all painfully aware of the difficulty of renumbering networks with today's technology. This is why it is important that IPv6 be able to do this painlessly and as simply as possible. louie From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 15:04:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14079; Fri, 25 Aug 1995 15:04:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA06932; Fri, 25 Aug 1995 15:01:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06787; Fri, 25 Aug 1995 14:08:59 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11108; Fri, 25 Aug 1995 14:07:13 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.com (aimnet.aimnet.com) by shark.mel.dit.csiro.au with SMTP id AA05434 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 25 Aug 1995 14:04:30 +1000 Received: from [204.118.88.30] (dial-cup2-6.iway.aimnet.com [204.118.88.36]) by aimnet.com (8.6.12/8.6.12) with SMTP id VAA10644; Thu, 24 Aug 1995 21:00:01 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 21:00:31 -0700 To: Scott Bradner From: Dave Crocker Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 7:36 PM 8/24/95, Scott Bradner wrote: >Dave, > One basic question here is just what level of multi-homing there is >and will be, not multi-homing within a provider (since that does not have a >CIDR impact) but multi-homing with two (or more) providers. Thank you. Yes. This is clearly a point of distinction in the stances. >but not many sites. I would actually be kind of surprised if there were >all that many, I don't think that many sites get multi-homed on their >telephone service, some big ones do, but I don't think many small or medium >sized one do. Except that the Internet isn't the phone system. Completely different operational models and VERY different operational track records. My own expectation is that medium-sized organizations and larger will tend to get multi-homed, in particular looking for the larges amount of path independence between the two (or more) providers to which they connect. d/ ps. just came across this on cidrd: >Date: Thu, 24 Aug 1995 20:06:35 -0700 (PDT) >From: Jim Dixon >To: Curtis Villamizar >cc: Dave Crocker , curtis@ans.net, cidrd@iepg.org >Subject: Re: ownership, leasing, renumbering, and that draft > ... >We are a second tier provider whose customers are largely small >ISPs in the UK and Ireland. Our experience as a provider installing >customers is that something like a third of recent customers are >dual homed and something under half of the rest are seriously >interested in becoming such. > >There is also, for what it's worth, quite serious resistance to >renumbering. But we all know that. >-- >Jim Dixon jdd@vbc.net >VP Engineering VBCnet West Inc 408 971 2682 fax 408 971 2684 -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 15:09:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14317; Fri, 25 Aug 1995 15:09:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA06951; Fri, 25 Aug 1995 15:06:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06826; Fri, 25 Aug 1995 14:24:05 +1000 From: bound@zk3.dec.com Received: from mail2.digital.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11477; Fri, 25 Aug 1995 14:16:54 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA04070; Thu, 24 Aug 1995 21:06:05 -0700 Received: by xirtlu.zk3.dec.com; id AA28331; Fri, 25 Aug 1995 00:06:03 -0400 Message-Id: <9508250406.AA28331@xirtlu.zk3.dec.com> To: Dave Crocker Cc: Scott Bradner , big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Thu, 24 Aug 95 19:03:14 PDT." Date: Fri, 25 Aug 95 00:05:57 -0400 X-Mts: smtp Precedence: bulk > Given prevailing opinion, I'm no doubt wrong about this, but it >would be helpful if someone took me (us) through the details that show how >easy renumbering handles these two issues well. You see, I'm increasingly >suspecting a case of mass hypnosis on the operational realities associated >with this. I am willing to do this on pier list. It can be done in IPv6 the piece of core technology we are missing is adding the initial addresses to the routers or dhcpv6 servers. Then using DNSIND from that vantage point so DNS I think is much further ahead than people realize and being implemented now. But if we can do autoconfiguration from the providers routers to init the process of renumbering that will work nice. Clearly as asp pointed out a new market for someone. I am being more positive than Bob I guess. ND was just one part of it lots of work has been going on parts that are not on the IPNG list only. It has been a point of architecture on DNS namedroppers for at least 9 months and DHCP wg list too. Addr conf is the base. Also pier-request list manager is out sick so none of us who requested today can get on the list yet fyi at isi. /jim From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 17:08:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03770; Fri, 25 Aug 1995 17:08:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA07116; Fri, 25 Aug 1995 17:06:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA07098; Fri, 25 Aug 1995 16:47:52 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02598; Fri, 25 Aug 1995 16:47:43 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch id AA16410; Fri, 25 Aug 1995 08:47:01 +0200 Received: by dxcoms.cern.ch id AA15001; Fri, 25 Aug 1995 08:46:59 +0200 Message-Id: <9508250646.AA15001@dxcoms.cern.ch> Subject: Re: IP Encapsulation Growth Proposal To: big-internet@munnari.OZ.AU (bigi) Date: Fri, 25 Aug 1995 08:46:58 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9508242012.AA21911@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Aug 24, 95 04:12:51 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 218 Precedence: bulk > > > > not REPEATED renumbering, I hope. > > I don't think in the norm, but only as the exception. > > /jim > If address configuration and deprecation, and dynamic DNS, work properly, who cares? Brian From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 17:16:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB04129; Fri, 25 Aug 1995 17:16:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA07151; Fri, 25 Aug 1995 17:12:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA07101; Fri, 25 Aug 1995 16:52:55 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02813; Fri, 25 Aug 1995 16:52:31 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch id AA18245; Fri, 25 Aug 1995 08:52:01 +0200 Received: by dxcoms.cern.ch id AA15332; Fri, 25 Aug 1995 08:51:59 +0200 Message-Id: <9508250651.AA15332@dxcoms.cern.ch> Subject: Re: IP Encapsulation Growth Proposal To: big-internet@munnari.OZ.AU (bigi) Date: Fri, 25 Aug 1995 08:51:59 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: from "Bob Hinden" at Aug 24, 95 06:56:34 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 756 Precedence: bulk Bob, > I think we have learned from designing IPv6 renumbering that automatic > renumbering is hard stuff but possible if it is done right from the start. > What worries me about the discussion about IPv4 renumbering is without > major changes/additions to IPv4 stacks automatic renumbering is not > possible. Given the installed base of IPv4 (plus WIN95 shipping today w/ > TCP/IP bundled), I don't think this kind of change (to IPv4 stacks) is > going to happen. > Win95 ships with PPP and with SLIP as an easy add-on (there even seems to be a free version). It also has DHCP and WinNT has a functional DHCP server. Win95 systems will mainly get their IP addresses dynamically, whichever ISP they connect to. I own no shares in Microsoft. Brian From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 17:41:26 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05864; Fri, 25 Aug 1995 17:41:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA09232 Fri, 25 Aug 1995 15:18:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA06963; Fri, 25 Aug 1995 15:09:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06815; Fri, 25 Aug 1995 14:12:57 +1000 From: bound@zk3.dec.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11280; Fri, 25 Aug 1995 14:11:53 +1000 (from bound@zk3.dec.com) Received: from mail2.digital.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04917 Fri, 25 Aug 1995 13:47:08 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA25305; Thu, 24 Aug 1995 20:22:44 -0700 Received: by xirtlu.zk3.dec.com; id AA27968; Thu, 24 Aug 1995 23:22:43 -0400 Message-Id: <9508250322.AA27968@xirtlu.zk3.dec.com> To: Vince Fuller Cc: big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Thu, 24 Aug 95 14:23:26 PDT." Date: Thu, 24 Aug 95 23:22:36 -0400 X-Mts: smtp Precedence: bulk Vince, | > not REPEATED renumbering, I hope. | | I don't think in the norm, but only as the exception. >OK, I'll bite: if IPv6 isn't going to require automatic, regular, repeated >renumbering when networks move around in the topology? Exponential growth >of 128-bit prefixes is certainly not going to be better than exponential >growth of 32-bit prefixes. If I had my way all MUSTs in the IETF and in the world would be stricken from all languages along with "I am sorry". But I don't seem to win those battles. I fully believe we must be able to automatically renumber private networks with IPv6. To avoid the exponential growth problems of 128 bit prefixes. What I do believe should be permitted is that providers who wish to make it so that a site does not have to renumber should be able to do so. So I am nervous about the word "require" above. But if I am with provider X and move to provider Y with IPv6 and they give me a new prefix in IPv6 as a customer I expect a painless effort to renumber to the new prefix. So yes to your question and I punt on require for now. Though its true that with Neighbor Discovery (ND), Address Configuration, DNSINDv6, and DHCPv6 have the underpinnings of renumbering. Integrating those together is an important task. For example there is no MUST in Address Configuration that a prefix provided by a router via ND/ICMPv6 to a host with an address must tell DNS about the address or that the router should have gotten the address from IP6.INT domain on DNS (where wildcard PTR records could exist etc...). The IETF have built the core standards to make it all possible. The market will have to make it really work. Will they make it work? If not the Internet is dead. And the IETF can do nothing about it. I think a group of vendors, architects, and providers could at that point, but I think then the government would step in. I prefer the vendors, architects, and providers to that. The issue for me with the draft in CIDR is not that it is technically wrong, but that there is another proposal on the table I would like to see discussed (in process), and that I simply do not like the discussion of the IETF saving the Internet from dying. We come here to work on standards and technical ideas not to save the worlds Internet. So if the Internet is in trouble which it is (though we have varying opinions on how much trouble) then lets see if we can find a technical solution. If all we come up with is a management solution I am just not clear the IETF has that charter. Recommendations are fine go for it. But I don't think we should standardize management of the Internet decisions. Make it a BCP or something. >Have you found a better way to make routing scale than using hierarchical >addressing? If so, I'm sure there is much fame and glory (not to mention >riches) to be had. No. Hierarchical routing is the best approach I know of but how one uses that structure can be done in many ways to reduce restructuring of the tree at the router. And I am thinking on that now. But I would prefer the money really, and I doubt I would do it for the world, Internet, or other altruistic reasons, and fame and glory are fruitless objectives that are not even born again in the spring. I would also do it simply because I feel like it. I also have ideas in IPv6 how providers could do what I stated in the 1st paragraph. I have also been around long enough that CIDR has me nervous in general as its not to exact. First we have two conflicting reports on when CIDR will run out of IPv4 address space. One even says +/- 8 years which my scientfic training tells me to throw that experiment away. Then I hear about two months ago we could be out of Class C address space in 18 months via a rumor mill. Now we have another problem and CIDR now needs to specifiy a BCP (at least I hope thats all it is). In private enterprise if this happens we usually ask the architects to go back to the drawing board and bring in some new architects for that work too. So I am totally confused and not sure I trust anything about CIDR right now, I just don't know. But I am sure not going to support any mandates from it right now that I do know. /jim From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 17:41:59 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB05900; Fri, 25 Aug 1995 17:41:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06168 Fri, 25 Aug 1995 14:08:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA06755; Fri, 25 Aug 1995 14:03:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA06715; Fri, 25 Aug 1995 13:42:10 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10051; Fri, 25 Aug 1995 13:42:05 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04350 Fri, 25 Aug 1995 13:35:50 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.30] (dial-cup2-6.iway.aimnet.com [204.118.88.36]) by aimnet.com (8.6.12/8.6.12) with SMTP id UAA08301; Thu, 24 Aug 1995 20:32:41 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 20:33:11 -0700 To: "William Allen Simpson" From: Dave Crocker Subject: Re: "Provider-based addresses" is bad terminology Cc: big-internet@munnari.OZ.AU Precedence: bulk At 6:13 PM 8/24/95, William Allen Simpson wrote: >You know, I do wish that you two (Noel and Dave) would quit agreeing >with each other so Vehemently! ok. if you insist. >Both of you seem to agree that it is the real topology that matters. well, no we don't. Topology is certainly important for routing and topology is "relevant" for addressing. But my own belief is that the best middle ground for addressing is a scheme which is primarily geographic. >Actually, Sprint is also connected to MCI at Chicago NAP, and probably >many other places. That's why "provider-based" is utterly worthless as yup. >So, we all agree with this, too.... Multi-home has tradeoffs, depending in the current scheme, it doesn't have trade-offs. it has losses. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 17:42:47 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05957; Fri, 25 Aug 1995 17:42:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05088 Fri, 25 Aug 1995 13:51:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA06719; Fri, 25 Aug 1995 13:46:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA06701; Fri, 25 Aug 1995 13:33:58 +1000 Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09582; Fri, 25 Aug 1995 13:33:15 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.com by relay1.UU.NET with SMTP id QQzegk03751; Thu, 24 Aug 1995 23:33:13 -0400 Received: from [204.118.88.30] (dial-cup2-6.iway.aimnet.com [204.118.88.36]) by aimnet.com (8.6.12/8.6.12) with SMTP id UAA06288; Thu, 24 Aug 1995 20:19:19 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 20:19:49 -0700 To: asp@uunet.uu.net (Andrew Partan) From: Dave Crocker Subject: Re: CIDR savings for AlterNet Cc: big-internet@munnari.OZ.AU Precedence: bulk At 6:50 PM 8/24/95, Andrew Partan wrote: >CIDR is working. Andrew, you've been citing statistics in some recent notes, all of which have been snapshots. It's important to look for trends. In this last case the issue is not whether cidr is providing current benefit, but rather whether its trend of savings is being maintained (or improved.) The statements on the cidrd list -- and the very explicit reason for the leasing proposal -- is the observation that cidr benefits are flattening out or being reduced. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 17:48:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06196; Fri, 25 Aug 1995 17:48:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA07200; Fri, 25 Aug 1995 17:46:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA07194; Fri, 25 Aug 1995 17:40:44 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05827; Fri, 25 Aug 1995 17:40:38 +1000 (from avg@sprint.net) Received: from titan.sprintlink.net by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14781 Fri, 25 Aug 1995 17:40:02 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id DAA23138; Fri, 25 Aug 1995 03:38:18 -0400 Date: Fri, 25 Aug 1995 03:38:18 -0400 From: Vadim Antonov Message-Id: <199508250738.DAA23138@titan.sprintlink.net> To: big-internet@munnari.OZ.AU, presotto@plan9.att.com Subject: Re: numbering/address spaces Precedence: bulk Splitting class A will work with (at least) cisco equipment (with "ip classless" statement in the configuration). I'm not sure about OSPF but IGP-level aggregation is certainly doable with I-ISIS, like i did in SprintLink backbone, using "redistribute static" filtered by a route-map. Anyway, having a class A is probably an overkill and it would be a really good deed to return it to InterNIC and get a smaller-sized sub-block instead. Also, as nobody yet came up with a working solution for large-scale portable IP addreses for dialup IP it makes sense to explore dynamic addressing (IPCP address negotiation in PPP), and so reduce the number of addresses to the number of ports. This requires using POP instead of SMTP, etc, which is probably ok for the target market (people with pee-sees and macintrashes). --vadim PS. The term CIDR stands for "classless INTER-domain routing" and as such not directly applicable to interior routing. Nitpicking. Anyway, a proper host IP implementation in 90s should know nothing about "classes". ---ORIGINAL MESSAGE--- Tell me to sod off if this is inappropriate for this list (and mention one it would be appropriate to). Assume: - a large telecommunications company is getting into the Internet business - it has a class A address - it wants to number its << 16 million SLIP/PPP customers using its Class A - a certain NIC told it to use its Class A or give it back. What could it do with its Class A address? CIDR would be nice but it seems meant for aggregating class C's and not for chunking up a Class A. Does anyone even support CIDR for Class A's? Multilevel subnetting seems doable using OSPF but this wastes a good chunk of the space. I also don't know who supports it. The only reference I found in a Cisco manual just said 'be careful'. Any suggestions? From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 19:32:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11219; Fri, 25 Aug 1995 19:32:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA07339; Fri, 25 Aug 1995 19:26:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA07322; Fri, 25 Aug 1995 19:23:56 +1000 Received: from [132.30.140.5] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10796; Fri, 25 Aug 1995 19:23:09 +1000 (from bass@unix.lajes.af.mil) Message-Id: <9508250923.10796@munnari.oz.au> Received: by unix.lajes.af.mil (1.38.193.3/16.2) id AA00960; Fri, 25 Aug 95 10:13:06 +0100 From: Tim Bass Subject: Re: Comments on draft-ietf-cidrd-ownership-01.txt To: dcrocker@brandenburg.com (Dave Crocker) Date: Fri, 25 Aug 95 10:13:06 PST Cc: jnc@ginger.lcs.mit.edu, Big-Internet@munnari.OZ.AU, IETF@cnri.reston.va.us, cidrd@iepg.org, inet-access@earth.com, nanog@merit.edu In-Reply-To: ; from "Dave Crocker" at Aug 24, 95 8:30 am Mailer: Elm [revision: 70.85] Precedence: bulk Quote from Claude Chappe ( acknowledged invent of "far-writing" commonly know as the telegraph ) circa 1824; this quote is very relevant to the recent discussions on CIDRD-WG and the complete unwillingness of CIDRD-WG to consider alternatives to CIDR and renumbering... From Mr. Chappe ( a highly decorated Frenchman ): " The use of novel methods that modify established habits, often hurts the interests of those who profit the most from the older methods. Few people, with the exceptions of the inventors, are truely interested in helping projects succeed while their ultimate impact is still uncertain. ... Those in power will normally make no effort to support a new invention, unless it can help them to augment their power; and even when they do support it, their efforts are usually insufficient to allow the new ideas to be fully exploited. " Reference: Holtzman, Pehrson _The Early History of Data Networks_, IEEE Press, AT&T, 1995. This statement in frustration by Mr. Chappe in 1824 summarizes the feelings of those who are well educated, experienced engineers that have introduced alternate ideas to the CIDRD-WG. VR, Tim Bass (still in the Azores for a few more days.... ) From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 20:28:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13998; Fri, 25 Aug 1995 20:28:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA07411; Fri, 25 Aug 1995 20:26:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA07394; Fri, 25 Aug 1995 20:18:40 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB13470; Fri, 25 Aug 1995 20:18:38 +1000 (from kre@munnari.OZ.AU) To: Yakov Rekhter Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 1995 11:49:44 PDT." <199508241849.LAA09559@hubbub.cisco.com> Date: Fri, 25 Aug 1995 20:18:15 +1000 Message-Id: <12627.809345895@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Thu, 24 Aug 95 11:49:44 PDT From: Yakov Rekhter Message-ID: <199508241849.LAA09559@hubbub.cisco.com> Such a provider may certainly point a default to another provider, but it may also receive specific routes from the other provider. These specific routes allow for dynamic re-routing in presence of failures. Yakov, there are absolutely no routing differences, none, whatever. In the period before we have a spec to examine the nits of, and work through the details, it seems to me that there are four things we need to consider. 1) Can we do this in time. 2) Is the benefit worth the cost 3) What is the effect on the routing sysem 4) What is the effect on the packet forwarding system 1) I think must be yes, because "in time" here really means "before the net dies". If the net has died (which you can define however you like, it doesn't matter) then all hope is lost, and that will have happened anyway. 2) is open for now. Obviously I believe it is worth the effort. 3) None whatever. I suspect that it is possible to prove (mathematically) that there is absolutely no difference whatever to internet routing (in terms of capabilities, the methods alter, as to the costs imposed, which is the rationale). Unfortunately doing so is outside my competence, but I can give a rough sketch. Consider that there are < 2^24 /24 prefixes possible in an IPv4 routing system (less because some of the prefixes are reserved). If we take one /8 prefix (10/8, or 223/8 or anything else) we have 2^24 - 2 available addresses (leaving out the prefix + 0 and the prefix + all 1's). Thus every possible IPv4 existing prefix can be mapped into a unique address from our new prefix. If we take those mapped addresses, and route using those we have the same routing system, exactly, as we had before, just with different bit patterns. Now we can choose the mapping function in order to make the routing using the new bit strings scale a lot better - in fact, to make it be able to scale exactly as well as we could make it if we were able to renumber every one of the connected IPv4 prefixes to the optimal value. The difference between the mapping scheme, and just CIDR (I say "just" as the mapping scheme used cidr techniques as well) is whereas both permit groups of nets to be aggregated into a single advertisment, the mapping scheme allows any group of nets to be aggregated, whereas cidr alone can only aggregate nets whose numbers fall into a power of two grouping (that is horrible terminology, I think you know what I mean, but I can't find the words to say that xxx.2/16 and xxx.3/16 can be aggregated into xxx.2/15 but xxx.3/16 and xxx.4/16 cannot (alone) be aggregated into anything at all). There need not be any difference to anything that routers can announce via any routing protocol, if a site needs to see announcements for some net prefix x.y.z/n then a router can see when a route to that prefix is available using either scheme. With pure cidr the route simply appears in the table. With mapping a route to the mapped value of x.y.z/n appears in the routing table. When either of those is true, the router can announce to its (local) peers the route to x.y.z/n. I think you can forget looking for routing loopholes with this scheme, I believe that any hard cases that you believe you have found work identically in the mapping scheme as they do with cidr alone. 4) forwarding - here there are differences. Differences relating to encapsulation techniques, MTU, TTL handling, ICMP handling, and end short circiuting the routing. Most of what those mean is pretty obvious I think - the last possibly deserves a little explanation. With current routing, a a packet entering the core will (probably) find a fairly generic route (a short prefix) to follow, and gradually move towards a point where longer prefixes exist, that is, more specific routes, where the destination is local. There is a chance that along that path, a router may happen to know, but not be advertising, a better route to the destination. In that case, as the packet passes that router, the packet can be extracted, and delivered more quickly. With the mapping scheme the ultimate destination won't be visible as the packet is moving through the core, only the entry point, so this kind of short cut isn't likely to work (it would be possible to configure it to do so I believe, but I don't believe this wacko case is really important enough to bother with). I believe that none of these differences is a show stopper, and that all of them can be handled. On a related topic, it would help if you'll be able to state precisely the rules that are used to determine whether a router could be outside the "core", or whether it has to be within the "core". I hope to be able to do so, as much as they are needed. Fortunately, just as with cidr, the definition of "core" is not, and need not be, rigid at all. There is plenty of room for flexibility (with cost/benefit trade offs) without breaking the scheme. kre From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 20:41:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14864; Fri, 25 Aug 1995 15:20:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA07002; Fri, 25 Aug 1995 15:12:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA06877; Fri, 25 Aug 1995 14:42:46 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12913; Fri, 25 Aug 1995 14:42:12 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzego23255; Fri, 25 Aug 1995 00:41:41 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: IP Encapsulation Growth Proposal To: sob@newdev.harvard.edu (Scott Bradner) Date: Fri, 25 Aug 1995 00:41:41 -0400 (EDT) Cc: dcrocker@brandenburg.com, sob@newdev.harvard.edu, big-internet@munnari.OZ.AU In-Reply-To: <199508250236.WAA10340@newdev.harvard.edu> from "Scott Bradner" at Aug 24, 95 10:36:07 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1242 Precedence: bulk Today there are just 816 ASs in the global Internet (at least that is all that I see). I rather suspect that my customer base (at est 8% multihomed) is rather atypical since I rather doubt that we have only 10,000 sites in the entire global Internet today. Say we double (or even triple) the number of multihomed sites. If every one of them has to add 1 route to the entire global Internet, big deal - that is still only another 1500 routes. So what. I am way more concerned about the huge number of singly homed sites - esp the small ones. We have a long way to go just doing more aggregation - we are at 30K routes today from just 816 ASs. If every customer of every AS could renumber into an AS-based address block, we would be down to just 816 routes. [Multihomed sites are treated as just another AS here - just like they are today.] If we could get the 'small' sites to renumber into AS-based blocks, we could get a long way towards our ideal. It would be interesting to figure out how many such 'small' sites there are out there (for some definition of 'small'). Anyone have any ideas of how to do this? The count of the number of /24s seen in today's routing tables is probably close. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 20:48:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14713; Fri, 25 Aug 1995 20:48:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA07451; Fri, 25 Aug 1995 20:46:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA07447; Fri, 25 Aug 1995 20:46:04 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14629; Fri, 25 Aug 1995 20:45:59 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id DAA07306; Fri, 25 Aug 1995 03:44:50 -0700 Date: Fri, 25 Aug 1995 03:44:50 -0700 From: Tony Li Message-Id: <199508251044.DAA07306@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: <12468.809266177@munnari.OZ.AU> (message from Robert Elz on Thu, 24 Aug 1995 22:09:37 +1000) Subject: Re: ownership, leasing, renumbering, and that draft Precedence: bulk Robert, Let's back up. As I understand it, in your scheme, there is a set of routers which have a table which contains every possible /24 prefix in the IPv4 address space. Is this correct? Tony From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 20:53:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14854; Fri, 25 Aug 1995 20:53:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA07476; Fri, 25 Aug 1995 20:51:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA07444; Fri, 25 Aug 1995 20:44:09 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14560; Fri, 25 Aug 1995 20:44:03 +1000 (from kre@munnari.OZ.AU) Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19780 Fri, 25 Aug 1995 20:43:41 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Thu, 24 Aug 1995 15:16:35 -0400." <9508241916.AA09531@ginger.lcs.mit.edu> Date: Fri, 25 Aug 1995 20:42:01 +1000 Message-Id: <12636.809347321@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Thu, 24 Aug 95 15:16:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9508241916.AA09531@ginger.lcs.mit.edu> As to how long it would take such a solution to get done and deployed, there I feel competent to make an assessment, and I'd say two years minimum, Now you've had one, two, and three, in different messages... because there are always lots of little nits you have to deal with here, Yes. and one thing we've all been glossing over in this disccussion is that translation from the IPv4 "address" (really more of an EID, with some local routing significance though) Unfortunately, no, not really. It would be nice if we could go that far, but that I don't think is doable at this stage. to the new topological-based address (presumably of the exit point). Approximately. That's going to be a big table, Its going to be a big something, a table seems likely to be the quickest to be able to make work. it's going to have to have copies all over (since packets to a given destination can come from anywhere), Absolutely - though fortunately, not consistently (ie: there is no requirement in this scheme for all entities to update tables at the same time). it probably wants to be updated dynamically, One day perhaps, not initially. etc, etc, etc. Not a weekend special. To get it done right, no, not a weekend special. To get it to a workable state, yes, I think a quicky will do. Then we can work on improving it once we have the experience to determine in what ways it is best to make the improvements. And it's going to take renumbering to keep [The Internet] going [until mapping is ready]. Since at that point we've bitten the bullet, why waste extra energy going backward? Renumbering isn't a bullet, its a million bullets, and they keep being shot out all the time, like forever, until the death of IPv4. We can probably convince the public to undergo some renumbering in order to keep the net functioning - the evidence supports that possibility. However I am not convinced we can keep doing that (at ever increasing rates - remember exponential growth) long enough (to the death of IPv4 do us part) that we can guarantee that we con continue to survive. Are you sure that we can keep on renumbering, and renumbering more, with IPv4, until we no longer need the protocol? Absolutely sure? Once the mapping scheme is deployed we can simply forget about renumbering for cidr type purposes. That will also mean that we can be even more agressive with cidr type number allocations, as getting a long prefix (at least up to a /24) will no longer have any negative impact at all - there will be no reason to demand that /19 and /20 prefixes be taken back and /18's allocated, or whatever. kre From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 22:28:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18304; Fri, 25 Aug 1995 22:28:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA07603; Fri, 25 Aug 1995 22:26:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA07588; Fri, 25 Aug 1995 22:14:23 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17593; Fri, 25 Aug 1995 22:14:17 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch id AA21806; Fri, 25 Aug 1995 14:13:55 +0200 Received: by dxcoms.cern.ch id AA25631; Fri, 25 Aug 1995 14:13:54 +0200 Message-Id: <9508251213.AA25631@dxcoms.cern.ch> Subject: just to muddy the waters To: big-internet@munnari.OZ.AU (bigi) Date: Fri, 25 Aug 1995 14:13:53 +0200 (MET DST) From: "Brian Carpenter CERN-CN" X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 873 Precedence: bulk It would be very nice if we could have a new subject field for discussing kre's proposal, to simplify life, since the same subject is being used over on cidrd for continued diatribes. What I really wanted to say is that one reason I don't treat Robert's proposal as utter drivel is that it does very much the same thing that I had in mind last year with the aeiou proposal (which used an IP option instead of encapsulation). Aeiou could be reworked to have about the same effect as encapsulation at the abstract level. I certainly support kre's assertion that the routing system and the deployment of CIDR are not affected one way or the other. Aeiou had disadvantages but it didn't create MTU size, TTL or ICMP problems. It shared the table distribution problem with kre's proposal. You can go back further in history and have another look at EIP (RFC 1385). Brian From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 22:50:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19072; Fri, 25 Aug 1995 22:50:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA07642; Fri, 25 Aug 1995 22:46:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA07625; Fri, 25 Aug 1995 22:37:47 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18518; Fri, 25 Aug 1995 22:37:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11608; Fri, 25 Aug 95 08:30:57 -0400 Date: Fri, 25 Aug 95 08:30:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508251230.AA11608@ginger.lcs.mit.edu> To: bass@unix.lajes.af.mil, dcrocker@brandenburg.com Subject: Re: Comments on draft-ietf-cidrd-ownership-01.txt Cc: Big-Internet@munnari.OZ.AU, IETF@cnri.reston.va.us, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tim Bass "The use of novel methods that modify established habits, often hurts the interests of those who profit the most from the older methods. Few people, with the exceptions of the inventors, are truely interested in helping projects succeed while their ultimate impact is still uncertain. ..." Indeed. A better summary of the attempts to introduce topology-based addresses into IPv4, in place of portable addresses (which no longer work in a network of this size), would be hard to find. Thanks for sending that along... Noel From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 23:09:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19690; Fri, 25 Aug 1995 23:09:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07686; Fri, 25 Aug 1995 23:06:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA07665; Fri, 25 Aug 1995 22:51:18 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19080; Fri, 25 Aug 1995 22:50:59 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id IAA23620 for ; Fri, 25 Aug 1995 08:50:26 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id IAA16107 for ; Fri, 25 Aug 1995 08:50:25 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA18672; Fri, 25 Aug 95 08:59:53 EDT Message-Id: <9508251259.AA18672@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 08:49:37 -0400 To: "William Allen Simpson" , big-internet@munnari.OZ.AU From: Robert Moskowitz Subject: Re: "Provider-based addresses" is bad terminology Precedence: bulk At 01:13 AM 8/25/95 GMT, William Allen Simpson wrote: > >> E.g. Sprint is connected to MCI as MAE-East, and you can draw the layout of >> the map any way you want, but unless it's *wrong*, it still has to show that >> as the place Sprint connects to MCI. >> >Actually, Sprint is also connected to MCI at Chicago NAP, and probably >many other places. That's why "provider-based" is utterly worthless as >a topology assignment base, which is what Dave seems to be getting at. According to com-priv discussions, they are connected at ALL of the NAPs and MAEs. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 23:11:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19859; Fri, 25 Aug 1995 23:11:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07710; Fri, 25 Aug 1995 23:08:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA07667; Fri, 25 Aug 1995 22:51:21 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19073; Fri, 25 Aug 1995 22:50:56 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id IAA23330 for ; Fri, 25 Aug 1995 08:48:41 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id IAA16093 for ; Fri, 25 Aug 1995 08:48:40 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA18664; Fri, 25 Aug 95 08:57:59 EDT Message-Id: <9508251257.AA18664@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 08:47:42 -0400 To: hinden@Ipsilon.COM (Bob Hinden), Scott Bradner From: Robert Moskowitz Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 06:56 PM 8/24/95 -0700, Bob Hinden wrote: > >I think we have learned from designing IPv6 renumbering that automatic >renumbering is hard stuff but possible if it is done right from the start. >What worries me about the discussion about IPv4 renumbering is without >major changes/additions to IPv4 stacks automatic renumbering is not >possible. Given the installed base of IPv4 (plus WIN95 shipping today w/ >TCP/IP bundled), I don't think this kind of change (to IPv4 stacks) is >going to happen. In IPv6 we constrained renumbering to occur without rebooting. In IPv4 it may be needed, and maybe not. In my WinNT 3.51 laptop, yesterday, I just changed my address and it broke all active connections, but immediately started using the new address without rebooting... Yes, this was a manual change, but the point is, the stack supports it. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 23:29:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20748; Fri, 25 Aug 1995 23:29:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07799; Fri, 25 Aug 1995 23:26:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07743; Fri, 25 Aug 1995 23:11:56 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19550; Fri, 25 Aug 1995 23:05:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11767; Fri, 25 Aug 95 09:02:49 -0400 Date: Fri, 25 Aug 95 09:02:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508251302.AA11767@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz > As to how long it would take such a solution to get done and deployed, > there I feel competent to make an assessment, and I'd say two years > minimum, Now you've had one, two, and three, in different messages... Well, it's not like a software engineering project in a company, where you have a well-defined design, etc, etc. There you can sit down and break it up into pieces, figure out how long each one will take with the manpower available, etc. Even there, with more clearly defined deal, you're probably off by a factor of two. The variance depends on whether I'm thinking of a typical IETF project (how long did it take to get CIDR out, or IPv6 for that matter - it's already a year and we had a fair amount of stuff going into Toronto last summer), which is where you get numbers like 3 years, or an absolute "do-or-die" project by a small numebr of vendors outside the IETF process (like SGMP) which is where you get one year. > translation from the IPv4 "address" .. to the new topological-based > address (presumably of the exit point). Approximately. Yakov and I talked about this last night, whether to make the output of the translation table be an exit router, or the address of the destination aggregate, in a new topologically-oriented namspace. If you go the "exit router" path, then you have more or less exactly the same problems as running IP over a large WAN (without having the routers on the edge of the cloud communicate) so the references to ROLC when people think about this scheme are not surprising. For instance, suppose two different exit routers lead to the destination. How do you decide which one to pick? Presumably you'd like to add the metrics from the entrance router to the exit router, and from the exit router to the destination. Unfortunately, you don't know the latter. How about the case in which there are two exit routers, and one is down? How do you find that out? If you use something like ICMP, what's to stop denial-of-service attacks? Etc, etc, etc. So, my bias would be to map into a true address for the destination. (That also had problems, as I reacll, but I don't remember what they were. Yakov?) > That's going to be a big table, Its going to be a big something, a table seems likely to be the quickest to be able to make work. > it's going to have to have copies all over (since packets to a given > destination can come from anywhere), Absolutely - though fortunately, not consistently > it probably wants to be updated dynamically, One day perhaps, not initially. I'm not sure I believe that. It certainly has to be managed in a distributed fashion; i.e. there's no way we can do it with one giant table which everyone FTP's out every day. I think this may be the biggest stumbling block to simple table distribution schemes, actually. If you think otherwise; I have the *perfect* counterexample for you: the hostnames.txt file. We used to have a giant table (file) that mapped from hostnames to addresses. We don't any more, in par because maintaing that table in a centralized way didn't work. A table that maps from old-portable-addresses to new-topological-addresses is going to be no different, basically, from the host table, and we had to go to a distributed database. Been There, Done That. Of course, we could always keep the old-portable-addresses to new-topological-addresses in the DNS, and cache them in the routers for beter performance... :-) I wait with bated breath to hear how the people who didn't like EID's "because the mapping would be too expensive" do a very artistic and agile triple-back-flip and now come down in favor of such a mapping because they oppose getting rid of portable addresses... To get it done right, no, not a weekend special. To get it to a workable state, yes, I think a quicky will do. /etc/hosts, here were come! Back to the future! > And it's going to take renumbering to keep [The Internet] going [until > mapping is ready]. Since at that point we've bitten the bullet, why waste > extra energy going backward? Renumbering isn't a bullet, its a million bullets, and they keep being shot out all the time, like forever Oh, so I assume you oppose IPv6 because it assumes perennial renumbering (at least it seems to in some people's heads; there seems to be some debate over there)? My assumption is that renumbering will become less painful over time as i) we get rid of places where addresses are hard-coded in, and learn to avoid doing things like that, and ii) more tools become available to help with it. After all, we are goign to have to do this for IPv6, so we have to learn how to do it someday... We can probably convince the public to undergo some renumbering in order to keep the net functioning - the evidence supports that possibility. Well, I'm glad you think so; some opponents of CIDR don't feel that way. Are you sure that we can keep on renumbering, and renumbering more, with IPv4, until we no longer need the protocol? Absolutely sure? Well, whatever protocol we use in the future, the names used by the routing are going to have to change to stay "within touch" of the topology. I.e. you don't have to change the address hierarchy ever time there is a topology change, but to keep the routing overhead within bounds, eventually you will have to update the address hierarchy. "How close" will be close enough is hard to predict, given the likely arrival of multi-metric and user-driven routing... Noel From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 23:43:44 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21498; Fri, 25 Aug 1995 23:43:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23420 Fri, 25 Aug 1995 23:16:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07741; Fri, 25 Aug 1995 23:11:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA07662; Fri, 25 Aug 1995 22:48:34 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18909; Fri, 25 Aug 1995 22:48:05 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id IAA22512 for ; Fri, 25 Aug 1995 08:43:37 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id IAA15930 for ; Fri, 25 Aug 1995 08:43:36 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA18642; Fri, 25 Aug 95 08:52:58 EDT Message-Id: <9508251252.AA18642@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 08:42:42 -0400 To: Dave Crocker , asp@uunet.uu.net (Andrew Partan) From: Robert Moskowitz Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 05:05 PM 8/24/95 -0700, Dave Crocker wrote: >At 4:29 PM 8/24/95, Andrew Partan wrote: >>> not REPEATED renumbering, I hope. >> >>And why not? Renumbering solves a lot of problems. IPv6 had better >>have as one of its goals really easy renumbering. Otherwise its just >>not going to cut it. > > well, Andrew, it's like this. With current technology, renumbering >is very, very painful for end-user organizations. It is painful enough >that an organization of any size will have to incur a very large internal >operations expense, indeed, when changing providers. this constitutes a >rather considerable disincentive to changing providers. I ***LOVE*** this discussion. It is SSOOOO orientated to the typical utopian Internet global playground. Business are NOT going to just connect. Or rather, businesses of any size. They are firewalling. The good firewalls are proxy servers. The low risk ones are filters. Big corps that can't renumber and are multihomed are also those corps that will use proxy firewalls. Once you use a proxy firewall, there is no needed correspondance between the addresses within the corp and those seen by the public on the firewall. Check out JEEP.COM (just do a whois, not everything is working yet). Oh, there is another 'problem' with large, multi-homed corps and the internet. If those multihomes are to different connection points on the network, default routing internally does not work and most internal corp routers do not want to see the whole outside. Thus proxy firewalls are again a good choice. The BIG corps are the LEAST affected by all of this. BIG gov and edu are and of course they are the ones that have long known how to make noise and protect their interest in IETF discussions. NOTE: The petro industry is building a FAST private network. I am attending a demo of it on Sept 13th. The auto industry is designing a LARGE, potentially, private network. I wrote the white paper and it will be presented on Sept 19th. The winds of change are blowing, Dave. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 23:48:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21709; Fri, 25 Aug 1995 23:48:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07857; Fri, 25 Aug 1995 23:46:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07821; Fri, 25 Aug 1995 23:30:26 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20767; Fri, 25 Aug 1995 23:30:00 +1000 (from rgm3@is.chrysler.com) Received: from sg543689.eng.chrysler.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA22945 Fri, 25 Aug 1995 23:02:44 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id JAA25791 for ; Fri, 25 Aug 1995 09:01:17 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id JAA16299 for ; Fri, 25 Aug 1995 09:01:15 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA18777; Fri, 25 Aug 95 09:10:30 EDT Message-Id: <9508251310.AA18777@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 09:00:14 -0400 To: Dave Crocker , asp@uunet.uu.net (Andrew Partan) From: Robert Moskowitz Subject: Re: CIDR savings for AlterNet Cc: big-internet@munnari.OZ.AU Precedence: bulk At 08:19 PM 8/24/95 -0700, Dave Crocker wrote: >At 6:50 PM 8/24/95, Andrew Partan wrote: >>CIDR is working. > > Andrew, you've been citing statistics in some recent notes, all of >which have been snapshots. It's important to look for trends. > > In this last case the issue is not whether cidr is providing >current benefit, but rather whether its trend of savings is being >maintained (or improved.) The statements on the cidrd list -- and the very >explicit reason for the leasing proposal -- is the observation that cidr >benefits are flattening out or being reduced. That my be the way it degenerated. It started with an move to go after the hard part of the reduction of the legacy routing and to reduce any trend at breaking CIDR aggregation. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 23:52:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21831; Fri, 25 Aug 1995 23:52:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07882; Fri, 25 Aug 1995 23:50:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07827; Fri, 25 Aug 1995 23:35:05 +1000 Received: from ns.Newbridge.Com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21047; Fri, 25 Aug 1995 23:34:55 +1000 (from jhalpern@Newbridge.COM) Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id JAA04992; Fri, 25 Aug 1995 09:34:52 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma004982; Fri Aug 25 09:34:41 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id JAA01895; Fri, 25 Aug 1995 09:34:41 -0400 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA01612; Fri, 25 Aug 95 09:31:34 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA25233; Fri, 25 Aug 1995 09:33:50 +0500 Date: Fri, 25 Aug 1995 09:33:50 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9508251333.AA25233@lobster.Newbridge.COM> To: yakov@cisco.com, kre@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU X-Sun-Charset: US-ASCII Content-Length: 1390 Precedence: bulk Assuming that I have properly understood kre's proposal, the "core" would include anyone who is multi-homed and using routing to select which provider to reach. I infer this because only by using "core" routing on the envelope addresses, coupled with the mapping table, can one make a rational decision. If this is true, I believe that the "core" becomes exactly as large as the hard part of the CIDR space. As far as I can tell, the only people who do not have to be part of the core are the singly homed users. So, in the CIDR scheme there is pain on all users, due to re-numbering. Unfortunately, it appears that kre's scheme has a core which, in any reasonable projection, develops all of the problems of the current internet. Thus, it seems to me not to be worth it. For short term stuff, singly homed sites can usually (not always) deal with the renumbering pain. As Andrew has been pointing out, customers are doing the renumbering. And trying to have a flag-day transition in the internal routing of the internet seems a non-starter. I presume that with enough thought kre can find a way not to change over the whole core at once. But it appears to me that there is no benefit until everyone changes over. Until everyone changes over, you need all the old advertisements. A real transition mess. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 23:55:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22072; Fri, 25 Aug 1995 23:55:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07904; Fri, 25 Aug 1995 23:53:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07841; Fri, 25 Aug 1995 23:42:47 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21420; Fri, 25 Aug 1995 23:42:27 +1000 (from kre@munnari.OZ.AU) To: "Brian Carpenter CERN-CN" Cc: big-internet@munnari.OZ.AU (bigi) Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Fri, 25 Aug 1995 08:51:59 +0200." <9508250651.AA15332@dxcoms.cern.ch> Date: Fri, 25 Aug 1995 23:42:05 +1000 Message-Id: <12679.809358125@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Fri, 25 Aug 1995 08:51:59 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Message-ID: <9508250651.AA15332@dxcoms.cern.ch> Win95 systems will mainly get their IP addresses dynamically, whichever ISP they connect to. There's a lot more to automating renumbering than just obtaining addresses dynamically - that helps, but is only part of it. We also need addresses to be able to be deleted from running systems, which includes notifying running applications that the addresses they learned are no longer valid, and new ones should be obtained. This means new models for applications, it's not just a "fix the OS and the world is nice again" problem. Note that both kinds of addresses need to be able to be updated, that is, all local addresses need to be capable of being altered and applications that know those must be able to learn others. And remote addresses must be able to be seen to change, that's less mechanism, as DNS results already have TTLs - unfortunately current APIs (I haven't looked at IPv6's for this issue) don't bother to return the TTL to the application - this is an example of the assumed immutability of IP addresses (it is pervasive). To get reunmbering to be able to work we need new APIs and new applications to make use of them... wandering around rebooting all my systems when I have to renumber them is perhaps an onerous task that has to be undertaken - walking around rebooting them all when someone else renumbers is simply absurd. kre From owner-Big-Internet@munnari.OZ.AU Fri Aug 25 23:57:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22184; Fri, 25 Aug 1995 23:57:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA07939; Fri, 25 Aug 1995 23:55:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07824; Fri, 25 Aug 1995 23:32:22 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20962; Fri, 25 Aug 1995 23:32:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11910; Fri, 25 Aug 95 09:29:54 -0400 Date: Fri, 25 Aug 95 09:29:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508251329.AA11910@ginger.lcs.mit.edu> To: kre@munnari.OZ.AU, yakov@cisco.com Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz Can we do this in time. ... yes, because "in time" here really means "before the net dies". If the net has died ... then all hope is lost, and that will have happened anyway. There's a bug in your reasoning, which is that the net is in trouble now, but we do have a tool on the shelf - designed, documented, implemented and deployed - to fix it: topologically-based addresses. This tool is being taken off the shelf and used *as we speak*. The net won't die (at least from routing overload), even if we don't do your scheme. What is the effect on the routing sysem ... I suspect that it is possible to prove (mathematically) that there is absolutely no difference whatever Well, it depends. If all you have is stubs, with no alternate paths, yes. However, once you have private links, multi-homing, etc, etc, there are certain capabilities (such as optimal use of multiple links) which require the routers outside the "core" (i.e. the routers running your new system) to have a fair amount of routing information. This routing information has to come from inside the core. You now have two choices. First, you could translate back from your new topologically assigned space and inject data in the non-topological form into those outside routers that need it; i.e. there is a permeable barrier between the routing inside and outside the core. This may i) be difficult (since you have aggregates that don't have a single back-mapping), and ii) result in a lot of data (which is what we were trying to avoid to begin with). Second, you can make all such routers part of the "core"; i.e. once again making things outside it be only stubs. This also brings problems, since it lets all these customer routers in through what could have been a security barrier, etc, etc. With the mapping scheme the ultimate destination won't be visible as the packet is moving through the core, only the entry point Ah, so you are mapping to the exit point. What happens if it's down? How do you select among more than one possible one? I believe that none of these differences is a show stopper, and that all of them can be handled. Sure, but they will all take time to solve, and, as we have seen from IPv6, even a design that looks "done" can have over a year of tiny little "non- show-stoppers" that add up and up and up. Fortunately, just as with cidr, the definition of "core" is not, and need not be, rigid at all. There is plenty of room for flexibility ... without breaking the scheme. What?? Although it's a big nebulous in CIDR (and we have managed to work out a satisfactory definition of the "core" for the existing scheme - I like Steve's "connected graph of default-free routers"), it's quite a strict line here. You either participate in the routing in the "new-topogically-assigned" address space, or you don't. Very simple dividing line... Noel From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 00:08:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22960; Sat, 26 Aug 1995 00:08:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA07970; Sat, 26 Aug 1995 00:06:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07875; Fri, 25 Aug 1995 23:50:10 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21732; Fri, 25 Aug 1995 23:49:26 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch id AA01469; Fri, 25 Aug 1995 15:48:40 +0200 Received: by dxcoms.cern.ch id AA29379; Fri, 25 Aug 1995 15:48:37 +0200 Message-Id: <9508251348.AA29379@dxcoms.cern.ch> Subject: Re: IP Encapsulation Growth Proposal To: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 25 Aug 1995 15:48:37 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: big-internet@munnari.OZ.AU In-Reply-To: <12679.809358125@munnari.OZ.AU> from "Robert Elz" at Aug 25, 95 11:42:05 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 702 Precedence: bulk Robert, >--------- Text sent by Robert Elz follows: > > Date: Fri, 25 Aug 1995 08:51:59 +0200 (MET DST) > From: "Brian Carpenter CERN-CN" > Message-ID: <9508250651.AA15332@dxcoms.cern.ch> > > Win95 systems will mainly get their IP addresses dynamically, > whichever ISP they connect to. > > There's a lot more to automating renumbering than just obtaining > addresses dynamically - that helps, but is only part of it. I suggest taking this thread over the road (pun) to the pier list. You raise several valid points, although my main point was that millions of domestic users will get dynamic addresses as a matter of course. Brian From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 00:14:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23379; Sat, 26 Aug 1995 00:14:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA07994; Sat, 26 Aug 1995 00:09:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07962; Fri, 25 Aug 1995 23:59:46 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22243; Fri, 25 Aug 1995 23:59:38 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Discussing encap/mapping proposal In-Reply-To: Your message of "Fri, 25 Aug 1995 03:44:50 MST." <199508251044.DAA07306@greatdane.cisco.com> Date: Fri, 25 Aug 1995 23:59:12 +1000 Message-Id: <12684.809359152@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Fri, 25 Aug 1995 03:44:50 -0700 From: Tony Li Message-ID: <199508251044.DAA07306@greatdane.cisco.com> Subject: Re: ownership, leasing, renumbering, and that draft Note change of subject. Let's back up. As I understand it, in your scheme, there is a set of routers which have a table which contains every possible /24 prefix in the IPv4 address space. Is this correct? Approximately. What's actually required is a mapping from every existing advertised prefix. The "every possible /24" is an absolute upper bound on the size of the table, and also a possible implementation technique in the routers (not a requirement). And though you didn't expressly ask, the "set of routers" is those that accept packets from routers that have default routes, but which themselves don't have such routes. (Ie: this router has no /0 route, but receives packets from others that do). And to keep Yakov happy - other routers can have this table, that some set must doesn't imply others mustn't, those others can if they prefer, have a subset of the table (basically they can do as much of this as they like). kre From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 00:14:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23378; Sat, 26 Aug 1995 00:14:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA08017; Sat, 26 Aug 1995 00:10:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA07953; Fri, 25 Aug 1995 23:57:53 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22195; Fri, 25 Aug 1995 23:57:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12142; Fri, 25 Aug 95 09:57:34 -0400 Date: Fri, 25 Aug 95 09:57:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508251357.AA12142@ginger.lcs.mit.edu> To: bound@zk3.dec.com, vaf@valinor.barrnet.net Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: bound@zk3.dec.com What I do believe should be permitted is that providers who wish to make it so that a site does not have to renumber should be able to do so. The problem is that we're in a "tragedy of the commons" type situation. E.g. if one fisherman overfishes, it's not a big deal. If they all overfish, the George's Bank (to use a New England example near you :-) shuts down. Similarly, if a few sites do not renumber, the Internet routing can surely withstand it. But if they all do it, it will croak... The problem becomes how to make that clear, that just because it says "may" doesn't mean everyone can avail themselves of it. You can get into more or less bottomless debates (as we have seen) over what is "fair"; how do you pick a date, why do people who were on before get to keep their addresses, etc. Which is why, when faced with question like that, I say "off with everyone's head". It may not be painless, but by golly it's fair. However, I think Sean's point, that the IETF is probably not the place to set policy for this, is a good one. All we have to do is write a document that says "if everyone does it, the routing will croak", and let the ISP's handle it from there. It is, after all, in their own business interests to do so. Now, they may decide to use the IETF as a neutral technical forum to try and talk about this, to avoid US anti-trust, but that's another matter. The issue for me with the draft in CIDR is not that it is technically wrong, but that there is another proposal on the table I would like to see discussed (in process) Sure, but i) let's not halt an effort that most people support while we argue the merits of another alternative (I think you can see the analogy I would make there :-), and ii) it's perhaps best to discuss that alternative somewhere else that in the WG dedicated to the first one... I have also been around long enough that CIDR has me nervous in general as its not to exact. ... Now we have another problem and CIDR now needs to specifiy a BCP (at least I hope thats all it is). Well, let me point out that the "another problem" in this case was forseen the best part of a decade ago, and if there was some uncertainty back then as to the approximate date (in a system this size, there are no exact dates), that's as much a function of an unclear crystal ball about deployed technology (both h/w and s/w; neither BGP nor OSPF existed back then) as anything else. So I am totally confused and not sure I trust anything about CIDR right now, I just don't know. Me, I'd say any group that manages to predict stuff 10 years out in an environment this dynamic can't be completely dumb... Noel From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 00:29:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24242; Sat, 26 Aug 1995 00:29:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA08334; Sat, 26 Aug 1995 00:26:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA08025; Sat, 26 Aug 1995 00:11:04 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23147; Sat, 26 Aug 1995 00:10:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12307; Fri, 25 Aug 95 10:10:27 -0400 Date: Fri, 25 Aug 95 10:10:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508251410.AA12307@ginger.lcs.mit.edu> To: bsimpson@morningstar.com, dcrocker@brandenburg.com Subject: Re: "Provider-based addresses" is bad terminology Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker the best middle ground for addressing is a scheme which is primarily geographic. It's a bit hard to respond to this without having a better idea of what you mean. Do you mean Steve's metro-addressing, or some variant, or something completely different? If you would provide some details, I'd be more than happy to show you where it goes wrong. Noel From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 00:33:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24395; Sat, 26 Aug 1995 00:33:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA08362; Sat, 26 Aug 1995 00:31:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA08163; Sat, 26 Aug 1995 00:21:16 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23703; Sat, 26 Aug 1995 00:20:46 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12431; Fri, 25 Aug 95 10:20:18 -0400 Date: Fri, 25 Aug 95 10:20:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508251420.AA12431@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, sob@newdev.harvard.edu Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Scott Bradner A tactic that a number of people have suggested is to distribute the prefixes for both providers within the organization ... There are some questions about how should a host select which address to use in the source field in the packet header As a general solution to multi-homing, multiple addresses is not a good one. Consider the case of an organization connected to three national providers, which are each in turn connected to three international providers. (I know, this kind of structure may not actually happen in reality, due to business trends in the communication industry, it's just something to visualize.) That would take *9* addresses per host, to allow all possible provider pairings, Etc, etc. What's really going on (to some degree) with multiple addresses is that people wish to have some policy control over which path their packets take, and that's better done with plain old policy routing (i.e. explicit routes) tools. Depending on exactly what your goal is for multi-homing, different mechanisms are appropriate (at least with the simple hop-by-hop precomputed-routes model we have now in the Internet). For providing backup (so that you can survive loss of a provider link fairly locally and invisibly) multiple addresses don't work, you have to advertise in the routing instead, and the overhead costs are the same there whether you use an address solely from one provider, one from each, or a separate address. Noel From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 00:48:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25183; Sat, 26 Aug 1995 00:48:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA08419; Sat, 26 Aug 1995 00:46:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA08336; Sat, 26 Aug 1995 00:28:13 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24146; Sat, 26 Aug 1995 00:27:59 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id HAA24472; Fri, 25 Aug 1995 07:25:24 -0700 Message-Id: <199508251425.HAA24472@hubbub.cisco.com> To: hinden@ipsilon.com (Bob Hinden) Cc: big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Thu, 24 Aug 95 18:56:34 PDT." Date: Fri, 25 Aug 95 07:25:24 PDT From: Yakov Rekhter Precedence: bulk Bob, > I think we have learned from designing IPv6 renumbering that automatic > renumbering is hard stuff but possible if it is done right from the start. > What worries me about the discussion about IPv4 renumbering is without > major changes/additions to IPv4 stacks automatic renumbering is not > possible. Given the installed base of IPv4 (plus WIN95 shipping today w/ > TCP/IP bundled), I don't think this kind of change (to IPv4 stacks) is > going to happen. To the best of my knowledge WIN95 has DHCP. So, WIN95 should not be such a big of a problem for renumbering. Yakov. From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 00:51:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25308; Sat, 26 Aug 1995 00:51:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA08440; Sat, 26 Aug 1995 00:49:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA08382; Sat, 26 Aug 1995 00:39:13 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24715; Sat, 26 Aug 1995 00:38:57 +1000 (from kre@munnari.OZ.AU) To: "Brian Carpenter CERN-CN" Cc: big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Fri, 25 Aug 1995 15:48:37 +0200." <9508251348.AA29379@dxcoms.cern.ch> Date: Sat, 26 Aug 1995 00:38:34 +1000 Message-Id: <12695.809361514@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Fri, 25 Aug 1995 15:48:37 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Message-ID: <9508251348.AA29379@dxcoms.cern.ch> I suggest taking this thread over the road (pun) to the pier list. Yes, if that ever shows any signs of life (barnacles?) I think I subscribed, at least I requested subscription (day 1) but have no evidence anything happened yet... You raise several valid points, although my main point was that millions of domestic users will get dynamic addresses as a matter of course. They'll get dynamic addresses as they connect, which for all the homes in the world connecting via MSN is a damn good thing. They don't get renumbering, once they're running, unless they do it manually, or reconnect. If you think your average Win95 user is able to cope with renumbering IP, then I think you need go look at average PC users again... (they are typically capable of reebooting though - that is PC SOP - but its not clear how we tell them that now is the time they have to do that). kre From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 01:09:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26269; Sat, 26 Aug 1995 01:09:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA08485; Sat, 26 Aug 1995 01:07:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA08475; Sat, 26 Aug 1995 00:56:54 +1000 From: bound@zk3.dec.com Received: from mail2.digital.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25552; Sat, 26 Aug 1995 00:56:47 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA31040; Fri, 25 Aug 1995 07:47:09 -0700 Received: by xirtlu.zk3.dec.com; id AA08153; Fri, 25 Aug 1995 10:47:06 -0400 Message-Id: <9508251447.AA08153@xirtlu.zk3.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Fri, 25 Aug 95 09:57:34 EDT." <9508251357.AA12142@ginger.lcs.mit.edu> Date: Fri, 25 Aug 95 10:47:00 -0400 X-Mts: smtp Precedence: bulk Noel, ACK. I agree with Seans point too. Thats been my issue all along. Sorry it took all this to get that out my fault. /jim From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 01:28:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27251; Sat, 26 Aug 1995 01:28:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA08578; Sat, 26 Aug 1995 01:26:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08538; Sat, 26 Aug 1995 01:20:53 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26868; Sat, 26 Aug 1995 01:20:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12729; Fri, 25 Aug 95 11:20:42 -0400 Date: Fri, 25 Aug 95 11:20:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508251520.AA12729@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: "Provider-based addresses" is bad terminology Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "William Allen Simpson" Actually, Sprint is also connected to MCI at Chicago NAP, and probably many other places. That's why "provider-based" is utterly worthless as a topology assignment base You seem to be operating with a different image of what I'm talking about. Let's try it this way... Draw a map of MCI, its connections to other providers and the rest of the Internet, and all the customers who are solely connected to MCI. You will note that you can draw circle (well, a closed boundary, actually; it's not likely to be circular) which includes MCI and those customers. For the routing, you can give that entity a single name (in IPv4 CIDRese, something like X/y, where y is a mask length). Outside that entity, routing tables need only contain a single entry for anything inside that boundary; i.e. X/y. This is "provider-based addressing", and it works just fine, *as your own example shows*. You are perhaps under the same misapprehension that seems to befall Dave, which is believing that the hierarchy in the tree of abstractions has *anything* to do with the connection topology. It *doesn't*, any more than the tree structure of a Unix filesystem on a single volume has anything to do with the way the disk blocks are laid out. A regular mesh graph (e.g. a NEWS grid) which is chock-a-block with alternate paths can *still* be addressed by an address hierarchy, which when diagrammed out is a pure tree. (This does *not* mean that the routing is a pure tree, though, but that's yet another topic.) Don't try to draw both of them on one picture; it doesn't work! I'm not sure what routing references you have available to you, but many have pictures which make this plain, by giving the topology map *and* the abstraction tree. The one on pg 258 of the Kleinrock and Kamoun paper is one. But, Noel agreed in his message (starting this subject). No, I did not agree. I objected (and object) to the term "provider-based" as it obscures the underlying technical reality, not because I think "provider- based" addresses don't work. World Wide Access is multi-homed with MCInet and SprintNet. They peer in Chicago ... a mere 2 hops apart. In fact, the WWA multihome is relatively useless topologically, as a connection directly to Chicago NAP would give the same effect. It does provide some redundancy when the Chicago NAP falls over Your statement ("relatively useless topologically") I just don't understand, on several levels. To start with, as a statement it makes no sense. I mean, topology just is. If you meant that it does not provide much redundancy, I'd disagree; it's probably even better than connection to the NAP, as the NAP is a single point of failure, whereas I doubt MCI and Sprint have a common single point of failure, but peer in lots of places, not just Chicago. If you meant that it's hard to assign an address to it that can be easily aggregated, again I don't agree. If (big "if", I know :-) MCI and Sprint had been numbered out of some larger aggregate, so that MCI was U.M and Sprint was U.S, WWA could have been numbered U.W, or even U.M.W or U.S.W (the routing overhead of all three would be identical inside U), and outside U, it would be aggregated. So, to have good topological numbering ... WWA should get its address space from Chicago NAP. Arrrghh! I am so tired of people talking "getting address space from" things. This is that same old stupid registry model that is utterly disfunctional. You don't (or shouldn't) "get addresses"; you should draw circles on maps, darn it. Then, give the circles numbers, and the address is the concatenation of the numbers; simple. Of course, this works a lot better with an address which looks like a Unix file-name; you can pack them into fixed-length entities but someone has to run around and set the masks up, etc, etc. So, in this case, what addresses you should assign to WWA *depends on what the map looks like*; show me the topology map, and I can draw circles for you. The assignment of the actual numbers, from there, is pretty much uninteresting and trivial. Instead, they each have addresses unrelated to any NAP or their "providers", and the routing is skewed. That's because people didn't look at topology maps when they set up the IP address space. Perfect examples of why provider-based addresses don't work in a mesh You seem to have this broken idea that a topology-based address hierarchy doesn't work in a mesh. It does. Draw a few pictures on your whiteboard, using the process I described in a previous note to Big-I, and you will see how it works. I'd do it for you, but I can't in email (and I don't have MIME, sorry). Perhaps someone who does understand this can make such a drawing available as PS file (sorry, I don't have the technology to do it), for those who are having a hard time here... Noel From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 02:08:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29262; Sat, 26 Aug 1995 02:08:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08627; Sat, 26 Aug 1995 02:06:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08612; Sat, 26 Aug 1995 01:48:49 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28311; Sat, 26 Aug 1995 01:48:36 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id IAA01208; Fri, 25 Aug 1995 08:48:17 -0700 Message-Id: <199508251548.IAA01208@hubbub.cisco.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: "Provider-based addresses" is bad terminology In-Reply-To: Your message of "Fri, 25 Aug 95 11:20:42 EDT." <9508251520.AA12729@ginger.lcs.mit.edu> Date: Fri, 25 Aug 95 08:48:17 PDT From: Yakov Rekhter Precedence: bulk Noel, > I objected (and object) to the term "provider-based" as > it obscures the underlying technical reality, not because I think "provider- > based" addresses don't work. You're certainly correct. "Provider-based" addressing is incorrect term. And here is why. CIDR address allocation aims at making allocations in such a way, as to make aggregation of addressing information possible. Any entity that provides sufficient degree of aggregation acts as an "aggregator". Such an entity *could* be a provider, but does not have to be a provider. For example, an organization like MIT that has well over 10K computers has its address allocation in such a way that addressing information associated with all these computers can be expressed as a *single* address prefix. This level of aggregation seemed to be sufficient to carry this prefix (with no further aggregation) through the Internet routing system. So, in this example MIT acts as an "aggregator". On the other hand, a site with 5 computers can't provide sufficient level of aggregation to justify carrying a route to that site throughout the Internet routing system. So, such a site needs an "aggregator". Site's provider may be a good choice for being the "aggregator" for the site. So, perhaps "aggregator-based" addresses would be a more correct term. Yakov. P.S. The term "aggregator-based" addresses was coined by Peter Ford. From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 02:28:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00350; Sat, 26 Aug 1995 02:28:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08677; Sat, 26 Aug 1995 02:26:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08660; Sat, 26 Aug 1995 02:24:45 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29924; Sat, 26 Aug 1995 02:24:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13136; Fri, 25 Aug 95 12:24:19 -0400 Date: Fri, 25 Aug 95 12:24:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508251624.AA13136@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: ownership, leasing, renumbering, and that draft Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "William Allen Simpson" It would be easy to map the AS directly into a reserved set of 64K IP addresses Hmmm. With mapping straight through from a portable-current destination address to a new-style destination address, which you put in a wrapping packet (since to add it as an option would mean tweaking the forwarding in all the internal routers in the core), there are a number of potential problems (especially with multihomed sites). For instance, if the MTU of the "core" is Ethernet-sized (at least for this particular source-destination pair), and an Ethernet sized packet comes in, it will have to be fragmented, for reassembly either i) on exit, or ii) at the ultimate destination. Either has potential for complications. If you wish to do i), the exit router has to hang on to the fragments until all the bits arrive, etc. Also, for multi-homed sites, if multi-path routing is in use, different fragments could wind up at different exit routers. If you do ii), and the fragmentation happens inside the net (i.e. not at the router which does the wrapping), it will have to unwrap the packet before fragments (so again you'd have to modify all the internal routers too). This can all be avoided with Path MTU, of course, but many hosts do not implement Path MTU. And if you upgrade all the hosts to have Path MTU, you can probabl upgrade them to make reassigning addresses easier. The lookups have to be done anyway for BGP, so there won't be any added latency. Not on every packet, they don't... Shouldn't take more than a few weeks to code, and a month to test. I think those are way underestimates since there are a bunch of little problems like the above. Than, as Joel points out, you have to deploy it everywhere before it's really useful. Etc, etc, etc. While you're doing all that, the ISP's will have gone ahead and renumbered... Noel From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 03:09:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02000; Sat, 26 Aug 1995 03:09:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08739; Sat, 26 Aug 1995 03:06:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08718; Sat, 26 Aug 1995 02:50:43 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01204; Sat, 26 Aug 1995 02:50:41 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA28729 Sat, 26 Aug 1995 02:50:23 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.3] ([204.247.5.3]) by aimnet.com (8.6.12/8.6.12) with SMTP id JAA04789; Fri, 25 Aug 1995 09:48:26 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 09:48:59 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: "Provider-based addresses" is bad terminology Cc: big-internet@munnari.OZ.AU Precedence: bulk At 7:10 AM 8/25/95, Noel Chiappa wrote: >you mean. Do you mean Steve's metro-addressing, or some variant, or something Noel, yes, I mean something along the line of Steve's metro-addressing. I was a very strong advocate of this in the days of the IPAE working group and spent extended time with him working through the details. In the end, the requirement for a MIX (metropolitan interchange) in each area was the killer. I haven't thought about the details since then but Bob Hinden mentioned recently that having coarse-grained (I'm calling them "region") interconnects might be sufficient for the near-term. In any event it's certainly reasonable for you to want to see more detail. Have to see what we can do to create it for you. (For you, Noel, anything...) d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 03:13:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02067; Sat, 26 Aug 1995 03:13:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08774; Sat, 26 Aug 1995 03:11:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08724; Sat, 26 Aug 1995 02:53:56 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB01321; Sat, 26 Aug 1995 02:53:54 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.3] ([204.247.5.3]) by aimnet.com (8.6.12/8.6.12) with SMTP id JAA05303; Fri, 25 Aug 1995 09:53:16 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 09:53:49 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk At 6:29 AM 8/25/95, Noel Chiappa wrote: >There's a bug in your reasoning, which is that the net is in trouble now, but >we do have a tool on the shelf - designed, documented, implemented and >deployed - to fix it: topologically-based addresses. This tool is being taken Noel, there's a bug in your reasonging. We have a tool which fixes it for some (large) fraction of the community, but at very, very considerable expense, pain, and damage to some (significant) fraction of the community. In reality, what cidr does is to take a difficult situation and make ALL end-users incur the expense, pain and damage of "fixing" the problem with relatively NO expense, pain or damage suffered by the transit providers. This is only a workable solution if one is a transit provider. For everyone else, the kindest description would be to call this an unpleasant experiment. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 03:16:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02203; Sat, 26 Aug 1995 03:16:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08794; Sat, 26 Aug 1995 03:15:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08715; Sat, 26 Aug 1995 02:48:12 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01133; Sat, 26 Aug 1995 02:48:09 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.3] ([204.247.5.3]) by aimnet.com (8.6.12/8.6.12) with SMTP id JAA04716 for ; Fri, 25 Aug 1995 09:47:35 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 09:48:08 -0700 To: big-internet@munnari.OZ.AU From: Dave Crocker Subject: firewalls and data integrity Precedence: bulk At 5:42 AM 8/25/95, Robert Moskowitz wrote: >Business are NOT going to just connect. Or rather, businesses of any size. >They are firewalling. Bob, good point. But it does raise a point I've wondered about: firewalling -- in particular proxying -- of interactive connections keeps the application-level protocol intact but interrupts the transport connection (turning it into two separate transport connections, one inside the organization and one outside.) Here's the concern: Most application protocols have no data integrity facilities. They rely on the transport service to provide this. With firewalls, we provide a significant opportunity for data loss and corruption. For those inclined to dismiss this possibility, I caution that there is much history in the Internet with the NEED for true end-to-end data integrity. So, the point about firewalls is that they violate the long-standing Internet architectural model of end-to-end data integrity. For casual interactions this is no big deal. For more serious interactions, such as Web-based commerce, undetected flipping of a few stray bits such as in the price field could have very serious effects. Anyone care to comment? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 03:20:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02456; Sat, 26 Aug 1995 03:20:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08816; Sat, 26 Aug 1995 03:18:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08721; Sat, 26 Aug 1995 02:53:36 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01307; Sat, 26 Aug 1995 02:53:33 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.3] ([204.247.5.3]) by aimnet.com (8.6.12/8.6.12) with SMTP id JAA05244; Fri, 25 Aug 1995 09:52:49 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 09:53:22 -0700 To: "Brian Carpenter CERN-CN" From: Dave Crocker Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU (bigi) Precedence: bulk At 11:46 PM 8/24/95, Brian Carpenter CERN-CN wrote: >If address configuration and deprecation, and dynamic DNS, >work properly, who cares? Brian, et al, 1. You are a corporation with running services. Some are mission-critical, 24 hours a day. Outages of the service are a VERY big deal. Users are connected all the time. Please explain to me the sequence that will be acceptable with dynamic address changing? 2. You are an intermediate (local) provider with some thousands of customers. The customers do whatever they do, but they do them with addresses that you've supplied out of the cidr block given to you by ONE of your transit providers. You now decide to drop that transit provider and must, therefore, get a new cidr block and must, therefore, get all of those thousands of customers to renumber. Please explain to me the sequence that will be acceptable with dynamic address changing. 3. A common line of defense for auto-renumbering is the relative ease currently in practise for client-only Internet users. These already have dynamic addressing at dial-up time and work just fine. What this line of defense does NOT do is to characterize the relative proportion or, more importantly, the relative damage, for that portion of the community which is NOT this kind of user. Please discuss the impact on these other users. (Take as much time as you need. Additional blue books are available at the front of the room. You may start the exam now.) d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 03:48:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03507; Sat, 26 Aug 1995 03:48:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08870; Sat, 26 Aug 1995 03:46:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA08850; Sat, 26 Aug 1995 03:37:54 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03105; Sat, 26 Aug 1995 03:37:51 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.16] ([204.247.5.16]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA09560; Fri, 25 Aug 1995 10:37:15 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 10:37:48 -0700 To: Yakov Rekhter From: Dave Crocker Subject: Re: "Provider-based addresses" is bad terminology Cc: big-internet@munnari.OZ.AU Precedence: bulk At 8:48 AM 8/25/95, Yakov Rekhter wrote: >So, perhaps "aggregator-based" addresses would be a more correct term. Yakov, In the future will organizations, like MIT, get their addresses from IANA or from a provider? When they change providers will they keep their block or get a new one? How many such organizations would you estimate their to be, globally? Does this constitute an "interesting" number of exceptions in the global routing tables? -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 03:50:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03592; Sat, 26 Aug 1995 03:50:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08892; Sat, 26 Aug 1995 03:49:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA08864; Sat, 26 Aug 1995 03:43:24 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03405; Sat, 26 Aug 1995 03:43:16 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14835; Fri, 25 Aug 95 13:43:09 EDT Date: Fri, 25 Aug 95 13:43:09 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9508251743.AA14835@itd.nrl.navy.mil> To: big-internet@munnari.OZ.AU Subject: Re: Multi-homed sites In-Reply-To: <9508251420.AA12431@ginger.lcs.mit.edu> Organization: Naval Research Laboratory, DC Precedence: bulk In article <9508251420.AA12431@ginger.lcs.mit.edu> you write: >As a general solution to multi-homing, multiple addresses is not a good one. Absolutely. It is an administrative problem for openers. It can also be a problem for a host implementation trying to pick a reasonable (not necessarily optimal, but reasonable) source address. Not a lot of fun. >Consider the case of an organization connected to three national providers, >which are each in turn connected to three international providers. (I know, >this kind of structure may not actually happen in reality, due to business >trends in the communication industry, it's just something to visualize.) That >would take *9* addresses per host, to allow all possible provider pairings, >Etc, etc. NRL-DC is directly connected to about 8 external providers right now and that has been the number for a while now. So your example is plausible. >What's really going on (to some degree) with multiple addresses is that people >wish to have some policy control over which path their packets take, and >that's better done with plain old policy routing (i.e. explicit routes) tools. Yup. >Depending on exactly what your goal is for multi-homing, different mechanisms >are appropriate (at least with the simple hop-by-hop precomputed-routes model >we have now in the Internet). For providing backup (so that you can survive >loss of a provider link fairly locally and invisibly) multiple addresses don't >work, you have to advertise in the routing instead, and the overhead costs >are the same there whether you use an address solely from one provider, one >from each, or a separate address. My preference for NRL-DC, which campus has not moved since it was created just after WW-I and is pretty darn unlikely to ever move, would be for NRL-DC to have an IPv6 address space that looked something like: The "Routing Prefix for FIX-EAST" chunk would be the only prefix that most network providers would need to store in their routing tables. The service providers for NRL would also need to store a routing prefix like "" (this seems reasonable since they'd be getting $$$ to do this). NRL's campus addresses would come out of the local use chunk and be assigned however NRL Network Ops decides. NRL would then be constrained to pick from service providers that connected at FIX-EAST. This scheme doesn't work everywhere but it sure does work for sites reasonably near a NAP or FIX or CIX or MAE point. I've mentioned this approach in the past. I've been unhappy that various folks (not Noel) have rejected it out of hand without explaining why they think it wouldn't work for sites having the above properties. Similarly, if we assign Routing Prefixes to continents or world regions than that can help reduce the size of the routing tables. Carrying a single IPv6 route that means would suffice for many service providers (i.e. all that don't directly service Australia) Providers that directly service Australia have financial incentives to carry the additional routes of their Australian customers. So maybe the above would be consitued from parts that were or some such. NRL-DC really would like to try this experiment for IPv6. Ran rja@cs.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 04:28:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05437; Sat, 26 Aug 1995 04:28:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA08971; Sat, 26 Aug 1995 04:26:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08937; Sat, 26 Aug 1995 04:08:00 +1000 Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04280; Sat, 26 Aug 1995 04:07:53 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998) id <01HUHP101ROG002FYI@FNAL.FNAL.GOV>; Fri, 25 Aug 1995 13:07:18 -0500 (CDT) Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m) id AA04985; Fri, 25 Aug 95 13:06:28 CDT Date: Fri, 25 Aug 1995 13:06:27 -0500 From: Matt Crawford Subject: Re: "Provider-based addresses" is bad terminology In-Reply-To: Your message of Fri, 25 Aug 95 11:20:42 EDT. <9508251520.AA12729@ginger.lcs.mit.edu> Sender: crawdad@munin.fnal.gov To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508251806.AA04985@munin.fnal.gov> Content-Transfer-Encoding: 7BIT Precedence: bulk > Perfect examples of why provider-based addresses don't work in a mesh > > You seem to have this broken idea that a topology-based address hierarchy > doesn't work in a mesh. It does. Let me chip in ... A hierarchical network has a compelling natural choice for the drawing of the little circles, while a mesh network gives you lots of freedom of choice. Maybe someone's mistaking the lack of a single best way to choose the topological addresses for a lack of any way of doing so. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 04:33:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05666; Sat, 26 Aug 1995 04:33:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA08995; Sat, 26 Aug 1995 04:31:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08951; Sat, 26 Aug 1995 04:13:07 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04357; Sat, 26 Aug 1995 04:13:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13723; Fri, 25 Aug 95 14:12:51 -0400 Date: Fri, 25 Aug 95 14:12:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508251812.AA13723@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@brandenburg.com Subject: Re: firewalls and data integrity Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker Most application protocols have no data integrity facilities. They rely on the transport service to provide this. With firewalls, we provide a significant opportunity for data loss and corruption. ... For casual interactions this is no big deal. For more serious interactions, such as Web-based commerce, undetected flipping of a few stray bits such as in the price field could have very serious effects. Hmm. My understanding is that such transactions will usually be authenticated, and often encrypted. These would of course catch such problems. (You can look at these as true end-end error detection, since of course the transport protocol is not really the application, either....) From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 04:48:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06375; Sat, 26 Aug 1995 04:48:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA09030; Sat, 26 Aug 1995 04:46:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA09015; Sat, 26 Aug 1995 04:36:56 +1000 Received: from valinor.barrnet.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05813; Sat, 26 Aug 1995 04:36:41 +1000 (from vaf@valinor.barrnet.net) Received: (from vaf@localhost) by valinor.barrnet.net (8.6.8/8.6.6) id LAA07880; Fri, 25 Aug 1995 11:35:28 -0700 Date: Fri, 25 Aug 95 11:35:28 PDT From: Vince Fuller To: bound@zk3.dec.com Cc: big-internet@munnari.OZ.AU Phone: (415) 528-7227 Usmail: 3801 East Bayshore Rd, Palo Alto, CA, 94303 Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of Thu, 24 Aug 95 23:22:36 -0400 Message-Id: Precedence: bulk If I had my way all MUSTs in the IETF and in the world would be stricken from all languages along with "I am sorry". But I don't seem to win those battles. I fully believe we must be able to automatically renumber private networks with IPv6. To avoid the exponential growth problems of 128 bit prefixes. What I do believe should be permitted is that providers who wish to make it so that a site does not have to renumber should be able to do so. So I am nervous about the word "require" above. But if I am with provider X and move to provider Y with IPv6 and they give me a new prefix in IPv6 as a customer I expect a painless effort to renumber to the new prefix. So yes to your question and I punt on require for now. I'll ask the obvious followup question which may have already been answered: if renumbering is painless, then why would a provider or a customer want to kludge things so that the customer doesn't have to renumber? Doing so works directly against making the Internet scale. Does potential reluctuance to renumber ("providers who wish to make it so that a site does not have to renumber") imply that renumbering will not be the painless, automated process that some consider an absolute requirement of IPv6? People keep saying that they have problems with CIDR because it doesn't do this or it doesn't do that. CIDR is nothing magical. In its essence, all it really is is a observation that addresses, the things used by routing, and topology are intimately related and that IP addresses must have topological significance for routing to scale. This should come as no surprise to anyone, not even someone (like me) who didn't do too well in graph theory in college. It isn't rocket science, but it is a fundamental aspect of networking. Think about the term "address" for a moment. What is an address? Well, in the physical world, it describes, in a very hierarchical fashion, where something is located. The address: Vince Fuller, 3801 East Bayshore Road, Palo Alto, CA, USA has a number of levels of hierarchy, each of which is used to reduce the scope of routing things by describing different levels of abstraction of the underlying "network" topology. Is the "local network" component of this address, "3801 East Bayshore Road", propagated to every post office and every mailman in the country? Probably not - the farther you get away from my location, the less specific "next hop" information is needed. Addresses of things in the network have to work the same way - they have to describe where something is located in the topology. If the things you use to number end-systems in the Internet don't have this property, then they aren't really addresses and you can't expect the routing system to track them in anything resembling an efficient manner. By saying that sites should be able to have "portable" addresses, you are making a statement analagous to my saying that I should be able to pick up "3801 East Bayshore Road" and move it to New Zealand and someone have mail still get to me at my old address. Of course, if "3801 East Bayshore Road" were propagated to every post office in the world, then this would work just great, but I don't think doing that for every street address is going to scale too well. Why should network addresses display any better scaling properties? If anything, the problem is far worse with network addresses because it is much easier to do the topological equivalent of moving 204.160.73.0/24 to New Zealand simply by ordering a phone circuit to another network provider who is topologically distant from the current provider. --Vince From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 05:27:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07738; Sat, 26 Aug 1995 05:27:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA09102; Sat, 26 Aug 1995 05:26:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA09096; Sat, 26 Aug 1995 05:26:13 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07720; Sat, 26 Aug 1995 05:26:03 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id PAA29374 for ; Fri, 25 Aug 1995 15:25:56 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id PAA23813 for ; Fri, 25 Aug 1995 15:25:56 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA11673; Fri, 25 Aug 95 15:35:20 EDT Message-Id: <9508251935.AA11673@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 15:25:01 -0400 To: Dave Crocker , Yakov Rekhter From: Robert Moskowitz Subject: Re: "Provider-based addresses" is bad terminology Cc: big-internet@munnari.OZ.AU Precedence: bulk At 10:37 AM 8/25/95 -0700, Dave Crocker wrote: >At 8:48 AM 8/25/95, Yakov Rekhter wrote: >>So, perhaps "aggregator-based" addresses would be a more correct term. > >Yakov, > > In the future will organizations, like MIT, get their addresses >from IANA or from a provider? When they change providers will they keep >their block or get a new one? We got our addresses for the new firewalls from our provider, MCI. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 05:28:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07790; Sat, 26 Aug 1995 05:28:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA09122; Sat, 26 Aug 1995 05:28:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA09078; Sat, 26 Aug 1995 05:20:37 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07473; Sat, 26 Aug 1995 05:20:24 +1000 (from bsimpson@morningstar.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-06.dialip.mich.net [141.211.7.174]) by merit.edu (8.6.12/merit-2.0) with SMTP id PAA11487 for ; Fri, 25 Aug 1995 15:20:14 -0400 Date: Fri, 25 Aug 95 18:52:20 GMT From: "William Allen Simpson" Message-Id: <4529.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: Re: "Provider-based addresses" is bad terminology Precedence: bulk > From: asp@uunet.uu.net (Andrew Partan) > > Actually, Sprint is also connected to MCI at Chicago NAP, and probably > > many other places. That's why "provider-based" is utterly worthless as > > a topology assignment base, which is what Dave seems to be getting at. > > Huh? This does not follow. I think that this shows just the opposite > - that "provider-based" address allocation does work & works rather > well. > --asp@uunet.uu.net (Andrew Partan) > The provider-assigned addresses have no relation to the actual interconnections of the topology. Whan all the traffic between providers goes through one NAP, even though they are connected at many NAPs, it is operationally and experiencially clear to the rest of us that provider-based is NOT working. This is a natural fallout of provider-based assignment, and building a treework instead of a network. Obviously UUnet has gotten out of touch with real traffic. We are experiencing 40% packet loss at Mae-East during the local day. It would be somewhat improved if we simply cut UUnet off from MaeEast, and forced them to interconnect somewhere else to distribute the load. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 05:29:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07821; Sat, 26 Aug 1995 05:29:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA09146; Sat, 26 Aug 1995 05:29:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA09081; Sat, 26 Aug 1995 05:20:41 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07476; Sat, 26 Aug 1995 05:20:26 +1000 (from bsimpson@morningstar.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-06.dialip.mich.net [141.211.7.174]) by merit.edu (8.6.12/merit-2.0) with SMTP id PAA11484 for ; Fri, 25 Aug 1995 15:20:10 -0400 Date: Fri, 25 Aug 95 17:53:12 GMT From: "William Allen Simpson" Message-Id: <4528.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: Benefits of Geographic examples Precedence: bulk > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > From: Dave Crocker > the best middle ground for addressing is a scheme which is primarily > geographic. > > If you would provide some details, I'd be more than > happy to show you where it goes wrong. > This statement so annoyed me that I actually spent the money to call Noel and get higher bandwidth. I thought I'd already given a fairly explicit pair of examples! Anyway, here they are again, with detail: ---- WWA is a Chicago BBS (cum provider), once widely known as gagme. They are multihomed with MCInet and SprintNet. So, they have the usual IP number which is _NOT_ under MCI or Sprint, and has to be advertised worldwide separately. Hopefully, we can all agree that this is bad. The alternative pushed by the providers that WWA should be re-numbered under one of them, say MCI, is both a non-starter for WWA, and for all of WWA customers. It reduces the routing table for MCI, but not for Sprint, and penalizes WWA by forcing the rest of the world though the MCI gateway, when in fact a Sprint path might be better. My solution was a geographic address matching the actual NAP near which they are connected -- that is, Chicago. Note that this does not help either MCI or Sprint, which have the same number of routing entries. But, it does help the rest of the world (which is a good thing), because it aggregates into a specific exchange toward which they can send all their traffic. Traffic which passes by on MCI or Sprint on the way to Chicago NAP will naturally be routed onto the correct link to WWA. I reach this conclusion drawing Chiappa Circles, and naming/numbering from the best topological exchange. (While a wonderful intellectual exercise for purists, I do NOT agree with Noel that drawing circles which include some other set of links and no exchange is worthwhile.) This is useful even should WWA leave one or the other of MCI or Sprint, and connect to the NAP directly, or connect to yet another provider. Yes, MCI and Sprint are still flat routing WWA, but the rest of the world is not. Again, a good thing. This is truly useful given the fact that WWA is now providing service to upper Mississippi, via WaterValley.Net. Unfortunately, WVN is numbered under WWA, instead of geographically in Mississippi. When WVN becomes multi-homed, either by connecting to Old-Miss in Oxford or someone else in Tupelo, then their exception route needs to be propagated worldwide. Bad news, since it will be yet another hole in the NA block and in WWA's block, clogging all the boundary routers. This would have been avoided if geographic was used in the first place for WVN. ---- The local freenet BBS Arbornet.Org is a harder case. It is connected to 2 regional providers (MichNet & MSEN), who are connected to multiple national providers (MCInet & PSInet). Since these only peer at MAE-East, drawing a Chiappa Circle shows that we have to assign them a _CONTINENTAL_ topological address. I am of the informed opinion that this is ridiculous. Not only because this is merely a routing table problem now (which it is), but also because it shows no foresight. While assigning a geographic address results in no routing table reduction TODAY, should both regional or national providers someday interconnect in Chicago, or Michigan, or eventually in Ann Arbor, each such STEP would result in a GLOBAL and CONTINENTAL savings in routing table size. Furthermore, as Arbornet changes providers, connects to a third provider, or becomes a provider itself, no negative effect will be felt in the "core" routing tables, for some definition of "core". ---- Yes, this all means that I expect some coordination and restrictions on where topology would be located. I think that planning our topology better would have gone a long way toward fixing many of our routing problems. Instead, we have a bunch of independent "providers" all refusing to interconnect in any way that might improve competition. The result is the balkanization of the Internet, and monopoly opportunities for MicroSoft, or another behemoth large enough to swamp your meager individual markets. Fools. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 05:46:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB08674; Sat, 26 Aug 1995 05:46:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA09183; Sat, 26 Aug 1995 05:46:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA09177; Sat, 26 Aug 1995 05:46:06 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08619; Sat, 26 Aug 1995 05:46:02 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzeix01748; Fri, 25 Aug 1995 15:45:59 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: "Provider-based addresses" is bad terminology To: bsimpson@MorningStar.Com (William Allen Simpson) Date: Fri, 25 Aug 1995 15:45:58 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <4529.bsimpson@morningstar.com> from "William Allen Simpson" at Aug 25, 95 06:52:20 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 516 Precedence: bulk > Obviously UUnet has gotten out of touch with real traffic. We are > experiencing 40% packet loss at Mae-East during the local day. It would > be somewhat improved if we simply cut UUnet off from MaeEast, and forced > them to interconnect somewhere else to distribute the load. Excuse me? Talk about injecting spurious info into the discussion at hand. There are other lists to bring up operational issues on - try mae-east@uunet.uu.net for MAE-East problems for instances. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 06:06:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09563; Sat, 26 Aug 1995 06:06:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09218; Sat, 26 Aug 1995 06:06:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA09203; Sat, 26 Aug 1995 05:51:06 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08771; Sat, 26 Aug 1995 05:51:02 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.40] ([204.247.5.20]) by aimnet.com (8.6.12/8.6.12) with SMTP id MAA22188; Fri, 25 Aug 1995 12:50:05 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 12:50:56 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: firewalls and data integrity Cc: big-internet@munnari.OZ.AU Precedence: bulk At 11:12 AM 8/25/95, Noel Chiappa wrote: >Hmm. My understanding is that such transactions will usually be authenticated, >and often encrypted. These would of course catch such problems. (You can look Well, Noel, thanks for taking the example in a way that entirely misses the concern. Let me try a different example that might be easier for folks to relate to: You have a nighly job that uses ftp to transfer some Very Important files across the net. Now, this is an existing facility. Existing protocol. Well-established basis for very, very, VERY high reliability of data integrity. With the advent of firewalls/proxies, we've just violated that basis. Those files WILL eventually come across corrupted. I said WILL, not maybe. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 06:26:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10296; Sat, 26 Aug 1995 06:26:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09284; Sat, 26 Aug 1995 06:26:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09254; Sat, 26 Aug 1995 06:18:09 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09938; Sat, 26 Aug 1995 06:18:07 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id NAA11420; Fri, 25 Aug 1995 13:18:04 -0700 Date: Fri, 25 Aug 1995 13:18:04 -0700 From: Tony Li Message-Id: <199508252018.NAA11420@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: <12684.809359152@munnari.OZ.AU> (message from Robert Elz on Fri, 25 Aug 1995 23:59:12 +1000) Subject: Re: Discussing encap/mapping proposal Precedence: bulk Let's back up. As I understand it, in your scheme, there is a set of routers which have a table which contains every possible /24 prefix in the IPv4 address space. Is this correct? Approximately. What's actually required is a mapping from every existing advertised prefix. Well, this is sufficient for my objection to stand. I'll not re-iterate unless you ask. Tony From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 06:28:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10353; Sat, 26 Aug 1995 06:28:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09308; Sat, 26 Aug 1995 06:27:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09261; Sat, 26 Aug 1995 06:23:30 +1000 Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10070; Sat, 26 Aug 1995 06:23:19 +1000 (from valdis@black-ice.cc.vt.edu) Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.Beta.10/8.7.Beta.10) with ESMTP id QAA18678; Fri, 25 Aug 1995 16:23:09 -0400 Message-Id: <199508252023.QAA18678@black-ice.cc.vt.edu> To: asp@uunet.uu.net (Andrew Partan) Cc: bsimpson@MorningStar.Com (William Allen Simpson), big-internet@munnari.OZ.AU Subject: Re: "Provider-based addresses" is bad terminology In-Reply-To: Your message of "Fri, 25 Aug 1995 15:45:58 EDT." From: Valdis.Kletnieks@vt.edu Date: Fri, 25 Aug 1995 16:23:09 -0400 Precedence: bulk On Fri, 25 Aug 1995 15:45:58 EDT, Andrew Partan said: > Excuse me? Talk about injecting spurious info into the discussion at > hand. There are other lists to bring up operational issues on - try > mae-east@uunet.uu.net for MAE-East problems for instances. Umm.. I dont consider it spurious. If one major ISP (UUNET) is having routing problems such that one of the major interconnect points is loosing nearly HALF of all traffic presented, this is is a symptom of the sort of thing we are trying to solve. /Valdis From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 06:29:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10401; Sat, 26 Aug 1995 06:29:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09328; Sat, 26 Aug 1995 06:29:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09258; Sat, 26 Aug 1995 06:23:28 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10069; Sat, 26 Aug 1995 06:23:18 +1000 (from bsimpson@morningstar.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm036-17.dialip.mich.net [141.211.7.59]) by merit.edu (8.6.12/merit-2.0) with SMTP id QAA13301 for ; Fri, 25 Aug 1995 16:23:14 -0400 Date: Fri, 25 Aug 95 19:44:19 GMT From: "William Allen Simpson" Message-Id: <4531.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: Re: Multi-homed sites Precedence: bulk > From: atkinson@itd.nrl.navy.mil (Ran Atkinson) > > > NRL-DC really would like to try this experiment for IPv6. > I would like to whole-heartedly agree with Ran's analysis based on his actual experience with multi-homing. This solution is the only one that I can see, too. Except that we are now discussing what to do with IPv4, not IPv6. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 06:31:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10443; Sat, 26 Aug 1995 06:31:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09352; Sat, 26 Aug 1995 06:30:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09269; Sat, 26 Aug 1995 06:23:39 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10090; Sat, 26 Aug 1995 06:23:30 +1000 (from bsimpson@morningstar.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm036-17.dialip.mich.net [141.211.7.59]) by merit.edu (8.6.12/merit-2.0) with SMTP id QAA13308 for ; Fri, 25 Aug 1995 16:23:19 -0400 Date: Fri, 25 Aug 95 20:04:35 GMT From: "William Allen Simpson" Message-Id: <4533.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: Re: "Provider-based addresses" is bad terminology Precedence: bulk > From: Dave Crocker > Noel, yes, I mean something along the line of Steve's > metro-addressing. I was a very strong advocate of this in the days of the > IPAE working group and spent extended time with him working through the > details. In the end, the requirement for a MIX (metropolitan interchange) > in each area was the killer. I haven't thought about the details since > then but Bob Hinden mentioned recently that having coarse-grained (I'm > calling them "region") interconnects might be sufficient for the near-term. > Actually, Deering's Metros always had deployment scaling to regional, then metro, exchanges, as density allowed. But for scaling, you need to decide early where the metros are, instead of later, even if they all aggregate somewhere else initially. Anyway, instead of commenting on each one, I'd like to say I really agree with Dave's next set of messages. Let's encourage him and Hinden and KRE to write up the encaps proposal yet again. I assume he will have sections on the questions and problems he raises on this list.... Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 06:33:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10495; Sat, 26 Aug 1995 06:33:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09374; Sat, 26 Aug 1995 06:33:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09259; Sat, 26 Aug 1995 06:23:28 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10068; Sat, 26 Aug 1995 06:23:18 +1000 (from bsimpson@morningstar.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm036-17.dialip.mich.net [141.211.7.59]) by merit.edu (8.6.12/merit-2.0) with SMTP id QAA13298 for ; Fri, 25 Aug 1995 16:23:12 -0400 Date: Fri, 25 Aug 95 19:34:52 GMT From: "William Allen Simpson" Message-Id: <4530.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal Precedence: bulk > From: Vince Fuller > CIDR is nothing magical. In its essence, all it > really is is a observation that addresses, the things used by routing, and > topology are intimately related and that IP addresses must have topological > significance for routing to scale. This should come as no surprise to anyone, > not even someone (like me) who didn't do too well in graph theory in college. > It isn't rocket science, but it is a fundamental aspect of networking. > As usual, the subject has wandered from the original. Vince, we are all in agreement that we need a "something" that follows the topology. I think (although some will argue with abtruse technical sematics) that we are all in agreement about addresses matching topology. We are discussing a mechanism to do that -- WITHOUT requiring all the IPv4 end users to renumber their IP addresses. The current proposal on the table is to map to AS numbers, probably using the existing IP->AS mapping already distributed for BGP. Then, we can painlessly renumber the ASs [sic] to match the topology. Now, what technical problems have you uncovered with this proposal? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 06:35:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10680; Sat, 26 Aug 1995 06:35:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09396; Sat, 26 Aug 1995 06:35:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09251; Sat, 26 Aug 1995 06:15:41 +1000 Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09897; Sat, 26 Aug 1995 06:15:38 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA23314; Fri, 25 Aug 95 16:14:18 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9508252014.AA23314@wizard.gsfc.nasa.gov> Subject: Re: ownership, leasing, renumbering, and that draft To: yakov@cisco.com (Yakov Rekhter) Date: Fri, 25 Aug 1995 16:14:17 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199508241140.EAA08203@hubbub.cisco.com> from "Yakov Rekhter" at Aug 24, 95 04:40:25 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2158 Precedence: bulk Yakov, I think kre addressed most of your points, but I'll add a few comments of my own. > To sum things up: > > (a) you explained how the problem I brought up can be solved within the > current Internet model And how hierarchical addressing and route aggregation can lead to black hole routing for portions of the aggregate. I think when the Internet starts using route aggregation on a large scale, which it will have to at some point, there will also need to be mechanisms available to detect such black holes, to be able to probe the path end-to-end, to insure that the path the routing says to take is indeed viable, and be able to discover and use alternate routes if necessary. After all, people are not going to want to pay for traffic that doesn't go anywhere. But this is probably digressing from the main topic of the mapping/ encapsulation scheme that kre is proposing. > (b) you didn't explain how the problem I brought up can be solved within > the encaps model (the model described in /kre's message) I should have explicitly stated that there's no particular reason that P1 and P2 couldn't have the mapping tables (or a minimal subset of them), or be able to perform the IP-in-IP encapsulation, just because they're not part of the "core" (DFZ). Alternatively, there's also no reason they couldn't choose to be part of the "core". It seems to be kind of an artificial distinction at some point. > (c) your description of how to handle routes to P3-S3 does not seem to > match the encaps model (/kre's proposal) Yes, I was modifying his proposal somewhat, as kre had indicated it was a rough working draft, with the details to be ironed out. kre had proposed routing the encapsulated packet to a specific exit router, I was proposing routing to the region containing the destination route, and Bill Simpson has suggested routing to the AS. They're all variations on the common theme, and which is best, or yet some other alternative, is a detail that can be worked a little later in the process, if the basic idea is deemed to have sufficient merit to pursue, which I believe it does. > Yakov. -Bill From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 06:37:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10803; Sat, 26 Aug 1995 06:37:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09419; Sat, 26 Aug 1995 06:37:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09266; Sat, 26 Aug 1995 06:23:36 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10072; Sat, 26 Aug 1995 06:23:21 +1000 (from bsimpson@morningstar.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm036-17.dialip.mich.net [141.211.7.59]) by merit.edu (8.6.12/merit-2.0) with SMTP id QAA13304 for ; Fri, 25 Aug 1995 16:23:16 -0400 Date: Fri, 25 Aug 95 19:49:31 GMT From: "William Allen Simpson" Message-Id: <4532.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: Re: "Provider-based addresses" is bad terminology Precedence: bulk > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > You are perhaps under the same misapprehension that seems to befall Dave, > which is believing that the hierarchy in the tree of abstractions has > *anything* to do with the connection topology. Funny, you'd think I understood that after 3-5 years of your lectures on the topic.... > Arrrghh! I am so tired of people talking "getting address space from" things. > This is that same old stupid registry model that is utterly disfunctional. > > You don't (or shouldn't) "get addresses"; you should draw circles on maps, > darn it. Then, give the circles numbers, and the address is the concatenation > of the numbers; simple. > > So, in this case, what addresses you should assign to WWA *depends on what > the map looks like*; show me the topology map, and I can draw circles for > you. The assignment of the actual numbers, from there, is pretty much > uninteresting and trivial. > Great, Noel, and how exactly are you going to administer this marvelous future? Amazingly enough, humans are still served by computers, not the more perfect vice versa.... > Instead, they each have addresses unrelated to any NAP or their > "providers", and the routing is skewed. > > That's because people didn't look at topology maps when they set up the IP > address space. > That's right, they don't. So, we need a model that matches the locations that people really are located at (geographically), and make our network topology conform.... MAKE the computers serve US! > You seem to have this broken idea that a topology-based address hierarchy > doesn't work in a mesh. It does. Note that I didn't say "theoretically cannot work", I said "don't work". And it is a fact that it IS NOT actually working. Routers are sending packets past local connections, indeed right past the Chicago NAP, to the East Coast, where we are experiencing terrible congestion. This appears to be because of shortest prefix matching, which forces everything into a heirarchy instead of a mesh. It may also be a misguided "policy" trying to force symmetric routes. Again, heirarchy instead of mesh. I am much less interested in the theoretical at this point than the practical. Enough lectures already.... Any improvement, such as AS encapsulation, will need to address this bogus CIDR side effect. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 06:47:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11283; Sat, 26 Aug 1995 06:47:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09462; Sat, 26 Aug 1995 06:47:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09433; Sat, 26 Aug 1995 06:39:36 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10865; Sat, 26 Aug 1995 06:39:31 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzeja11465; Fri, 25 Aug 1995 16:39:25 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: "Provider-based addresses" is bad terminology To: Valdis.Kletnieks@vt.edu Date: Fri, 25 Aug 1995 16:39:24 -0400 (EDT) Cc: bsimpson@MorningStar.Com, big-internet@munnari.OZ.AU In-Reply-To: <199508252023.QAA18678@black-ice.cc.vt.edu> from "Valdis.Kletnieks@vt.edu" at Aug 25, 95 04:23:09 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 398 Precedence: bulk > Umm.. I dont consider it spurious. This is spurious to the discussion at hand and spurious in this mailing list. Please take this elsewhere to some other mailing list. Note: we are not seeing any packet loss over MAE-East. If anyone is seeing packet loss with AlterNet, they should contact our noc (noc@uunet.uu.net or +1 800 900 0241) and open a ticket. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 06:49:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11341; Sat, 26 Aug 1995 06:49:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09486; Sat, 26 Aug 1995 06:49:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09414; Sat, 26 Aug 1995 06:36:53 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10776; Sat, 26 Aug 1995 06:36:41 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id NAA27703; Fri, 25 Aug 1995 13:35:49 -0700 Message-Id: <199508252035.NAA27703@hubbub.cisco.com> To: kre@munnari.OZ.AU, big-internet@munnari.OZ.AU, yakov@cisco.com Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Fri, 25 Aug 95 13:18:04 PDT." <199508252018.NAA11420@greatdane.cisco.com> Date: Fri, 25 Aug 95 13:35:38 PDT From: Yakov Rekhter Precedence: bulk Robert, > > Let's back up. As I understand it, in your scheme, there is a set of > routers which have a table which contains every possible /24 prefix in > the IPv4 address space. Is this correct? > > Approximately. What's actually required is a mapping from > every existing advertised prefix. Let's assume that the total number of existing advertised prefixes is N. Is it correct that the mapping table would need to have N entries as well ? If not, then what is that number ? Yakov. From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 06:52:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11445; Sat, 26 Aug 1995 06:52:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09508; Sat, 26 Aug 1995 06:52:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09457; Sat, 26 Aug 1995 06:43:14 +1000 Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11003; Sat, 26 Aug 1995 06:43:02 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA23377; Fri, 25 Aug 95 16:42:59 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9508252042.AA23377@wizard.gsfc.nasa.gov> Subject: Re: encaps and NHRP To: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 25 Aug 1995 16:42:59 -0400 (EDT) Cc: yakov@cisco.com, doleary@cisco.com, Big-Internet@munnari.OZ.AU In-Reply-To: <12474.809266804@munnari.OZ.AU> from "Robert Elz" at Aug 24, 95 10:20:04 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1470 Precedence: bulk > Is not true. Routing is certainly carried over the core, > just not the routes to the eventual IP end point destinations. > Routing for the addresses used to traverse the core still exists. > > Further, the mechanism by which te mapping table is distributed > can evolve into anything. If ROLC already has a nicer > solution to this than a file to FTP and install, then I'm > entirely willing to adopt it. > > kre I'm certainly not an expert on the subject, but it seems to me that BGP, which is already being used to exchange the dynamic routing information, could be modified to also be able to exchange the *fairly* static mapping/connectivity (this would also help to eliminate my fear of manually configured tables). The map updates would be done on a much less frequent basis than the routing updates, perhaps once an hour, and if necessary performed in separate processors from the routers, and then periodically uploaded into the routers in full (or the routers could request parts of the map on demand). By the way, I would think that Noel would like this approach since it amounts to distributing mapping information to augment the routing information. The mapping information could include multiple alternate pathways (routing hints) with preferences. It could start out simple and evolve into more detailed mapping information later. The lessons learned from this could even be useful to the IPv6 effort, albeit in different forms. -Bill From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 07:07:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11826; Sat, 26 Aug 1995 07:07:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA09563; Sat, 26 Aug 1995 07:07:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA09557; Sat, 26 Aug 1995 07:00:58 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11658; Sat, 26 Aug 1995 07:00:46 +1000 (from bsimpson@morningstar.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-08.dialip.mich.net [141.211.7.144]) by merit.edu (8.6.12/merit-2.0) with SMTP id RAA14344 for ; Fri, 25 Aug 1995 17:00:42 -0400 Date: Fri, 25 Aug 95 20:35:22 GMT From: "William Allen Simpson" Message-Id: <4534.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU (bigi) Subject: Re: IP Encapsulation Growth Proposal Precedence: bulk OK, I've spent the entire day on this, and hopefully it was at least as important as getting my IP Security code done.... The Routing Arbiter software is up and running, and provides exactly the information that would be needed for mapping the 30K routes to ASs, to be used for tunneling. Better yet, look at www.ra.net. The software is readily available. To look at your mappings, try "whois -h radb.ra.net /" which will tell you more than you ever wanted to know..... At this time, there are 4 groups all running the RIPE-181 database, talking to each other and the US NAPs. The problem is that many other places talking BGP, even in the US, still aren't using the database. But using it to route the "core" would be a real buy-in incentive.... Thanks to Elise Gerich for the help. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 07:53:51 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13210; Sat, 26 Aug 1995 07:53:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04593 Sat, 26 Aug 1995 07:15:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09528; Sat, 26 Aug 1995 06:54:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09455; Sat, 26 Aug 1995 06:43:13 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10994; Sat, 26 Aug 1995 06:42:59 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id QAA12424 for ; Fri, 25 Aug 1995 16:42:57 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id QAA25267 for ; Fri, 25 Aug 1995 16:42:56 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA23584; Fri, 25 Aug 95 16:52:18 EDT Message-Id: <9508252052.AA23584@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 16:41:56 -0400 To: Dave Crocker , jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Robert Moskowitz Subject: Re: firewalls and data integrity Cc: big-internet@munnari.OZ.AU Precedence: bulk At 12:50 PM 8/25/95 -0700, Dave Crocker wrote: >At 11:12 AM 8/25/95, Noel Chiappa wrote: >>Hmm. My understanding is that such transactions will usually be authenticated, >>and often encrypted. These would of course catch such problems. (You can look > > > Well, Noel, thanks for taking the example in a way that entirely >misses the concern. Let me try a different example that might be easier >for folks to relate to: > > You have a nighly job that uses ftp to transfer some Very > Important files across the net. > > Now, this is an existing facility. Existing protocol. >Well-established basis for very, very, VERY high reliability of data >integrity. > > With the advent of firewalls/proxies, we've just violated that >basis. Those files WILL eventually come across corrupted. I said WILL, >not maybe. Dave, having done this a lot already, I do not agree with this. The proxy process for an FTP is basically a byte pipe. Bytes in one process out the other. Perhaps if you are running on a Pentium based firewall ( : ) ), something might get corrupted. Whole NNTP feeds are going thorugh these now with no corruption. If you want to see bulk transfers. I think, though, what you are getting at might be an end condition. The sender says it is done and terminates the first link. But before the second link terminates properly, something fails. So the receiver thinks it got a partial transmit, but the sender thinks all is well. Law of averages says this will happen, it would seem. Got to go home for the Sabbath, have fun debating all of this! Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 08:07:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13876; Sat, 26 Aug 1995 08:07:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09641; Sat, 26 Aug 1995 08:06:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA09635; Sat, 26 Aug 1995 07:56:09 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13323; Sat, 26 Aug 1995 07:56:03 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id OAA21436; Fri, 25 Aug 1995 14:55:28 -0700 Date: Fri, 25 Aug 1995 14:55:28 -0700 From: Tony Li Message-Id: <199508252155.OAA21436@greatdane.cisco.com> To: bill@wizard.gsfc.nasa.gov Cc: tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <9508252150.AA23481@wizard.gsfc.nasa.gov> (bill@wizard.gsfc.nasa.gov) Subject: Re: ownership, leasing, renumbering, and that draft Precedence: bulk I would consider the pain threshold to be an organization whose size could be handled with a single Class C net. Single organizations of this size can probably renumber with a tolerable level of pain. To renumber larger organizations can be a very daunting task (talk about flag days) with extreme cost and associated pain. Let me reiterate: no one has ever proposed that you have to renumber as a flag day. There are reasonable time-periods (months) that this can be deployed in. Let's consider the tradeoffs carefully here. One approach has minimal impact to transit providers but a huge cost spread out over the end user sites and local providers, the degree of pain to individual organizations being directly related to the size of the organization. The other approach has minimal impact to the end users but requires a development effort on the part of the IETF and the maintainers of the "core" routing infrastructure, a much smaller set. If the mapping/ encapsulation scheme is technically feasible, i.e. doesn't have any fatal technical flaws, I believe it should be seriously investigated and pursued. What we've been trying to tell you is that it is fatally flawed. Tony From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 08:10:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14053; Sat, 26 Aug 1995 08:10:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09661; Sat, 26 Aug 1995 08:07:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA09618; Sat, 26 Aug 1995 07:47:19 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12802; Sat, 26 Aug 1995 07:47:10 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04747 Sat, 26 Aug 1995 07:24:31 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.40] ([204.247.5.24]) by aimnet.com (8.6.12/8.6.12) with SMTP id OAA00727; Fri, 25 Aug 1995 14:21:22 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 14:21:57 -0700 To: Robert Moskowitz From: Dave Crocker Subject: Re: firewalls and data integrity Cc: big-internet@munnari.OZ.AU Precedence: bulk Bob, >> With the advent of firewalls/proxies, we've just violated that >>basis. Those files WILL eventually come across corrupted. I said WILL, >>not maybe. > >Dave, having done this a lot already, I do not agree with this. > >The proxy process for an FTP is basically a byte pipe. Bytes in one process >out the other. Perhaps if you are running on a Pentium based firewall ( : ) >), something might get corrupted. The proxy process is an interface. Interfaces are the exact architectural places for "interesting" forms of failure and data corruption/loss. As I said in my earlier note, we have lots and lots of Internet experience with the truth of these failures. They DO occur. In the absence of end-to-end reliability mechanisms, they occur in a manner which is, at least sometimes, undetected in real time. One more time: this isn't an academic point. I have my own anecdotes. Others have theirs. Mine involve XNS vs. TCP over WANs and NFS without UDP checksums over WANs. The latter is quite famous. In both cases, the failures hit random places within a file. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 08:20:45 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14548; Sat, 26 Aug 1995 08:20:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06292 Sat, 26 Aug 1995 08:11:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09685; Sat, 26 Aug 1995 08:09:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA09621; Sat, 26 Aug 1995 07:52:32 +1000 Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13136; Sat, 26 Aug 1995 07:52:10 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA23481; Fri, 25 Aug 95 17:50:44 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9508252150.AA23481@wizard.gsfc.nasa.gov> Subject: Re: ownership, leasing, renumbering, and that draft To: dcrocker@brandenburg.com (Dave Crocker) Date: Fri, 25 Aug 1995 17:50:43 -0400 (EDT) Cc: tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: from "Dave Crocker" at Aug 24, 95 08:31:12 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2494 Precedence: bulk > At 3:52 AM 8/24/95, Tony Li wrote: > > Forcing renumbering can put immense pain at the end points, > > > >It's pretty clear from the statements that we've heard that "immense > >pain" is not a reasonable characterization. > > I'm inclined to agree with you. "disastrous pain" would probably > be a better characterization. In effect it causes organizations of any > significant size to be unable to afford the cost of changing providers. > > Then again, maybe the problem is with the word 'pain'. For local > providers unable to change transit providers, it's definitely not strong > enough. > > d/ Let me concur completely with Dave. I would consider the pain threshold to be an organization whose size could be handled with a single Class C net. Single organizations of this size can probably renumber with a tolerable level of pain. To renumber larger organizations can be a very daunting task (talk about flag days) with extreme cost and associated pain. If the necessary set of integrated network management tools and host software features existed to make renumbering simple and painless, that would be different, but they don't and won't for some time. In the case of a local provider trying to coordinate address renumbering for possibly hundreds of sites when changing their higher level provider, it's just mind boggling what would be required. Let's consider the tradeoffs carefully here. One approach has minimal impact to transit providers but a huge cost spread out over the end user sites and local providers, the degree of pain to individual organizations being directly related to the size of the organization. The other approach has minimal impact to the end users but requires a development effort on the part of the IETF and the maintainers of the "core" routing infrastructure, a much smaller set. If the mapping/ encapsulation scheme is technically feasible, i.e. doesn't have any fatal technical flaws, I believe it should be seriously investigated and pursued. Finally, I openly admit my bias as someone representing the interests of end-user organizations, but all I'm saying is that the relative costs and distribution of costs of the two approaches needs to be carefully weighed and evaluated. I have no problem with the idea of economic incentives to encourage voluntary renumbering, as long as any such costs (of not renumbering) are openly disclosed by the provider before the initial connection of the user site. -Bill From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 08:26:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14817; Sat, 26 Aug 1995 08:26:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09736; Sat, 26 Aug 1995 08:26:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09719; Sat, 26 Aug 1995 08:22:20 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14624; Sat, 26 Aug 1995 08:22:06 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzejh28436; Fri, 25 Aug 1995 18:22:01 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Benefits of Geographic examples To: bsimpson@MorningStar.Com (William Allen Simpson) Date: Fri, 25 Aug 1995 18:22:01 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <4528.bsimpson@morningstar.com> from "William Allen Simpson" at Aug 25, 95 05:53:12 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 368 Precedence: bulk > So, they have the usual IP number which is _NOT_ under MCI or Sprint, > and has to be advertised worldwide separately. Hopefully, we can all > agree that this is bad. Why? If every multihomed site (customer or provider) in the world got a seperate address block, things would work just fine - there are only 814 of them today. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 08:28:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14892; Sat, 26 Aug 1995 08:28:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09756; Sat, 26 Aug 1995 08:28:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09716; Sat, 26 Aug 1995 08:21:11 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14547; Sat, 26 Aug 1995 08:20:45 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzejh28106; Fri, 25 Aug 1995 18:18:40 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: "Provider-based addresses" is bad terminology To: bsimpson@MorningStar.Com (William Allen Simpson) Date: Fri, 25 Aug 1995 18:18:40 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <4529.bsimpson@morningstar.com> from "William Allen Simpson" at Aug 25, 95 06:52:20 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1102 Precedence: bulk > The provider-assigned addresses have no relation to the actual > interconnections of the topology. Whan all the traffic between > providers goes through one NAP, even though they are connected at many > NAPs, it is operationally and experiencially clear to the rest of us > that provider-based is NOT working. Huh? Address allocation by provider is about a close to the real topology that you can get. The fact that there happens to be quite a bit of traffic flowing over something like 6 (not just one) interexchanges does not change this. [The 6 exchanges that I am revering to are MAE-East, MAE-West, FIX-East, FIX-West, Sprint Nap, and Stockholm Nap. There are probably others that I am forgetting about at the moment.] Operationally there is still more being done to exchange more traffic at more exchange points (and more properly balance the existing ones); this has nothing to do w/ assigning addresses though. If you want to talk about operational problems, please move to other lists - mae-east or nanog or mae-west or something else. Not here. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 08:46:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15694; Sat, 26 Aug 1995 08:46:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09801; Sat, 26 Aug 1995 08:46:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09778; Sat, 26 Aug 1995 08:33:47 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15193; Sat, 26 Aug 1995 08:33:43 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzeji29886; Fri, 25 Aug 1995 18:33:24 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: ownership, leasing, renumbering, and that draft To: bill@wizard.gsfc.nasa.gov (Bill Fink) Date: Fri, 25 Aug 1995 18:33:23 -0400 (EDT) Cc: yakov@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <9508252014.AA23314@wizard.gsfc.nasa.gov> from "Bill Fink" at Aug 25, 95 04:14:17 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 197 Precedence: bulk > I think when the Internet > starts using route aggregation on a large scale, which it will have to > at some point, It is already and has been for some time. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 08:48:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15730; Sat, 26 Aug 1995 08:48:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09823; Sat, 26 Aug 1995 08:48:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09781; Sat, 26 Aug 1995 08:36:28 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15285; Sat, 26 Aug 1995 08:36:24 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzeji00548; Fri, 25 Aug 1995 18:36:21 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: "Provider-based addresses" is bad terminology To: bsimpson@MorningStar.Com (William Allen Simpson) Date: Fri, 25 Aug 1995 18:36:21 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <4532.bsimpson@morningstar.com> from "William Allen Simpson" at Aug 25, 95 07:49:31 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 596 Precedence: bulk > And it is a fact that it IS NOT actually working. Routers are sending > packets past local connections, indeed right past the Chicago NAP, to > the East Coast, where we are experiencing terrible congestion. This > appears to be because of shortest prefix matching, which forces > everything into a heirarchy instead of a mesh. Actually its more probably that the Chicago Nap does not yet work than anything else. Have you contacted your providers & found out why this is going on? They may have very valid reasons for not using some exchange or another. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 08:50:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15787; Sat, 26 Aug 1995 08:50:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA09845; Sat, 26 Aug 1995 08:49:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09795; Sat, 26 Aug 1995 08:45:14 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15676; Sat, 26 Aug 1995 08:45:08 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.40] ([204.247.5.55]) by aimnet.com (8.6.12/8.6.12) with SMTP id PAA11132; Fri, 25 Aug 1995 15:44:30 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 15:45:05 -0700 To: Tony Li From: Dave Crocker Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU Precedence: bulk At 2:55 PM 8/25/95, Tony Li wrote: >Let me reiterate: no one has ever proposed that you have to renumber >as a flag day. There are reasonable time-periods (months) that this >can be deployed in. speaking of transition issues... slowness does not mean easiness or cheapness. For that matter, what IS the sequence that takes place when changing providers requires changing addresses? How is the (slow) organization switchover handled with the (sometimes quick) switchover of providers? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 09:46:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18418; Sat, 26 Aug 1995 09:46:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA09917; Sat, 26 Aug 1995 09:46:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA09902; Sat, 26 Aug 1995 09:32:48 +1000 Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17741; Sat, 26 Aug 1995 09:32:45 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id TAA24398; Fri, 25 Aug 1995 19:32:41 -0400 Date: Fri, 25 Aug 1995 19:32:41 -0400 From: Vadim Antonov Message-Id: <199508252332.TAA24398@titan.sprintlink.net> To: asp@uunet.uu.net, bsimpson@MorningStar.Com Subject: Re: "Provider-based addresses" is bad terminology Cc: big-internet@munnari.OZ.AU Precedence: bulk asp> Huh? Address allocation by provider is about a close to the real asp> topology that you can get. The fact that there happens to be quite a asp> bit of traffic flowing over something like 6 (not just one) asp> interexchanges does not change this. Well, a provider may want to have more than block in the AS, to play preference games thru different exchange points. In the ideal world all backbones have the same load and bandwidth, so hot-potato routing is fine. In the real world there's a need to do MEDs. SprintLink's numbering plan is to have a block per POP (ideally). In practice, as InterNIC refused to allocate large enough blocks each pop has several /16s and (later) /15s. It is still a provider-based allocation, but the provider has the internal "structure" imposed by geography (the latencies on long-haul links are large enough, so additional routing information is provided to optimize paths). The blocks are aggregated within POPs, so the aggregates have proper metrics, and the backbone does not carry the individual customer routes, except for out-of-POP connections. --vadim From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 11:06:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21746; Sat, 26 Aug 1995 11:06:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA10003; Sat, 26 Aug 1995 11:06:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA09997; Sat, 26 Aug 1995 10:55:23 +1000 Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21435; Sat, 26 Aug 1995 10:55:19 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA23727; Fri, 25 Aug 95 20:53:59 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9508260053.AA23727@wizard.gsfc.nasa.gov> Subject: Re: ownership, leasing, renumbering, and that draft To: tli@cisco.com (Tony Li) Date: Fri, 25 Aug 1995 20:53:58 -0400 (EDT) Cc: tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <199508252155.OAA21436@greatdane.cisco.com> from "Tony Li" at Aug 25, 95 02:55:28 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 969 Precedence: bulk > Let me reiterate: no one has ever proposed that you have to renumber > as a flag day. There are reasonable time-periods (months) that this > can be deployed in. OK, that will make it somewhat more manageable, but slow, spreadout pain is still pain, and still has a significant, operational cost, that is directly proportional to the size of the organization (or the number of sites for a local provider). > If the mapping/ > encapsulation scheme is technically feasible, i.e. doesn't have any > fatal technical flaws, I believe it should be seriously investigated > and pursued. > > What we've been trying to tell you is that it is fatally flawed. I've read all the messages to this point, and I still haven't heard any arguments that I would consider fatal flaws in the mapping/encaps proposal. Could you or someone else succinctly state what you consider the fatal flaws? > Tony -Bill From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 11:26:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22364; Sat, 26 Aug 1995 11:26:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA10054; Sat, 26 Aug 1995 11:26:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA10037; Sat, 26 Aug 1995 11:18:50 +1000 Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22109; Sat, 26 Aug 1995 11:18:36 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA23750; Fri, 25 Aug 95 21:17:16 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9508260117.AA23750@wizard.gsfc.nasa.gov> Subject: Re: ownership, leasing, renumbering, and that draft To: asp@uunet.uu.net (Andrew Partan) Date: Fri, 25 Aug 1995 21:17:15 -0400 (EDT) Cc: yakov@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: from "Andrew Partan" at Aug 25, 95 06:33:23 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 899 Precedence: bulk > > I think when the Internet > > starts using route aggregation on a large scale, which it will have to > > at some point, > > It is already and has been for some time. > --asp@uunet.uu.net (Andrew Partan) I realize that significant use of route aggregation is already happening. What I meant by on a large scale was when the bulk of the "core" traffic was routed using highly aggregated routes rather than the many individual atomic routes currently being advertised. Are we there yet? Does anyone have a handle on what portion of the address space (in /24 size chunks) that is actually actively being used (as opposed to just being allocated) is being routed via atomic routes versus CIDR aggregated routes? Does anyone have a handle on how much traffic is being blackholed due to the loss of more specific routing information that is an inherent feature of route aggregation? -Bill From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 11:31:06 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22465; Sat, 26 Aug 1995 11:31:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA10077; Sat, 26 Aug 1995 11:27:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA10013; Sat, 26 Aug 1995 11:07:18 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21753; Sat, 26 Aug 1995 11:07:15 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id SAA15615; Fri, 25 Aug 1995 18:07:12 -0700 Date: Fri, 25 Aug 1995 18:07:12 -0700 From: Tony Li Message-Id: <199508260107.SAA15615@greatdane.cisco.com> To: bill@wizard.gsfc.nasa.gov Cc: big-internet@munnari.OZ.AU In-Reply-To: <9508260053.AA23727@wizard.gsfc.nasa.gov> (bill@wizard.gsfc.nasa.gov) Subject: Re: ownership, leasing, renumbering, and that draft Precedence: bulk I've read all the messages to this point, and I still haven't heard any arguments that I would consider fatal flaws in the mapping/encaps proposal. Could you or someone else succinctly state what you consider the fatal flaws? At the risk of boring everyone else to tears: The mapping/encaps proposal has as one of it's prerequisites a default-free router. To be specific, the last exchange was: Let's back up. As I understand it, in your scheme, there is a set of routers which have a table which contains every possible /24 prefix in the IPv4 address space. Is this correct? Approximately. What's actually required is a mapping from every existing advertised prefix. Please note the last clause. Let us suppose that such a router exists and can switch packets at some non-trivial rate and has sufficient connectivity that we can actually build a _service_ from them. Note that kre proposes that CIDR be used in conjunction with this scheme as the means of performing sufficient aggregation so that this router can even exist. If such a router exists, then in kre's scheme, it is used to tunnel across another fabric (such as CLNP). However, if such a router exists, it could also be used to route IPv4 packets directly. Thus, the problem is still solved and no new hardware development needs to be done. My analysis is that the mapping scheme fails to address the key issue: scaling the number of advertised prefixes. Tony From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 11:46:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23028; Sat, 26 Aug 1995 11:46:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA10113; Sat, 26 Aug 1995 11:46:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA10064; Sat, 26 Aug 1995 11:27:06 +1000 Received: from valinor.barrnet.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22365; Sat, 26 Aug 1995 11:26:58 +1000 (from vaf@valinor.barrnet.net) Received: (from vaf@localhost) by valinor.barrnet.net (8.6.8/8.6.6) id SAA09143; Fri, 25 Aug 1995 18:28:24 -0700 Date: Fri, 25 Aug 95 18:28:23 PDT From: Vince Fuller To: "William Allen Simpson" Cc: big-internet@munnari.OZ.AU Phone: (415) 528-7227 Usmail: 3801 East Bayshore Rd, Palo Alto, CA, 94303 Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of Fri, 25 Aug 95 19:34:52 GMT Message-Id: Precedence: bulk As usual, the subject has wandered from the original. Vince, we are all in agreement that we need a "something" that follows the topology. I think (although some will argue with abtruse technical sematics) that we are all in agreement about addresses matching topology. We are discussing a mechanism to do that -- WITHOUT requiring all the IPv4 end users to renumber their IP addresses. The point is that the IP addresses can either be hierarchical addresses (locators as Noel would call them) or they can be Endpoint IDs. If you don't want them to change when the topology changes, then they ARE NOT addresses. You can't have it both ways. Adding a lookup table in the middle is a way of adding a layer of indirection and turning the "IP addresses" used by the end-systems into endpoint IDs. The current proposal on the table is to map to AS numbers, probably using the existing IP->AS mapping already distributed for BGP. Then, we can painlessly renumber the ASs [sic] to match the topology. Now, what technical problems have you uncovered with this proposal? Many of the problems associated with the original IP Encaps proposal, i.e. ICMP semantics, MTU sizes/fragmentation, etc. are just as applicable now as they were then. I'd love to see a detailed specification for this proposal that addresses the known problems with IP Encaps. Maybe after such a proposal has been written and it has been clearly elucidated that the proposal really solves new problems and can do so in a timely way, the people who really matter (i.e. the router software vendors) might take it a bit more seriously. When can we expect to see that detailed proposal? What is the estimated time to code and debug an implementation of it? And what about a deployment and transition schedule? Without any of this in hand, the only tool available for allowing the Internet to continue to scale is the use of topologically-oriented addressing. And before you or Crocker spew on about how topologycally-oriented addressing is a plot by providers to avoid expensive equipment and software deployment, who do you think would ultimately pay for such equipment if it existed? The users would, in the form of higher costs from the providers. Providers are generally in the business to make money or at the very least, not lose it (money-losing businesses tend not to be around very long). This means that if expenses go up, prices go up, too. --Vince From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 12:47:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25248; Sat, 26 Aug 1995 12:47:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA10185; Sat, 26 Aug 1995 12:46:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA10168; Sat, 26 Aug 1995 12:39:41 +1000 Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24910; Sat, 26 Aug 1995 12:39:31 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA23869; Fri, 25 Aug 95 22:38:12 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9508260238.AA23869@wizard.gsfc.nasa.gov> Subject: Re: ownership, leasing, renumbering, and that draft To: tli@cisco.com (Tony Li) Date: Fri, 25 Aug 1995 22:38:11 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199508260107.SAA15615@greatdane.cisco.com> from "Tony Li" at Aug 25, 95 06:07:12 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1088 Precedence: bulk > My analysis is that the mapping scheme fails to address the key issue: > scaling the number of advertised prefixes. > > Tony Tony, The number of routes exchanged over the "core" by BGP can be constrained to a manageable number, which can be made to be much less than the current number of routes being handled by the "core". Therefore, this part has been proven to be doable. The much larger number of active /n (where n <= 24) prefixes will be mapped to the much smaller set of routes being exchanged by the core via the mapping table, but will not generally need to be advertised by the "core" routers. Since entries in the mapping table will not change that frequently, it should be possible to manage the updates to the table, even though the table itself will be much larger than the current routing tables. As kre pointed out, although the size of this table is large, it is bounded to a manageable size in the very worst case (which we won't get to for quite a while). I don't see what part of this aspect of the proposal isn't feasible. What am I missing? -Bill From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 14:07:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB28047; Sat, 26 Aug 1995 14:07:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA10276; Sat, 26 Aug 1995 14:06:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA10270; Sat, 26 Aug 1995 14:00:59 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27825; Sat, 26 Aug 1995 14:00:55 +1000 (from bsimpson@morningstar.com) Received: from merit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14536 Sat, 26 Aug 1995 14:00:51 +1000 (from bsimpson@morningstar.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-08.dialip.mich.net [141.211.7.176]) by merit.edu (8.6.12/merit-2.0) with SMTP id XAA23509 for ; Fri, 25 Aug 1995 23:59:32 -0400 Date: Sat, 26 Aug 95 03:35:52 GMT From: "William Allen Simpson" Message-Id: <4539.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: Cisco can't policy route? Precedence: bulk > From: Tony Li > Approximately. What's actually required is a mapping from > every existing advertised prefix. > > Please note the last clause. Let us suppose that such a router exists > and can switch packets at some non-trivial rate and has sufficient > connectivity that we can actually build a _service_ from them. > Is this an official declaration that you know of no such router that currently exists? That is, Cisco does not produce a router that can currently "switch" packets based on the RADB for every site prefix in the Internet? This certainly is at variance from other Cisco advertisements. AND your previous statements to IETF WGs. It is most important that we understand this before proceeding further. Is the Internet already broken? Are we too late? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 14:09:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28126; Sat, 26 Aug 1995 14:09:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA10298; Sat, 26 Aug 1995 14:09:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA10267; Sat, 26 Aug 1995 13:59:38 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27791; Sat, 26 Aug 1995 13:59:35 +1000 (from bsimpson@morningstar.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-08.dialip.mich.net [141.211.7.176]) by merit.edu (8.6.12/merit-2.0) with SMTP id XAA23506 for ; Fri, 25 Aug 1995 23:59:30 -0400 Date: Sat, 26 Aug 95 03:22:33 GMT From: "William Allen Simpson" Message-Id: <4538.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal Precedence: bulk > From: Vince Fuller > We are discussing a mechanism to do that -- WITHOUT requiring all the > IPv4 end users to renumber their IP addresses. > > The point is that the IP addresses can either be hierarchical addresses > (locators as Noel would call them) or they can be Endpoint IDs. If you don't > want them to change when the topology changes, then they ARE NOT addresses. Yes, Vince, and if you'd have been paying attention, you'd know that I was an early supporter of separating Locators from Identifiers (before they were called that). You might, perhaps, have read all of my SIP, SIPP, and IPv6 drafts, wherein I used the new terms. The thingies in the actual IP header are labeled "IP Addresses" in RFC-791, and I have a tendency to call them that explicitly -- that is, by coupling the label "IP" followed by (concatenated with) "Address" -- in order to be understood by the audience. Thank you for pointing out the obvious. Now, could we get to the technical details? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 14:46:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29586; Sat, 26 Aug 1995 14:46:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA10356; Sat, 26 Aug 1995 14:46:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA10341; Sat, 26 Aug 1995 14:35:21 +1000 Received: from ns.iij.ad.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29074; Sat, 26 Aug 1995 14:35:18 +1000 (from davidc@iij.ad.jp) Received: from argus.iij.ad.jp (argus.iij.ad.jp [192.244.176.41]) by ns.iij.ad.jp (8.6.12+2.4W/3.3W9-NS) with SMTP id NAA28667; Sat, 26 Aug 1995 13:35:00 +0900 Message-Id: <199508260435.NAA28667@ns.iij.ad.jp> To: Dave Crocker Cc: Robert Moskowitz , big-internet@munnari.OZ.AU, davidc@ns.iij.ad.jp Subject: Re: firewalls and data integrity In-Reply-To: Your message of "Fri, 25 Aug 1995 14:21:57 MST." Date: Sat, 26 Aug 1995 13:36:33 +0900 From: David R Conrad Precedence: bulk > One more time: this isn't an academic point. I have my own >anecdotes. Others have theirs. Mine involve XNS vs. TCP over WANs and NFS >without UDP checksums over WANs. The latter is quite famous. Umm, Dave? This UDP checksum stuff doesn't violate your end-to-end architecture religion (at least the ones I heard about didn't). If you want to be sure your data isn't corrupted, use something like MD5 for the valuable bits prior to transmission and verify at the other end. This works in both the end-to-end model and the end-to-firewall-to-firewall-to-end model. Regards, -drc From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 15:07:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00300; Sat, 26 Aug 1995 15:07:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA10400; Sat, 26 Aug 1995 15:06:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA10394; Sat, 26 Aug 1995 15:05:27 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00272; Sat, 26 Aug 1995 15:05:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15745; Sat, 26 Aug 95 01:04:58 -0400 Date: Sat, 26 Aug 95 01:04:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508260504.AA15745@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Vince Fuller hierarchical addresses (locators as Noel would call them) Err, let me be slightly picky about terminology here. The term "locator" was defined to mean "address which is not carried in every packet". E.g. if you have a flow-id in every packet, or some kind of endpoint name, then you don't really have to have the address as well (as long as the router knows what to do with those packets). This is particularly useful if the addresses are i) long, and ii) variable length. The term was created because some people seemed to have a hard time wrapping their minds around the concept that one might have "addresses" which weren't in every packet. I am a firm fan of variable length addresses, but realize their overhead costs, and long ago came up with designs which did not have them in every packet. However, I kept hearing "but variable length addresses will be inefficient because you have to put them in every packet". Well, no you don't, actually. I don't know of a specific term for "hierarchical address" other than "hierarhical address". If you don't want them to change when the topology changes, then they ARE NOT addresses. You can't have it both ways. Err, well, to be precise, you could: the routing has to track them directly, then (as in a bridged network). Of course, in a large net this can mean so much overhead that it's effectively impossible, of course. Noel From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 15:43:18 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01538; Sat, 26 Aug 1995 15:43:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17637 Sat, 26 Aug 1995 15:31:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA10487; Sat, 26 Aug 1995 15:26:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA10451; Sat, 26 Aug 1995 15:12:12 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00465; Sat, 26 Aug 1995 15:11:54 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by shark.mel.dit.csiro.au with SMTP id AA18935 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 26 Aug 1995 15:10:17 +1000 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA25654; Fri, 25 Aug 1995 22:07:32 -0700 Date: Fri, 25 Aug 1995 22:07:32 -0700 From: Tony Li Message-Id: <199508260507.WAA25654@greatdane.cisco.com> To: bill@wizard.gsfc.nasa.gov Cc: big-internet@munnari.OZ.AU In-Reply-To: <9508260238.AA23869@wizard.gsfc.nasa.gov> (bill@wizard.gsfc.nasa.gov) Subject: Re: ownership, leasing, renumbering, and that draft Precedence: bulk > My analysis is that the mapping scheme fails to address the key issue: > scaling the number of advertised prefixes. The number of routes exchanged over the "core" by BGP can be constrained to a manageable number, which can be made to be much less than the current number of routes being handled by the "core". Therefore, this part has been proven to be doable. Bill, the exchange of routes via BGP is not the foremost problem anymore. It is maintaining the advertised prefixes at the switching engine and accessing them at line rate. Tony From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 16:27:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02956; Sat, 26 Aug 1995 16:27:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA10590; Sat, 26 Aug 1995 16:26:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA10573; Sat, 26 Aug 1995 16:12:16 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02350; Sat, 26 Aug 1995 16:12:13 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.58] ([204.247.5.11]) by aimnet.com (8.6.12/8.6.12) with SMTP id XAA17849; Fri, 25 Aug 1995 23:09:49 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 23:10:26 -0700 To: Vince Fuller From: Dave Crocker Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk Vince (or anyone else), At 6:28 PM 8/25/95, Vince Fuller wrote: >Many of the problems associated with the original IP Encaps proposal, i.e. >ICMP semantics, MTU sizes/fragmentation, etc. are just as applicable now as I made a request for information about real and hard MTU limits for "core" routers and would appreciate some response on this. The query is not for the current limit, per se, but for a description of the underlying reasons for it or some other number to be a hard limit that can't reasonably be changed. >And before you or Crocker spew on about how topologycally-oriented addressing >is a plot by providers to avoid expensive equipment and software deployment, Well, my memory is even flakier than my opinions these days, so I'd appreciate your providing me with a copy of any messages I sent to the list that said this. I sure don't remember making such a claim. (Hmmm. For some reason the form of your comment does prompt me to wonder whether I am now supposed to claim personal insult and challenge you to a duel. Dunno. Perhaps the cidrd wg chair can make that determination?) >who do you think would ultimately pay for such equipment if it existed? The >users would, in the form of higher costs from the providers. Providers are I DO have some vague recollection of suggesting that a fair comparison of costs for the current approach versus this alternative be made and, yes, I did predict that the alternative would be considerably cheaper. Much cheaper. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 16:30:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03041; Sat, 26 Aug 1995 16:30:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA10612; Sat, 26 Aug 1995 16:29:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA10559; Sat, 26 Aug 1995 16:07:36 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02292; Sat, 26 Aug 1995 16:07:27 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.58] ([204.247.5.11]) by aimnet.com (8.6.12/8.6.12) with SMTP id XAA17588; Fri, 25 Aug 1995 23:06:38 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 23:07:15 -0700 To: David R Conrad From: Dave Crocker Subject: Re: firewalls and data integrity Cc: big-internet@munnari.OZ.AU, davidc@ns.iij.ad.jp Precedence: bulk At 9:36 PM 8/25/95, David R Conrad wrote: >Umm, Dave? This UDP checksum stuff doesn't violate your end-to-end >architecture religion (at least the ones I heard about didn't). If >you want to be sure your data isn't corrupted, use something like MD5 Umm, David, turning off UDP checksum meant there was no end-to-end data integrity. If you can explain otherwise, please do. Running that over WANs rather than just single-segment ethernet's (with their high quality hardware checksum) meant that data corruptions DID occur and WEREN'T detected. And ummm, David, you can DESIGN an extra layer of protection to take care of any issue like this. All you are doing then is to create an end-to-end integrity mechanism and that is just spiffy for a NEW service. The question is how to deal with the hole that app proxies create for EXISTING services. By the way, the religion isn't "mine". It is merely a basic lesson that is being lost. I didn't create it. I learned it long after it was well established. It was, in fact, a controversial feature in TCP, put there because of data loss/corruption experiences from the Arpanet. When I later worked at a LAN company that primarily used an XNS-derivative protocol with no end-to-end checksum, I watched the company nearly lose a very major account because of file data corruptions that were proving nearly impossible to predict (detect) and even more difficult to diagnose. Eventually a piece of bad interface hardware was found to be concatenating packets occasionally. Had TCP been used, a small degradation in throughput and some increments to error counters would have been the only effects, rather than user data corruption. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 16:47:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03703; Sat, 26 Aug 1995 16:47:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA10670; Sat, 26 Aug 1995 16:46:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA10626; Sat, 26 Aug 1995 16:30:59 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03048; Sat, 26 Aug 1995 16:30:56 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA29501; Fri, 25 Aug 1995 23:30:53 -0700 Date: Fri, 25 Aug 1995 23:30:53 -0700 From: Tony Li Message-Id: <199508260630.XAA29501@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson) Subject: Re: Multi-homed sites Precedence: bulk [WARNING: Extra long. Get coffee now.] Ran, I've mentioned this approach [metro addressing] in the past. I've been unhappy that various folks (not Noel) have rejected it out of hand without explaining why they think it wouldn't work for sites having the above properties. Well, this is a note to attempt to remedy that. Let me first point out that an addressing plan that is specific to only a small number of sites is insufficiently general. But, on with the fun (and my apologies if I lecture)... My preference for NRL-DC, which campus has not moved since it was created just after WW-I and is pretty darn unlikely to ever move, would be for NRL-DC to have an IPv6 address space that looked something like: The "Routing Prefix for FIX-EAST" chunk would be the only prefix that most network providers would need to store in their routing tables. This is a close relative of metro addressing. Let's start by looking at what we have to do to support this. We can first carve up some address space out of our address. To be more generic we can call this: We need to give you some part for the local address. Note that this needs to be large enough to fit most of the customers at your metro inter-exchange, but not so large that it wastes address space. It doesn't have to fit the biggest organizations because we can simply give them multiple organization identifiers. Note that the _attempt_ here is to avoid renumbering so that this size is fixed across all service providers at that metro interconnect. Next, we need to provide some space for the organization identifier. If we make this too large, it becomes extremely painful because we must have flat routing at the metro interconnect. You are correct when you write: The service providers for NRL would also need to store a routing prefix like "" (this seems reasonable since they'd be getting $$$ to do this). You should note that ALL service providers at the metro interconnect must store this prefix, even those that are not providing you service. This can become a significant barrier to entry to a smaller service providers which would like to join the metro interconnect as they have full metro interconnect routing tables as soon as they connect, even before they add customer number one. I have some anti-trust concerns here, but they should be a different conversation. The other problem is that of scalability. The lookup that needs to happen at switching time is now a completely flat table of all customers of the metro interconnect. It grows as the number of customers grows (i.e., exponentially) until it fills the organization identifier portion of the address. Dr. Deering would have this space be in the millions. This seems too small for the total number of customers of a major interconnect, yet too large to be performing a lookup in less than tens of nanoseconds. When the organization identifier space fills, we have to get another metro prefix for the interconnect, injecting another route into the (presumably) next higher layer of the hierarchy. Now, note that we would like to achieve some reasonable address utilization. Without very good address utilization, IPv? simply runs out of address space before the end of its alloted lifetime. Recall that the overall utilization of the address space is the product of the utilizations at each level of the hierarchy. Because the local part is fixed and we're trying to address many consumers at many different sizes, we can have substantial lossage if we're not careful. An obvious hack here is to get many organizations to share an organization identifier. However, this is problematic, as this is equivalent to tying the organization to a particular set of neighboring organizations. Consider the case when one of them wants to move to another service provider. They must either renumber or they are forced to advertise a longer prefix into the metro interconnect. Since the former is what we're trying to avoid, this implies that we're doing longest match routing (and not a trivial table lookup) at the metro interconnect. Alternately, we can just punt on this and have lousy address utilization at the leaves. Unfortunately, the leaves are where it's easiest to have good address utilization. Recall that the organization identifier field and the metro prefix are fixed and chosen before we start. The odds on guessing correctly and getting good utilization over time in either of these fields seems remote indeed. Can you tell me, over the next 30 years, how many customers will be at Fix-East? [Side hypothesis: fixed fields in an address inevitably yield poor address space utilization or poor aggregation.] The implications are frightening. NRL would then be constrained to pick from service providers that connected at FIX-EAST. A fine point. And if you were to leave that group of providers, you would be forced to renumber. As one of the goals here was to avoid renumbering, I believe that you've re-instituted provider (set) lock. Another point is that migration in this scheme is still painful. You would have to advertise a foreign prefix into your new metro interconnect until you did renumber. This implies that there is longest match routing at least above metro interconnects. Similarly, if you were multi-homed between two metro interconnects (say Fix-East and Mae-East), you would have the same problem. Again, as with ANY other hierarchical addressing scheme such "noise" in the system can only be recaptured by aggregation at higher layers. This scheme doesn't work everywhere but it sure does work for sites reasonably near a NAP or FIX or CIX or MAE point. Still reading? My, you're persistent and patient. ;-) This is perhaps the most fatal flaw. Establishing metro interconnects is not something that anyone can do lightly. There is no global government to dictate where they must go. As they each cost Real Money, providers will not establish a metro interconnect lightly. Thus, for those users who are not "near" a metro interconnect, they may end up allocated from a completely different metro interconnect. For example, today Los Angeles has no major interconnect. If we are to follow this addressing plan, we would need to number them out of Mae-West/Fix-West. Subsequently there might be a real Los Angeles interconnect (yeah, right, and they'll get a useful subway working there too). At that point, what happens? Unless we get very tricky ahead of time, all of the organizations end up renumbering. Even if we are tricky enough to forsee the Los Angeles interconnect, will we be smart enough to forsee the eventual exhaustion of that interconnect and the creation of the neighboring Pasadena interconnect? Van Nuys? Marina Del Rey? Similarly, if we assign Routing Prefixes to continents or world regions than that can help reduce the size of the routing tables. Carrying a single IPv6 route that means would suffice for many service providers (i.e. all that don't directly service Australia) Providers that directly service Australia have financial incentives to carry the additional routes of their Australian customers. So maybe the above would be consitued from parts that were or some such. The general thought here is the ability to perform regional or continental aggregation, which is something I believe that we DO have consensus on. In conclusion: I'd like folks to come away noticing that this propsal does not eliminate the need to have good renumbering technology. Once we do have good renumbering technology, many different addressing schemes become interesting. Tony From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 17:26:54 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04837; Sat, 26 Aug 1995 17:26:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA10733; Sat, 26 Aug 1995 17:26:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA10716; Sat, 26 Aug 1995 17:24:53 +1000 Received: from uucp13.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04799; Sat, 26 Aug 1995 17:24:49 +1000 (from vjs@calcite.rhyolite.com) Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id AAA19954; Sat, 26 Aug 1995 00:10:10 -0700 Received: from localhost (vjs@localhost) by calcite.rhyolite.com (8.6.5/8.6.5) id XAA26742 for Big-Internet@munnari.OZ.AU; Fri, 25 Aug 1995 23:51:52 -0600 Date: Fri, 25 Aug 1995 23:51:52 -0600 From: Vernon Schryver Message-Id: <199508260551.XAA26742@calcite.rhyolite.com> To: Big-Internet@munnari.OZ.AU Precedence: bulk To: Big-Internet@munnari.OZ.AU Subject: Re: firewalls and data integrity >>> With the advent of firewalls/proxies, we've just violated that >>>basis. Those files WILL eventually come across corrupted. I said WILL, >>>not maybe. >> >>Dave, having done this a lot already, I do not agree with this. >> >>The proxy process for an FTP is basically a byte pipe. Bytes in one process >>out the other. Perhaps if you are running on a Pentium based firewall ( : ) >>), something might get corrupted. > > The proxy process is an interface. Interfaces are the exact >architectural places for "interesting" forms of failure and data >corruption/loss. As I said in my earlier note, we have lots and lots of >Internet experience with the truth of these failures. They DO occur. In >the absence of end-to-end reliability mechanisms, they occur in a manner >which is, at least sometimes, undetected in real time. > > One more time: this isn't an academic point. I have my own >anecdotes. Others have theirs. Mine involve XNS vs. TCP over WANs and NFS >without UDP checksums over WANs. The latter is quite famous. In both >cases, the failures hit random places within a file. Yes, many of us know that without end-to-end protection, Bad Things(tm) can, have, and will happen. Everyone who doesn't know this should consult the UDP and TCP checksum error counters on the nearest big, active server. However, what is the law of nature that prevents a proxying firewall from using the checksum that arrived with a TCP segment or UDP packet as the checksum on the output, just as a router would? Thereby preserving the end-to-end nature of the checksum? True, this would involve a touch of layer violating, might not be possible on some, generally unimportant and small parts of the transfer (e.g. FTP control), and might be impractical using the 4.3BSD TCP/IP code on your UNIX favorite workstation, but what is impossible about it? Note that such a device, a genuine, dedicated proxy-firewall box might spend far fewer computrons/byte doing the proxying, since it would avoid most of that that nasty checksum computing and consequent d-cache busting, and not need any checksumming hardware. Vernon Schryver vjs@rhyolite.com From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 17:28:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04907; Sat, 26 Aug 1995 17:28:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA10755; Sat, 26 Aug 1995 17:28:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA10713; Sat, 26 Aug 1995 17:23:59 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04762; Sat, 26 Aug 1995 17:23:52 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Fri, 25 Aug 1995 13:18:04 MST." <199508252018.NAA11420@greatdane.cisco.com> Date: Sat, 26 Aug 1995 17:23:27 +1000 Message-Id: <12865.809421807@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Fri, 25 Aug 1995 13:18:04 -0700 From: Tony Li Message-ID: <199508252018.NAA11420@greatdane.cisco.com> Well, this is sufficient for my objection to stand. I'll not re-iterate unless you ask. Yes, please do, as so far I haven't seen anything I believe is a major problem with the proposal (there are questions about the details that need to be dealt with, but we haven't gotten that far yet). Please be sure to explain your objection, not just state it. That is, explain it in enough detail that morons like me can grasp. Eg: the words "does not scale" don't help, you have to show what grows to the point that it is unmanageable, or if I disagree, I have no basis on which to argue. But before you do, there were two other messages from you on this general thread... Date: Fri, 25 Aug 1995 18:07:12 -0700 From: Tony Li Message-Id: <199508260107.SAA15615@greatdane.cisco.com> The mapping/encaps proposal has as one of it's prerequisites a default-free router. Not prerequisites, more assumptions. If all routers are using default, then any routing table can be made smaller by simply shifting more routes into the "default" basket and lessening the current load (which might mean supplying a new router to handle the ones that were moved, to the new one, all the others are default). The assumption is that this doesn't work, and that there are default free routers - something has to be ultimately responsible. It is to handle the scaling problems with those routers that the scheme is proposed. What's actually required is a mapping from every existing advertised prefix. Please note the last clause. OK. Let us suppose that such a router exists and can switch packets at some non-trivial rate and has sufficient connectivity that we can actually build a _service_ from them. I think we believe such routers exist, and are what is driving the internet core right now. Note that kre proposes that CIDR be used in conjunction with this scheme as the means of performing sufficient aggregation so that this router can even exist. So it can continue to exist as the information to be distributed grows larger. If such a router exists, then in kre's scheme, it is used to tunnel across another fabric (such as CLNP). Yes, though I was proposing we use IPv4, not that that changes the principles. I actually received a very interesting suggestion that IPv6 be used, which has some very attractive advantages. Unfortunately, I'm not sure we're really ready for that quite yet, but a little later it may be the way to go. However, if such a router exists, it could also be used to route IPv4 packets directly. It can, and is, now, yes. So? Thus, the problem is still solved and no new hardware development needs to be done. Oh good. Then we're done, we don't need the draft-cidrd-ownership thing, and no-one ever needs to renumber, anytime, ever. I hadn't realised it was going to be that simple. I'm quite willing to do nothing at all, if that will work. I thought the problem was that it won't. My analysis is that the mapping scheme fails to address the key issue: scaling the number of advertised prefixes. Tony, I know you understand exponential growth. I am not sure however that you really understand upper bounds. The point is that the mapping table has an upper bound that is tractable. There is no scaling. Ideally we will, via many means, never reach that upper bound, but even if we do, we can still handle the table. If you believe that there is something in the mapping scheme that can grow too bit to be manageable, please say exactly what it is, how big it will become, and why that can't be handled. Date: Fri, 25 Aug 1995 22:07:32 -0700 From: Tony Li Message-Id: <199508260507.WAA25654@greatdane.cisco.com> Bill, the exchange of routes via BGP is not the foremost problem anymore. It is maintaining the advertised prefixes at the switching engine and accessing them at line rate. Well, that is two problems, not one. Maintaining the prefixes is still something we have to work out the details on I admit (using BGP, using ROLC work, using an ftp'd text file, using ...). Exactly how that will be done has not been decided, so I think its a little early to say that it is the real problem. Accessing at line rate seems to me to be a comparatively trivial problem. Obviously the way this is actually done is an implementation issue, and we don't want to specify that. However, one implementation technique that is blatantly obvious is a simple linear (64Mb) table, built from DRAM not SRAM or something horribly expensibe like that, in which case we are adding one DRAM access time to the forwarding path. Considering all the rest of what has to be done - including access list searches, forwarding table searches, header verification, ttl manipulation (with the associated header checksum), etc - I'd be very very surprised if one DRAM access were to really make that much difference to anything. This is not going to be the implementation to use initially of course, as that will certainly require modified hardware to contain that DRAM array, which current version routers don't have. Initially I would make the mapping table be simply a part of the forwarding table - such a table needs 8 bytes of data per entry, plus linkage overheads (say another 12 for up & two down pointers - but obviously I am not asking for anyone's implementation secrets here). That is convenient (for me) in that its a nice round number so I can multiply in my head... If we have 100K prefixes we need just 2Mb of forwarding table to deal with this. Normally with 100K routes we'd need all the overhead of routing table entries, which (so I gather) are hundreds of bytes big, and multiply by the number of paths to the destinations. The mapping scheme has none of this. Lastly, one more message that arrived as I was composing this... Date: Fri, 25 Aug 1995 22:04:11 -0700 From: Tony Li Message-Id: <199508260504.WAA25548@greatdane.cisco.com> It turns out that NAT is non-trivial because of the embedded addresses. Yes, I think we (most of us) understand that. Certainly doable, but non-trivial. But this is fascinating ... this is doable, which ammounts to remapping source & dest addresses in every packet passing through (ignoring the embedded addresses for now), which must mean looking them up in some kind of giant table - yet the mapping scheme that maps dest addresses only, is somehow impossible. Interesting. kre From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 17:47:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05678; Sat, 26 Aug 1995 17:47:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA10793; Sat, 26 Aug 1995 17:46:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA10775; Sat, 26 Aug 1995 17:39:20 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05228; Sat, 26 Aug 1995 17:39:10 +1000 (from kre@munnari.OZ.AU) To: Yakov Rekhter Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Fri, 25 Aug 1995 13:35:38 PDT." <199508252035.NAA27703@hubbub.cisco.com> Date: Sat, 26 Aug 1995 17:38:47 +1000 Message-Id: <12875.809422727@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Fri, 25 Aug 95 13:35:38 PDT From: Yakov Rekhter Message-ID: <199508252035.NAA27703@hubbub.cisco.com> Let's assume that the total number of existing advertised prefixes is N. OK. Is it correct that the mapping table would need to have N entries as well ? If not, then what is that number ? Yes, it is N. If you're about to claim, that then this obviously represents no saving, then you're wrong, the saving is that the mapping table entry is (much) smaller than the routing table entry, with a reasonable upper bound on its size, and further, doesn't depend on the number of paths to the destination. kre From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 17:51:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05945; Sat, 26 Aug 1995 17:51:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA10815; Sat, 26 Aug 1995 17:50:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA10789; Sat, 26 Aug 1995 17:44:25 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05548; Sat, 26 Aug 1995 17:44:21 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: asp@uunet.uu.net (Andrew Partan) Cc: big-internet@munnari.OZ.AU Subject: Administrivia. In-Reply-To: Your message of "Fri, 25 Aug 1995 16:39:24 -0400." Date: Sat, 26 Aug 1995 17:43:09 +1000 Message-Id: <12880.809422989@munnari.OZ.AU> Sender: kre@munnari.OZ.AU Precedence: bulk Date: Fri, 25 Aug 1995 16:39:24 -0400 (EDT) From: asp@uunet.uu.net (Andrew Partan) Message-ID: This is spurious to the discussion at hand and spurious in this mailing list. Please take this elsewhere to some other mailing list. Whether it is spurious to the topic at hand is irrelevant, Big-Internet is (and has always been) a multi threaded list. However, nothing related to the size, or growth, of the internet is suprious on this list. This list may not be the place best used to get problems fixed, but that doesn't mean that discussing them here is out of order. One thing that is out of order here is meta discussions about whether other discussions should be carried on here or not. Those discussions are definitely not related to the growth or size of the internet. kre From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 18:47:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07818; Sat, 26 Aug 1995 18:47:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA10890; Sat, 26 Aug 1995 18:46:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA10886; Sat, 26 Aug 1995 18:46:03 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07810; Sat, 26 Aug 1995 18:45:58 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA11089; Sat, 26 Aug 1995 01:45:54 -0700 Date: Sat, 26 Aug 1995 01:45:54 -0700 From: Tony Li Message-Id: <199508260845.BAA11089@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: <12865.809421807@munnari.OZ.AU> (message from Robert Elz on Sat, 26 Aug 1995 17:23:27 +1000) Subject: Re: Discussing encap/mapping proposal Precedence: bulk Please be sure to explain your objection, not just state it. I've tried to do that below. The assumption is that ... there are default free routers - something has to be ultimately responsible. Let us suppose that such a router exists and can switch packets at some non-trivial rate and has sufficient connectivity that we can actually build a _service_ from them. I think we believe such routers exist, and are what is driving the internet core right now. Correct. Note that the key scaling problems with these routers is the growth in the number of advertised prefixes. So the fact that such routers exist today is NOT sufficient to conclude that those same routers will suffice in the future. Or that we can develop such a series of routers over time such that we have a deployed, stable router base before the previous generation expires. Note that kre proposes that CIDR be used in conjunction with this scheme as the means of performing sufficient aggregation so that this router can even exist. So it can continue to exist as the information to be distributed grows larger. Note that CIDR had to _succeed_ for this to work. If CIDR fails to contain the information growth, then there is no default-free router to base your proposal on. However, if such a router exists, it could also be used to route IPv4 packets directly. It can, and is, now, yes. So? So if CIDR succeeds, tunnelling is not beneficial. Thus, the problem is still solved and no new hardware development needs to be done. Oh good. Then we're done, we don't need the draft-cidrd-ownership thing, and no-one ever needs to renumber, anytime, ever. I hadn't realised it was going to be that simple. I'm quite willing to do nothing at all, if that will work. I thought the problem was that it won't. You are correct, it will probably not work. Again, recall that CIDR's _continued success_ at containing the explosion of information is not assured. We need to take action to improve the probabilities of success. The draft is one such possible action. Tony, I know you understand exponential growth. I am not sure however that you really understand upper bounds. The point is that the mapping table has an upper bound that is tractable. There is no scaling. I think that we disagree as to what's tractable. Your default-free router has 2^24 routes. The best router available today has something less than 128k (2^17). [Note, I've intentionally picked an overly large number so we don't haggle about this.] I would say that this (a factor of 128) is a good bit of scaling. Ideally we will, via many means, never reach that upper bound, but even if we do, we can still handle the table. Again, with what hardware? And when does it get developed and shipped? Who will make the investment for its development? And who will guarantee the return on investment? I claim that you're simply begging the question. If you believe that there is something in the mapping scheme that can grow too bit to be manageable, please say exactly what it is, how big it will become, and why that can't be handled. At the risk of repeating myself: the forwarding table, 2^24 or bigger, we don't have the technology at the necessary rates and we don't have a good way of getting there. Other stuff: It turns out that NAT is non-trivial because of the embedded addresses. Yes, I think we (most of us) understand that. Certainly doable, but non-trivial. But this is fascinating ... this is doable, which ammounts to remapping source & dest addresses in every packet passing through (ignoring the embedded addresses for now), which must mean looking them up in some kind of giant table - yet the mapping scheme that maps dest addresses only, is somehow impossible. The table is NOT giant. It's actually quite small. It's four addresses per flow through the NAT, which is constrained by the bandwidth of the leaf site. If such a router exists, then in kre's scheme, it is used to tunnel across another fabric (such as CLNP). Yes, though I was proposing we use IPv4, not that that changes the principles. I actually received a very interesting suggestion that IPv6 be used, which has some very attractive advantages. Unfortunately, I'm not sure we're really ready for that quite yet, but a little later it may be the way to go. I suggested that because the requisite implementation for CLNP exists today, complete with high speed forwarding, routing protocols and debugged router implementations. The remaining 6748 SprintLink prefixes are 851 aggregates of various lengths, assorted old classful Bs and many many many many many ancient allocations wherein there is some but not much scope for further aggregation. The mapping scheme allows all of those ancient prefixes to be mapped into a nice aggregatable (as far as routing is concerned) single prefix announcement (allows, doesn't require) which makes this problem go away, and need not even be known about by all of Sean's customers with those ancient numbers. Those 6748 prefixes still exist in your mapping table. Tony From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 19:09:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08344; Sat, 26 Aug 1995 19:09:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA10929; Sat, 26 Aug 1995 19:06:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA10923; Sat, 26 Aug 1995 19:01:58 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08164; Sat, 26 Aug 1995 19:01:54 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzeky09963; Sat, 26 Aug 1995 05:01:51 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Discussing encap/mapping proposal To: kre@munnari.OZ.AU (Robert Elz) Date: Sat, 26 Aug 1995 05:01:51 -0400 (EDT) Cc: tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <12865.809421807@munnari.OZ.AU> from "Robert Elz" at Aug 26, 95 05:23:27 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1300 Precedence: bulk > It turns out that NAT is non-trivial because of the embedded > addresses. > > Yes, I think we (most of us) understand that. > > Certainly doable, but non-trivial. > > But this is fascinating ... this is doable, which ammounts to > remapping source & dest addresses in every packet passing > through (ignoring the embedded addresses for now), which must > mean looking them up in some kind of giant table - yet the > mapping scheme that maps dest addresses only, is somehow > impossible. > > Interesting. I think that we are talking about different orders of magnatude here. On the one hand you have a NAT box which is handling the Internet interface of one organization - with a small number of internal/external adresses to be mapped, and a small amount of traffic going through that box. On the other hand you have a major backbone router that sees traffic going to nearly every part of the internet and all at enourmous rates. The numbers of flows (measured in destinations or source/dest pairs) is much higher in a backbone router than on a NAT box. The table sizes of these mapping tables is also a lot higher on a backbone router than in a NAT box. I just don't see how to scale a NAT-type box to any one of my current backbone routers. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 19:29:50 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08983; Sat, 26 Aug 1995 19:29:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA10981; Sat, 26 Aug 1995 19:26:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA10966; Sat, 26 Aug 1995 19:15:10 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08442; Sat, 26 Aug 1995 19:15:06 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzeky11009; Sat, 26 Aug 1995 05:14:58 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: "Provider-based addresses" is bad terminology To: avg@sprint.net (Vadim Antonov) Date: Sat, 26 Aug 1995 05:14:58 -0400 (EDT) Cc: bsimpson@MorningStar.Com, big-internet@munnari.OZ.AU In-Reply-To: <199508252332.TAA24398@titan.sprintlink.net> from "Vadim Antonov" at Aug 25, 95 07:32:41 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 285 Precedence: bulk > Well, a provider may want to have more than block in the AS, If they do, then so long as they keep this to reasonable levels, thats fine. If every provider in the world today had 20 prefixes, that would still only be on the order of 20K routes. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 19:30:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09008; Sat, 26 Aug 1995 19:30:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA11003; Sat, 26 Aug 1995 19:29:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA10963; Sat, 26 Aug 1995 19:14:02 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08409; Sat, 26 Aug 1995 19:13:55 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzeky10752; Sat, 26 Aug 1995 05:12:34 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: IP Encapsulation Growth Proposal To: dcrocker@brandenburg.com (Dave Crocker) Date: Sat, 26 Aug 1995 05:12:33 -0400 (EDT) Cc: vaf@valinor.barrnet.net, big-internet@munnari.OZ.AU In-Reply-To: from "Dave Crocker" at Aug 25, 95 11:10:26 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 789 Precedence: bulk > I made a request for information about real and hard MTU limits for > "core" routers and would appreciate some response on this. The query is > not for the current limit, per se, but for a description of the underlying > reasons for it or some other number to be a hard limit that can't > reasonably be changed. Ether & FDDI mtus. Serial links can be run at (nearly) any mtu you want (today most slow (T1 or less) links typically run at 1500 and most fast (T3) links run at 4470). The real constraints are the interconnects - which are typically either FDDI or Ether. Get me something better than a FDDI GigaSwitch for my interconnects, and this may change; but for today & the forseeable future, the limits will be (at best) FDDI mtus. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 19:32:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09018; Sat, 26 Aug 1995 19:32:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA11025; Sat, 26 Aug 1995 19:31:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA10947; Sat, 26 Aug 1995 19:09:56 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08347; Sat, 26 Aug 1995 19:09:48 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id CAA11853; Sat, 26 Aug 1995 02:09:02 -0700 Date: Sat, 26 Aug 1995 02:09:02 -0700 From: Tony Li Message-Id: <199508260909.CAA11853@greatdane.cisco.com> To: bsimpson@MorningStar.Com ("William Allen Simpson") Cc: big-internet@munnari.OZ.AU Subject: Cisco can't policy route? Precedence: bulk Bill, I'm not sure if you're serious, joking, or just being argumentative. In any case.. > Approximately. What's actually required is a mapping from > every existing advertised prefix. > > Please note the last clause. Let us suppose that such a router exists > and can switch packets at some non-trivial rate and has sufficient > connectivity that we can actually build a _service_ from them. > Is this an official declaration that you know of no such router that currently exists? Correct. Note that the context of this entire discussion was about futures under kre's proposal. So every existing advertised prefix may well be 2^24 prefixes. I know of no such router. That is, Cisco does not produce a router that can currently "switch" packets based on the RADB for every site prefix in the Internet? cisco routers do not switch packets based on the RADB. They switch packets based on their forwarding table(s). Any resemblence to the RADB is purely accidental. Inserting the RADB into your cisco router is an abuse of the equipment, may damage the hardware, and may void your warranty. ;-) This certainly is at variance from other Cisco advertisements. AND your previous statements to IETF WGs. I don't believe that I've ever said anything about switching based on the RADB. It is most important that we understand this before proceeding further. Is the Internet already broken? Are we too late? It is my belief that the Internet has been broken for a very long time now. But that's the nature of the world's largest distributed system. Something's always busted. ;-) As to your subject line, policy routing is an 11.0 feature and hasn't shipped yet. Tony From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 21:21:45 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11772; Sat, 26 Aug 1995 21:21:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26256 Sat, 26 Aug 1995 21:12:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA11163; Sat, 26 Aug 1995 21:06:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA11156; Sat, 26 Aug 1995 21:05:31 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11489; Sat, 26 Aug 1995 21:05:26 +1000 (from kre@munnari.OZ.AU) To: asp@uunet.uu.net (Andrew Partan) Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Sat, 26 Aug 1995 05:01:51 -0400." Date: Sat, 26 Aug 1995 20:59:53 +1000 Message-Id: <12907.809434793@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sat, 26 Aug 1995 05:01:51 -0400 (EDT) From: asp@uunet.uu.net (Andrew Partan) Message-ID: I think that we are talking about different orders of magnatude here. We don't have to be. On the one hand you have a NAT box which is handling the Internet interface of one organization - with a small number of internal/external adresses to be mapped, and a small amount of traffic going through that box. Then put the encapsulating/mapping boxes in the same places, with the same constraints. The small number of addresses is perhaps small at any one instant, over time however every internet address is a potential candidate. This is just the same with both techniques. On the other hand you have a major backbone router that sees traffic going to nearly every part of the internet and all at enourmous rates. Perhaps it hasn't been clear - only the entry points to the backbone need do any of this stuff, the transit routers sitting inside the backbone just route the way they do today, except seeing only the (highly aggregable) internal addresses. We can define the points where the mapping is done to be wherever it makes most sense, putting it at the entry points to the default free zone probably minimises the number of routers and organisations that need to manage this system (and gives the benefits where they are really needed), putting it further out towards the end users lowers the load costs on the routers doing the work. Like many things there is a trade off here - and here, one that each provider can make for themselves (there will be no rules, or not more than that some router on the path from the core to any end user can handle the encapsulation/decapsulation techniques). kre From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 21:21:50 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11778; Sat, 26 Aug 1995 21:21:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26284 Sat, 26 Aug 1995 21:14:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA11183; Sat, 26 Aug 1995 21:09:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA11140; Sat, 26 Aug 1995 20:54:35 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11364; Sat, 26 Aug 1995 20:54:08 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Sat, 26 Aug 1995 01:45:54 MST." <199508260845.BAA11089@greatdane.cisco.com> Date: Sat, 26 Aug 1995 20:48:54 +1000 Message-Id: <12902.809434134@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sat, 26 Aug 1995 01:45:54 -0700 From: Tony Li Message-ID: <199508260845.BAA11089@greatdane.cisco.com> Note that the key scaling problems with these routers is the growth in the number of advertised prefixes. Yes, but it is not the absolute number as such that is the problem (in the latter days of IPv4) but the volume of data that each prefix currently requires. So the fact that such routers exist today is NOT sufficient to conclude that those same routers will suffice in the future. No, I assume that they will not. If they were to exist, we would just do nothing at all, and there would be no problem. Note that CIDR had to _succeed_ for this to work. No, CIDR has to continue to succeed long enough to get this deployed. Once deployed, CIDR will be used for the internal routing, there the operators of these boxes can make it succeed, so that should not be a problem. But we can then forget CIDR if we want as far as it applies to end users address allocations (other than its role in giving out blocks of suitable sizes). If CIDR fails to contain the information growth, then there is no default-free router to base your proposal on. I don't need a default free router - I simply assume they currently exist. The aim of this proposal is to (essentially) make all routers use default routes, if, with you like, the default route pointed at a logical interface that encapsulates the packet with the "internal" address as destination, and runs the routing algorithm again. However, if such a router exists, it could also be used to route IPv4 packets directly. It can, and is, now, yes. So? So if CIDR succeeds, tunnelling is not beneficial. No, we require renumbering to make CIDR succeed, this proposal will not require that. Again, recall that CIDR's _continued success_ at containing the explosion of information is not assured. Exactly, which is one reason for pursuing this scheme, even if avoiding mandatory renumbering were not a sufficient reason, that is, to act as a backup in case CIDR fails (doesn't succeed well enough). We need to take action to improve the probabilities of success. And/Or to make provision in case of failure. It has been argued that now is too late to start on this, it should have been done years ago - what is certainly true is that 3 years from now will be too late to startif we suddenty decide that the hopes of CIDR forced renumbering aren't good enough. The draft is one such possible action. Yes, possible, but unfortunately not one that a lot of people (providers excepted) seem to consider acceptable. I think that we disagree as to what's tractable. Perhaps. Your default-free router has 2^24 routes. No, not routes, mapping table entries. And certainly less than that, as even with no renumbering, etc, CIDR aggregations (as in allocating a /22 to a site, or whatever) would reduce that considerably. And finally, your address space consumption work has shown that we don't reach that number until 2010 or later, assuming exponential growth doubling every 9 months (lets assume 12 for this paragraph though, its easier for me, and kinder to your side of this argument). That combination means that in 2009 the max is 2^23, in 2008 the max is 2^22, in 2007 the max is 2^21, ... in 2003 2^17 if I counted (on my fingers) correctly. By 2003 we should start having IPv6 deployed in reasonable quantities (but don't let Jim Bound hear us say that, because he thinks it will be years earlier than that). And yes, I know that if I continued back with that extrapolation we'd only have 2^9 routes now, and we know we have a few more than that, so something is wrong (and its not the 12 month doubling, 9 months would make it considerably more inaccurate). Still the general point holds, it is very likely that this will all be obsolete long before we approach 2^24. However calculating using 2^24 does lend some assurance that we can handle the worst case. I am yet to see any worst case calculations for the draft's method. The best router available today has something less than 128k (2^17). Tony, you're comparing apples & oranges. Mapping table entries can be implemented to require 4 bytes each. I doubt that even you can squeeze routing table entries into that little space. Again, with what hardware? With whatever is available 5 years from now. And when does it get developed and shipped? Anytime in the next 5 years. Who will make the investment for its development? Any company that proposes to remain in business. If current growth patterns are anything to go by, in 5 years it will be close to impossible to build routers without memory sizes of the magnitudes required. Mem availability and prices are driven by the PC market (the big user) - in 5 years those people are going to be demanding memory quantities that are hard to conceive of now, all the newer applications are demanding it. Have you tried to buy 128Kb or 256Kb SIMMs recently? They're not exactly easy to get - yet 5 years ago building using those would have been mundane (the safe thing to do). These days about 4Mb SIMMS (or bigger) are all it makes sense to plan to use, even 1Mb SIMMS are becoming harder to find. Don't 7000's use 16Mb SIMMs now? In 5 years you'll be using 64Mb SIMMS, or 256Mb SIMMS as matter of course. Maybe even 1Gb SIMMs. Finding 64Mb for this mapping table will not be a problem. And who will guarantee the return on investment? Anyone who hopes to remain in business. You can't keep building products out of parts that are no longer manufactured, and if you're silly enough to think that the mem part manufacturers will keep low volume (cheap) parts in ready supply just for routers, then I suggest that you go talk to your chip purchasing agents. At the risk of repeating myself: the forwarding table, 2^24 or bigger, Or bigger?? Again, its the mapping table, sticking that in the forwarding table probably makes sense as long as it remains (comparatively) small, when it gets big it deserves a data struct of its own. we don't have the technology at the necessary rates and we don't have a good way of getting there. We do, as the technology for this is trivial. It is even assured that for IPv4 you won't need to grow any more (for routing reasons), nothing in the cidrd ownership draft gives you any guarantee that way until you start mentioning very big numbers indeed (ie: 2^24 but multiplied by about another 2^8 bytes/entry, and then more for the number of paths, if I have understood what I have read). My 2^24 multiplies by just 4. (Note: I don't say that full flat routing of 2^24 entries will be impossible in 2003 or something, it may well be, I just wouldn't like to depend on that one). The table is NOT giant. It's actually quite small. It's four addresses per flow through the NAT, Huh? Where does the box get the addresses from in the first place? When a new flow starts, the mapping must come from somewhere. which is constrained by the bandwidth of theleaf site. Yes, recall that my encapsulating boxes go only at places where default route routers connect (leaf sites if you like - you can make it that way), so it would seem we have exactly the same situation .. bandwidth & number of flows constrained, and an address mapping that has to be obtained from somewhere. Wherever you get yours from, I can get mine from too. I suggested that because the requisite implementation for CLNP exists today, complete with high speed forwarding, routing protocols and debugged router implementations. That's fine. I wasn't sure that the entire IP core had CLNP capable routers deployed. I know it has IPv4 capable routers deployed however, and as IPv4 addresses are smaller than NSAPs, making the mapping table smaller (with NSAPs it would likely be a 320Mb table, rather than 64Mb, that might be a bit much to ask). Those 6748 prefixes still exist in your mapping table. Yes, they might consume as little as 26992 bytes of mapping table memory, if the rest of the mapping table is big enough to make that implementation technique make sense. Perhaps 134960 bytes if we have to start building lists, or something, because the overall table isn't huge. How much memory do they consume today? (Consider in a router with 4 or 5 paths to SprintLink) How much will they consume if BGP gives way to IDRP (or whichever that new one is?) kre From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 21:47:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12502; Sat, 26 Aug 1995 21:47:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA11246; Sat, 26 Aug 1995 21:46:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA11228; Sat, 26 Aug 1995 21:27:21 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11929; Sat, 26 Aug 1995 21:27:10 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id EAA21017; Sat, 26 Aug 1995 04:26:45 -0700 Date: Sat, 26 Aug 1995 04:26:45 -0700 From: Tony Li Message-Id: <199508261126.EAA21017@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: <12902.809434134@munnari.OZ.AU> (message from Robert Elz on Sat, 26 Aug 1995 20:48:54 +1000) Subject: Re: Discussing encap/mapping proposal Precedence: bulk No, CIDR has to continue to succeed long enough to get this deployed. Ah... and we have to limp along using CIDR and traditional routers until then. I'm catching on slowly. Ok, so when do you plan to deliver? I hope you realize that unless it's EXTREMELY soon, we need to take some action to insure that there's something left for you to save. No, we require renumbering to make CIDR succeed, this proposal will not require that. And you need to ALSO be making some proposal on how to continue CIDR until your boxes are ready to deploy. By 2003 we should start having IPv6 deployed in reasonable quantities (but don't let Jim Bound hear us say that, because he thinks it will be years earlier than that). Agreed. ;-) Mapping table entries can be implemented to require 4 bytes each. I doubt that even you can squeeze routing table entries into that little space. You might be surprised. Who will make the investment for its development? Any company that proposes to remain in business. Excuse me, but not all companies are router companies. Really. ;-) Further, many router companies could simply ignore the ENTIRE Internet quite happily. The money seems to be in the IBM market... And who will guarantee the return on investment? Anyone who hopes to remain in business. Again, there is one limited market for these research boxes. They serve no other purpose and they are obsolete the day IPv6 is deployed in volume (assuming it is). An incredible risk for customers who have not stepped up to say that they will buy. we don't have the technology at the necessary rates and we don't have a good way of getting there. We do, as the technology for this is trivial. I would like an example, please. Show me this box forwarding at wire speed T3, please. The table is NOT giant. It's actually quite small. It's four addresses per flow through the NAT, Huh? Where does the box get the addresses from in the first place? When a new flow starts, the mapping must come from somewhere. Which address? The NAT sees two address spaces, the global Internet's and the users. It does NOT need to map all of each simultaneously. When it sees a DNS request from either side, it allocates an address from its pool of dynamically assigned addresses for the requesting side, and maps that to the real address on the other side. Yes, recall that my encapsulating boxes go only at places where default route routers connect (leaf sites if you like - you can make it that way), so it would seem we have exactly the same situation Ah. I missed that we were replacing the entire Internet. That's fine. I wasn't sure that the entire IP core had CLNP capable routers deployed. I know it has IPv4 capable routers deployed however, and as IPv4 addresses are smaller than NSAPs, making the mapping table smaller (with NSAPs it would likely be a 320Mb table, rather than 64Mb, that might be a bit much to ask). One might even algorthmically embed your AS# token in your NSAP. No significant extra space required. Tony From owner-Big-Internet@munnari.OZ.AU Sat Aug 26 21:48:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12533; Sat, 26 Aug 1995 21:48:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA11270; Sat, 26 Aug 1995 21:48:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA11231; Sat, 26 Aug 1995 21:31:54 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12032; Sat, 26 Aug 1995 21:31:51 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Fri, 25 Aug 1995 09:02:49 -0400." <9508251302.AA11767@ginger.lcs.mit.edu> Date: Sat, 26 Aug 1995 21:31:29 +1000 Message-Id: <12919.809436689@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Fri, 25 Aug 95 09:02:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9508251302.AA11767@ginger.lcs.mit.edu> or an absolute "do-or-die" project by a small numebr of vendors outside the IETF process (like SGMP) which is where you get one year. That is bascically what we have here? How many vendors do we have of backbone type routers? This scheme affects no-one but those vendors and the providers. Yakov and I talked about this last night, Great (two of the people who don't believe its worthwhile...) whether to make the output of the translation table be an exit router, or the address of the destination aggregate, in a new topologically-oriented namspace. The latter is what I have always assumed. It seems likely to work much better. However I am open to be convinced otherwise. In either case, it is important that it be a *new* namespace, whether it is one name per exit router, or one name per aggregate. If you go the "exit router" path, As I wasn't really planning on doing that, I won't worry too much about its problems just yet. For instance, suppose two different exit routers lead to the destination. How do you decide which one to pick? How do you decide which to pick when you have two exit routers leading to a CIDR aggregated block? I do it exactly the same way, using a different bit string. How about the case in which there are two exit routers, and one is down? How do you find that out? How do you do it when the route is to an aggregated CIDR block. I do it exactly the same way, using a different bit string. If you use something like ICMP, what's to stop denial-of-service attacks? Etc, etc, etc. And what's to stop that when you use aggregated CIDR blocks as routes? I stop it exactly the same way, using a different bit string. Listen again, these two routing schemes are *identical*. I'm not sure I believe that. It certainly has to be managed in a distributed fashion; Does it? Why? i.e. there's no way we can do it with one giant table which everyone FTP's out every day. Why not? It is certainly not an ideal method, but nor is it impossible. If you think otherwise; I have the *perfect* counterexample for you: the hostnames.txt file. Then I have a good counter-counter-example - the com.au zone file. (or any of the other root zone files). This is a more reasonable analogy, as it needs to be distributed to just a small handful of organisations, as does our mapping table - not every end user host as did hostnames.txt (though my recollection was it had a slightly different name than that - who cares). Last I heard the root servers still shipped around the zone files using FTP, not the DNS zone transfer mechanisms, though that may have altered now. Those files contain lots more than 100K entries, they need to be roughly consistent, but not perfectly - basically just the same as the encaps mapping table. Of course, we could always keep the old-portable-addresses to new-topological-addresses in the DNS, and cache them in the routers for better performance... :-) Hmm... that was actually the way the original IPencaps proposal siuggested it be done. I don't really think that way is reasonable (DNS depends on routing working). I wait with bated breath to hear how the people who didn't like EID's "because the mapping would be too expensive" EIDs were end user used identifiers, which is a different scale (not that I ever believed that argument of course). Oh, so I assume you oppose IPv6 because it assumes perennial renumbering No, we make it work there. IPv6 is not yet deployed anywhere, that makes it amenable to being distributed in a form that will work. The IPv4 that we have to make this work on is already on my desk, nothing shipped after today is early enough. (Perhaps I should say, nothing shipped after last weekend is early enough, wouldn't want to confuse anyone with that silly product launch). Well, I'm glad you think so; some opponents of CIDR don't feel that way. I don't think anyone has suggested prohibiting renumbering. kre From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 02:07:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21403; Sun, 27 Aug 1995 02:07:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA11745; Sun, 27 Aug 1995 02:06:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA11739; Sun, 27 Aug 1995 02:04:52 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21358; Sun, 27 Aug 1995 02:04:50 +1000 (from bsimpson@morningstar.com) Received: from merit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03113 Sun, 27 Aug 1995 02:04:47 +1000 (from bsimpson@morningstar.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-05.dialip.mich.net [141.211.7.141]) by merit.edu (8.6.12/merit-2.0) with SMTP id MAA08653 for ; Sat, 26 Aug 1995 12:03:27 -0400 Date: Sat, 26 Aug 95 15:23:20 GMT From: "William Allen Simpson" Message-Id: <4544.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: Re: Administrivia. Precedence: bulk > One thing that is out of order here is meta discussions about > whether other discussions should be carried on here or not. > Those discussions are definitely not related to the growth > or size of the internet. > Thank you. I had just decided to ignore him. As to the rest of your proposal, it is eminently sensible, and supported with good arguments. Now, it is time to stop arguing, and write the details down. I will just stop replying to B-I arguments until we have a firm draft in hand. Particularly since Tony Li declares the Internet is already broken, and _admits_ that Cisco can't handle the simple PRDB mapping we already have agreed upon (which requires a router/server to lookup the net->AS mapping, essentially what you also need, at exactly the same scale). So, it's time to do something. If you need help, just let me know. Back to coding IP Security.... This flood of email really takes a lot of time! Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 06:47:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00370; Sun, 27 Aug 1995 06:47:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA12002; Sun, 27 Aug 1995 06:46:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA11996; Sun, 27 Aug 1995 06:44:37 +1000 Received: from foobar.Ipsilon.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00334; Sun, 27 Aug 1995 06:44:35 +1000 (from minshall@servo.ipsilon.com) Received: from localhost.ipsilon.com (localhost.ipsilon.com [127.0.0.1]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id NAA05965 for ; Sat, 26 Aug 1995 13:44:00 -0700 Message-Id: <199508262044.NAA05965@servo.ipsilon.com> X-Authentication-Warning: servo.ipsilon.com: Host localhost.ipsilon.com didn't use HELO protocol X-Mailer: exmh version 1.6beta 3/23/95 To: big-internet@munnari.OZ.AU Subject: 1. core; 2. conformance In-Reply-To: Your message of "Fri, 25 Aug 1995 22:07:32 PDT." <199508260507.WAA25654@greatdane.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Aug 1995 13:44:00 -0700 From: Greg Minshall Precedence: bulk Tony, et al, Two things, one driven by Tony Li's message: > Bill, the exchange of routes via BGP is not the foremost problem > anymore. It is maintaining the advertised prefixes at the switching > engine and accessing them at line rate. 1. If there *were* a core of the internet, it would be very hot from switching all those packets. It would have a "border" that wouldn't be quite as hot as "farther in" to the core. So, one might be tempted to spend some cycles on the border (heating that part up) to try to reduce the heat in the core. In kre's proposal, by mapping the /24 addresses (looks like a DOS command-line option, for heaven's sake!) into /16 addresses, or something else more tractable for routing (both as in "routing protocols/database" and "forwarding") within the core itself. If. 2. It occurs to me, just back from a clearly ill-timed three day vacation, that in some sense, the difference between provider-based addressing and metro addressing (both, i believe, examples of aggregator-based addressing) is that provider-based addressing says "we, today, have *no* clue how the *topology* is going to evolve, based as it is on the anarchy of a free-market economy" (or some such), "so, we will deploy measures that allow us to constrain/permute the *addressing* to conform to the evolving topology." Metro addressing, on the other hand, says "we would like to put some constraints on the *topology*, and how it will evolve, such that it will continue to, in the main, conform to the *addressing*; we will thus gaze into our crystal ball and determine some set of constraints that will accomplish our goal." In other words, either addressing determines topology, or topology determines addressing. "Who's on top?" Greg From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 12:27:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10663; Sun, 27 Aug 1995 12:27:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA12299; Sun, 27 Aug 1995 12:26:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA12271; Sun, 27 Aug 1995 12:07:14 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09962; Sun, 27 Aug 1995 12:07:09 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzeno23012; Sat, 26 Aug 1995 22:07:04 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: ownership, leasing, renumbering, and that draft To: kre@munnari.OZ.AU (Robert Elz) Date: Sat, 26 Aug 1995 22:07:04 -0400 (EDT) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <12919.809436689@munnari.OZ.AU> from "Robert Elz" at Aug 26, 95 09:31:29 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 824 Precedence: bulk > That is bascically what we have here? How many vendors do we > have of backbone type routers? This scheme affects no-one but > those vendors and the providers. Wait a minute - you just said that the best place to deploy this is not in the backbone boxes but rather in the access boxes (the routers where the customers connect to the Internet). If 'all' we had to change was backbone boxes, that might be a tractible problem - all major ISPs are used to deploying new code very frequently (daily/weekly/monthly) and new hardware every 1-2 years. But if we suddenly have to change all of my customers' access boxes, thats a lot harder - there are a lot more of them from a lot more vendors, and my customers typically do not change anything on their box after they 1st install it. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 15:47:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16864; Sun, 27 Aug 1995 15:47:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA12601; Sun, 27 Aug 1995 15:46:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA12588; Sun, 27 Aug 1995 15:43:45 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16636; Sun, 27 Aug 1995 15:43:39 +1000 (from kre@munnari.OZ.AU) To: asp@uunet.uu.net (Andrew Partan) Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Sat, 26 Aug 1995 22:07:04 -0400." Date: Sun, 27 Aug 1995 15:43:17 +1000 Message-Id: <13012.809502197@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sat, 26 Aug 1995 22:07:04 -0400 (EDT) From: asp@uunet.uu.net (Andrew Partan) Message-ID: Wait a minute - you just said that the best place to deploy this is not in the backbone boxes but rather in the access boxes (the routers where the customers connect to the Internet). No, I said nothing about "best", you get to choose where to do this, depending upon your requirements. Perhaps the reply I am about to send to Tony (ie: composed, but not yet dispatched) will make some of this clearer. If 'all' we had to change was backbone boxes, that might be a tractible problem - all major ISPs are used to deploying new code very frequently (daily/weekly/monthly) and new hardware every 1-2 years. That's interesting, that's even more frequent than I had thought (the relevance will become clear in the other message). But if we suddenly have to change all of my customers' access boxes, Oh, no no, that was never the plan, we must have read the "install NAT boxes" suggestion differently. I read that as suggesting that you (ie: the providers) install NAT boxes (or more accurately, install NAT code in the routers) at the point(s) where your customers connect to you - no change in your customer's view of the world, they do nothing, you do the translations. (No comment about whether this could work, I myself see only a limited future for NAT, but that was how I saw the suggestion). thats a lot harder - there are a lot more of them from a lot more vendors, Yes, I understand that, the aim of my proposal is to insulate the end users from changes (end users == customers, closely enough, here, for this purpose it doesn't matter if your customer is atually a small time IP reseller, an individual with a PC, or a major organisation either with open access, or a firewall, in no cases do I want them to have to go about changing things). and my customers typically do not change anything on their box after they 1st install it. Yes, I know -- they should be able to just make use of the internet, most of them don't want to know how it works. Including not wanting to have to deal with changing numbers (more than to allocate them when they first connect, somewhere). kre From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 16:07:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17684; Sun, 27 Aug 1995 16:07:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA12642; Sun, 27 Aug 1995 16:06:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA12614; Sun, 27 Aug 1995 15:47:50 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB16872; Sun, 27 Aug 1995 15:47:48 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA03062; Sat, 26 Aug 1995 22:47:40 -0700 Date: Sat, 26 Aug 1995 22:47:40 -0700 From: Tony Li Message-Id: <199508270547.WAA03062@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Cc: bsimpson@morningstar.com ("William Allen Simpson") Subject: Re: Administrivia. Precedence: bulk Particularly since Tony Li declares the Internet is already broken, and _admits_ that Cisco can't handle the simple PRDB mapping we already have agreed upon (which requires a router/server to lookup the net->AS mapping, essentially what you also need, at exactly the same scale). Excuse me, I wasn't aware the we had decided that kre's mapping table scheme was now known as the PRDB. As you may know, there's another very common usage of that particular acronym which has entirely different semantics. Please pardon my confusion. It is also true that cisco routers today cannot support kre's full mapping table of 2^24 entries at wire rate. It is also true that today's software image cannot support kre's scheme at all. I'd also like to point out that if you accept my humorous metric for "broken": "But that's the nature of the world's largest distributed system. Something's always busted. ;-)" Then nothing that kre has proposed will "fix" the net. Except, perhaps, intentionally turning it off. Tony From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 16:08:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17705; Sun, 27 Aug 1995 16:08:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA12666; Sun, 27 Aug 1995 16:08:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA12627; Sun, 27 Aug 1995 15:51:40 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB16950; Sun, 27 Aug 1995 15:51:38 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Sat, 26 Aug 1995 04:26:45 MST." <199508261126.EAA21017@greatdane.cisco.com> Date: Sun, 27 Aug 1995 15:51:17 +1000 Message-Id: <13017.809502677@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sat, 26 Aug 1995 04:26:45 -0700 From: Tony Li Message-ID: <199508261126.EAA21017@greatdane.cisco.com> and we have to limp along using CIDR and traditional routers until then. Yes, exactly as we have to do if we don't even start this approach, but possibly a little less heavy handed. Ok, so when do you plan to deliver? I am hoping for a year. I hope you realize that unless it's EXTREMELY soon, we need to take some action to insure that there's something left for you to save. Yes, I am anticipating continued efforts to convince people to renumber, where they can, so we get better aggregation. I expect that the chances of that will be greater if we can simultaneously promise people that having done that once they will probably never have to again, than if we're having to tell people the chances are they may have to renumber several times over the next few years as connectivity changes. I would prefer we not take any action (yet at least) that forces renumbering - both because I think that is a revolting thing to do to anyone, however long you give them to do it, and because it sends the message that they have no overall control over their internet connectivity, which will tend to cause them to resist, rather than co-operate. Again, there is one limited market for these research boxes. No, you don't understand, all routers, for any market, will be big enough to cope with the mapping scheme, simply because there will remain no economic way left to build them so that they are so small they cannot cope. That is, ignoring absurdities like sticking in big simms, but not bothering to connect all the address lines to the processors' address busses. They serve no other purpose and they are obsolete the day IPv6 is deployed in volume (assuming it is). We better be assuming something is, whether it is the current IPv6 or something else, as there is no way IPv4 can last forever, whatever we do with it. But on the real point, no, only if you were to design the hardware in a way that is very specific to IPv4 routing. Since you already route lots of other protocols, I kind of doubt that. We know routers are going to get bigger anyway, all I am saying is that the naturally bigger routers will be big enough to handle the mapping scheme, with no special designs required. Of course, if you see some advantage in doing some hardware that is specific to one purpose, that's a choice you can make. Further, this might be reasonable, perhaps there are enough customers who would like a router that can route IP blindingly fast now (for example) that they woudl buy this, even knowing that some of that hardware may sit idle once IPv4 is no longer being routed (as in, the box still routes other stuff, but leaves some ram, or processors, doing nothing useful). Beats me if this is a sound strategy or nor. And finally of course, router lifetime (before they need to be swapped to other newer models), especially around the core of the net isn't all that long (a few years max), having some hardware that would be over powered for a year or two until it is time to replace it with the (then) latest model isn't likely to worry too many people, as long as it did the job when it was needed. I would like an example, please. Show me this box forwarding at wire speed T3, please. You know I can't do that, I don't have the technology to make it happen. However, you ship me your source code, and I will make the mods, and we will see how well a 7000 (or 4500 or whatever) can do will we? Which address? The NAT sees two address spaces, the global Internet's and the users. It does NOT need to map all of each simultaneously. When it sees a DNS request from either side, it allocates an address from its pool of dynamically assigned addresses for the requesting side, and maps that to the real address on the other side. Oh, sure. And I suppose you're adding stable storage so all this persists past router reboots, etc. I can just see this great market for routers with discs... (Or are you proposing many Mb's of flash ram to store all these mappings). Recall that once mapped, you have no way to tell how long the clients, on either side, will remember the mappings. One place IP addresses appear is in Received headers, I keep my mail years, I might want to send a message to user@[stored.ip.addr.ess] from months ago... (Ok, a little far fetched that I would actually expect it to work, but these things happen). And again, if you can somehow make this work, whatever technique you use I can use for my mappings as well, except the users never get to see the mapped addresses, and so it is easier for me to alter them at will (to make aggregation more effective or whatever). Ah. I missed that we were replacing the entire Internet. No, we are changing some number of routers in providers. They get to decide which to change - which will depend on what is available from you guys. If you make available something not too expensive, but that is limited in forwarding rates, they will use those things at the edges. If you make available something much more expensive, and much faster, they'll buy less, and stick them closer to the core of the net. There is no one requirement here, lots of options. One might even algorthmically embed your AS# token in your NSAP. No significant extra space required. Yes, we could do something like that. I have been avoiding using AS# though for several reasons, one is that they currently are allocated randomly, and to be topologically signifcant would all need to alter - which should be no big problem of itself, other than that someone would need to work out what to do with all those AS numbers that have been allocated, but which aren't actually used in the Internet anywhere (beats me why anyone bothers with an allocated AS# for most of those purposes, but they do, so...) More relevantly, for right now anyway, the current AS# space is just 16 bits, and while I would prefer a 16 bit mapping than 32 bits (uses just 1/2 the memory, so you get to object less...) it isn't possible then to demonstrate an equivalence between the mapped numbers and CIDR prefixes in the most general case (ie: widespread flat routing). That would allow Yakov and Noel to dream up some weird cases where CIDR (really flat routing) can handle, and the mapping scheme can't. Once we get past that stage, we can then look and see if a 2^16 routing space is enough for the core, and if so, go for it (which, for Yakov and Noel, is exactly equivalent to no more than 2^16 CIDR prefixes, and does not assume that only /16's are advertised). My feeling is that this is probably enough, but this is a detail, and we can worry about that later. Given mappings just 16 bits long, we would certainly need to embed them in something, that could be in an IPv4 addr, with a constant top 16 bits (reserve a /16 instead of a /8 for this purpose), or it could be CLNP (or IPv6) with a constant prefix to separate these addrs from the other CLNP (or IPv6) addresses, then this 16 bit number, and then, perhaps, the actual IPv4 address appended, which would allow more precise routing as the packets approach the destination. (Those CLNP/IPv6 approaches would apply with 32 bit mappings as well of course). Again, this is getting into choices of details, and isn't important to the overall scheme, whatever way is chosen here the mapping from IPv4 address to still needs to be made. You seem to feel this isn't possible, I disagree, I don't know any way we can prove this one way or the other (as "possible" here clearly doesn't mean theoreticaly possible, but practically possible within other constraints) without actually trying it. kre From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 16:47:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18888; Sun, 27 Aug 1995 16:47:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA12724; Sun, 27 Aug 1995 16:46:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA12720; Sun, 27 Aug 1995 16:40:56 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18773; Sun, 27 Aug 1995 16:40:31 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA05317; Sat, 26 Aug 1995 23:40:28 -0700 Date: Sat, 26 Aug 1995 23:40:28 -0700 From: Tony Li Message-Id: <199508270640.XAA05317@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: <13017.809502677@munnari.OZ.AU> (message from Robert Elz on Sun, 27 Aug 1995 15:51:17 +1000) Subject: Re: Discussing encap/mapping proposal Precedence: bulk Robert, and we have to limp along using CIDR and traditional routers until then. Yes, exactly as we have to do if we don't even start this approach, but possibly a little less heavy handed. Ok, so when do you plan to deliver? I am hoping for a year. Frankly, I don't see how we can deviate from our current path, even if we got instant consensus on your plan, just in case it isn't delivered on time. I hope you realize that unless it's EXTREMELY soon, we need to take some action to insure that there's something left for you to save. Yes, I am anticipating continued efforts to convince people to renumber, where they can, so we get better aggregation. I expect that the chances of that will be greater if we can simultaneously promise people that having done that once they will probably never have to again, There's a song in some corner of my mind that goes: "Don't make promises that your body can't keep." ;-) than if we're having to tell people the chances are they may have to renumber several times over the next few years as connectivity changes. Interesting. Assuming a site isn't bouncing around amongst providers (and I have little reason to think that one would _want_ to), what other causes of renumbering do you see? I would prefer we not take any action (yet at least) that forces renumbering - both because I think that is a revolting thing to do to anyone, however long you give them to do it, and because it sends the message that they have no overall control over their internet connectivity, And we dare not tell them the truth? You DO realize that this is a distributed system, don't you? No _one_ has control. Again, there is one limited market for these research boxes. No, you don't understand, all routers, for any market, will be big enough to cope with the mapping scheme, simply because there will remain no economic way left to build them so that they are so small they cannot cope. Sorry, I can't parse this. I think you're saying that the only routers that could ever get sold are one's that support your scheme. I should point out that there are a VERY significant number of IP routers out there that not connected to the Internet. A company could EASILY decide to pass up the Internet router market during this interim period and jump straight to IPv6. Or only sell interior routers. But on the real point, no, only if you were to design the hardware in a way that is very specific to IPv4 routing. Since you already route lots of other protocols, I kind of doubt that. We know routers are going to get bigger anyway, all I am saying is that the naturally bigger routers will be big enough to handle the mapping scheme, with no special designs required. You'll pardon me if I simply disagree. You know I can't do that, I don't have the technology to make it happen. However, you ship me your source code, and I will make the mods, and we will see how well a 7000 (or 4500 or whatever) can do will we? Please send me your resume. No ;-). And I suppose you're adding stable storage so all this persists past router reboots, etc. I never said that I was building a NAT.... I can just see this great market for routers with discs... Given current disk technology, it's no longer out of the question. Consider a couple of PCMCIA cards in a router... Recall that once mapped, you have no way to tell how long the clients, on either side, will remember the mappings. Au contraire. By carefully controlling the DNS TTL and watching active flows, we have a really good idea of how long it's alive. One place IP addresses appear is in Received headers, I keep my mail years, I might want to send a message to user@[stored.ip.addr.ess] from months ago... (Ok, a little far fetched that I would actually expect it to work, but these things happen). Agreed. And the proper way to do a NAT is to translate those as well. Admittedly, the stored address isn't going to remain bound. And again, if you can somehow make this work, whatever technique you use I can use for my mappings as well, except the users never get to see the mapped addresses, and so it is easier for me to alter them at will (to make aggregation more effective or whatever). So you're proposing that your prefix mapping table be dynamically assigned? Sorry, I don't see how this works. No, we are changing some number of routers in providers. They get to decide which to change - which will depend on what is available from you guys. Please do NOT make the rash assumption that cisco will buy into this scheme. I do NOT understand cisco strategic thinking. I just profit from it. Also, please note that I don't speak for cisco. They might go for it. Depends on how big your check is. If you make available something not too expensive, but that is limited in forwarding rates, they will use those things at the edges. If you make available something much more expensive, and much faster, they'll buy less, and stick them closer to the core of the net. There is no one requirement here, lots of options. And it's not clear that the tradeoff makes sense. If it's used at the leaves, then there are lots more of them. I don't think it's 50-50 here. You seem to feel this isn't possible, I disagree, I don't know any way we can prove this one way or the other (as "possible" here clearly doesn't mean theoreticaly possible, but practically possible within other constraints) without actually trying it. That's correct. My feelings are based on my implementation experience. Even if all of the nits get worked out, everyone buys off and gets cranking, I think that things are still farther off than you suspect. I suspect that we still have to push on CIDR very hard. And if we push hard enough to keep the net running long enough for your scheme to be deployed, we'll also have the technology just to run with CIDR. I too am in the situation where I cannot prove this without actually trying it. Tony From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 17:07:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19546; Sun, 27 Aug 1995 17:07:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA12764; Sun, 27 Aug 1995 17:06:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA12740; Sun, 27 Aug 1995 16:48:01 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18905; Sun, 27 Aug 1995 16:47:56 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA07727; Sun, 27 Aug 95 02:07:43 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA05159; Sun, 27 Aug 95 01:47:52 CDT Date: Sun, 27 Aug 95 01:47:52 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9508270647.AA05159@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal Precedence: bulk I think one thing that gets lost in these discussions is that big router software looks very very little like host software. Forwarding packets at any reasonable rate simply cannot be done withouy doing some fairly hairy dancing, and some hardware assist. So you're not going to be able to solve whatever the global internet's problems are by hacking on a BSD-ish stack and stuffing some SIMMs in somewhere. We're talking 1 or more levels of lookaside caches, custom silicon or FPGA loads, highly optimised packet forwarding paths of several different flavors in the same box, lots of complex stuff. Any of these easy solutions just involving a table and a few lines of code or whatever it is, -- in the forwarding path -- is going to require a substantial development effort, X millions of dollars to get it to market, and if the total market for such work is going to be a few hundred boxes, the core routers, nobody is gonna do it. I may be wrong, and I have great confidence that Tony will straighten me right out if I am, but I think the only reason CIDR got done was because the software was practically doing it anyways, and the bulk of the work was in the routing protocols, which are implemented like host software, not on the forwarding path. Any other solutions are going to have to be similarly cheap, or be rolled in with some serious added value that itself has a reasonably sized market. Or, get someone a great big grant. This is not to suggest that any of the ideas I've seen kicked around are necessarily bad, but please, try to figure out why it's of benefit to the corporate and government accounts that are going to buy a truckload of boxes for their internal net. Andrew From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 17:08:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19556; Sun, 27 Aug 1995 17:08:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA12788; Sun, 27 Aug 1995 17:08:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA12760; Sun, 27 Aug 1995 16:56:39 +1000 Received: from sdg.dra.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19193; Sun, 27 Aug 1995 16:56:13 +1000 (from SEAN@SDG.DRA.COM) Date: Sun, 27 Aug 1995 1:54:56 -0500 (CDT) From: Sean Donelan To: big-internet@munnari.OZ.AU Message-Id: <950827015456.cf5@SDG.DRA.COM> Subject: Re: IP Encapsulation Growth Proposal Precedence: bulk At 7:36 PM 8/24/95, Scott Bradner wrote: >but not many sites. I would actually be kind of surprised if there were >all that many, I don't think that many sites get multi-homed on their >telephone service, some big ones do, but I don't think many small or medium >sized one do. If you could only call certain other telephones depending on which telephone provider you had, they I suspect you would see a lot more sites with multiple telephone providers. For those that remember their telephone history, this was exactly the case in the early part of this century. The net has already started to balkanized. It used to be balkanized based on "AUP." Now its balkanized on router overloads. We already see a few different routes from MCI than from Sprint/MIDNET. I suspect as we become more multi-homed, there will be more. I think trying to come up with a single BCP for the Internet is as flawed as coming up with a single AUP. Different providers will act in their own best interest. Sprint is going to filter whatever sprint wants to filter, regardless of what the BCP says. What we really want is something that shows what all these filtering policies are. Is there a place in the RADB to show you don't route to prefixes longer than 18, 19, 24, whatever bits? Then when a provider runs across a customer that doesn't want to renumber, the provider can run a report against the RADB showing all the places on the net they won't be able to reach. And a report showing all the places they would be able to reach if they renumbered. The customer and the providers can then make their own choices. Maybe there is nothing on those parts of the net they care about, so they won't renumber. Maybe we can take all that disk space filled with old AUP's, and recycle it with new route aggregation policy documents? (RAPs?) -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 17:47:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20751; Sun, 27 Aug 1995 17:47:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA12846; Sun, 27 Aug 1995 17:46:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA12831; Sun, 27 Aug 1995 17:29:50 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20259; Sun, 27 Aug 1995 17:29:45 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id AAA13768; Sun, 27 Aug 1995 00:29:40 -0700 Date: Sun, 27 Aug 1995 00:29:40 -0700 From: Tony Li Message-Id: <199508270729.AAA13768@greatdane.cisco.com> To: amolitor@anubis.network.com (Andrew Molitor) Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal Precedence: bulk I think one thing that gets lost in these discussions is that big router software looks very very little like host software. Forwarding packets at any reasonable rate simply cannot be done withouy doing some fairly hairy dancing, and some hardware assist. So you're not going to be able to solve whatever the global internet's problems are by hacking on a BSD-ish stack and stuffing some SIMMs in somewhere. We're talking 1 or more levels of lookaside caches, custom silicon or FPGA loads, highly optimised packet forwarding paths of several different flavors in the same box, lots of complex stuff. Any of these easy solutions just involving a table and a few lines of code or whatever it is, -- in the forwarding path -- is going to require a substantial development effort, X millions of dollars to get it to market, and if the total market for such work is going to be a few hundred boxes, the core routers, nobody is gonna do it. This corresponds to my view of reality. Please note that I'm one of the co-authors of the currently used switching path in default free cisco 7000's. I may be wrong, and I have great confidence that Tony will straighten me right out if I am, but I think the only reason CIDR got done was because the software was practically doing it anyways, and the bulk of the work was in the routing protocols, which are implemented like host software, not on the forwarding path. I'll agree that the longest match algorithm was in place irrespective of CIDR. OSPF drove that. However, accelerating longest match at cisco happened as a result of CIDR and a few fanatical individuals. We also should thank the IPng discussion, which drove us to demonstrate that variable length addresses could also be accelerated. Any other solutions are going to have to be similarly cheap, or be rolled in with some serious added value that itself has a reasonably sized market. Or, get someone a great big grant. This is not to suggest that any of the ideas I've seen kicked around are necessarily bad, but please, try to figure out why it's of benefit to the corporate and government accounts that are going to buy a truckload of boxes for their internal net. Amen. One of the things that needs to be attached to the spec is a serious business case. Tony From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 19:29:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23704; Sun, 27 Aug 1995 19:29:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA12955; Sun, 27 Aug 1995 19:26:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA12940; Sun, 27 Aug 1995 19:22:08 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23404; Sun, 27 Aug 1995 19:22:03 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch id AA18344; Sun, 27 Aug 1995 11:21:39 +0200 Received: by dxcoms.cern.ch id AA18943; Sun, 27 Aug 1995 11:21:38 +0200 Message-Id: <9508270921.AA18943@dxcoms.cern.ch> Subject: Re: 1. core; 2. conformance To: minshall@ipsilon.com (Greg Minshall) Date: Sun, 27 Aug 1995 11:21:38 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: big-internet@munnari.OZ.AU In-Reply-To: <199508262044.NAA05965@servo.ipsilon.com> from "Greg Minshall" at Aug 26, 95 01:44:00 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 389 Precedence: bulk Greg, > > In other words, either addressing determines topology, or topology determines > addressing. "Who's on top?" > Money determines topology. Lines mainly go in one at a time in response to perceived operational problems (not only load) as providers can manage to fund them. I think the net effect is essentially random topology with a tendency to being provider- based. Brian From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 20:07:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24599; Sun, 27 Aug 1995 20:07:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA13007; Sun, 27 Aug 1995 20:07:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA12989; Sun, 27 Aug 1995 19:52:31 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24166; Sun, 27 Aug 1995 19:52:25 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Sat, 26 Aug 1995 23:40:28 MST." <199508270640.XAA05317@greatdane.cisco.com> Date: Sun, 27 Aug 1995 19:52:03 +1000 Message-Id: <13045.809517123@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sat, 26 Aug 1995 23:40:28 -0700 From: Tony Li Message-ID: <199508270640.XAA05317@greatdane.cisco.com> Frankly, I don't see how we can deviate from our current path, I am not asking for anyone to deviate from the current path, just to avoid the new draconian one - which I don't think actually achieves a lot anyway. If the providers tell people they have to renumber to connect, whether their previous number was "owned" or "leased" makes very little difference. Further, if someone has a "leased" number and they disconnect (and not connect elsewhere) I don't see them going about renumbering, just because their lease expired, or however it is put, if then they want to connect someplace else later, that provider will tell them to renumber, leased or owned, so what would be gain. We all agree that nothing we say can control what the providers actually do here, they're going to do whatever is necessary for them to survive - whether that means to keep their routers functioning, or to attract enough clients. There's a song in some corner of my mind that goes: "Don't make promises that your body can't keep." ;-) I did say "probably" ... Assuming a site isn't bouncing around amongst providers (and I have little reason to think that one would _want_ to), You have to be kidding, or maybe the US is just different. I do DNS updates here, I see sites changing providers constantly. Whether its because the last lot don't have adequate bandwidth, or their service is lousy, or their charges too high, or ... I can't tell, but remain loyal, for lots of them, no way. Further, the small scale providers change their connectivity amongst the bigger guys as well - the current proposals mean that when that happens all the small guy's customers have to renumber, which would be a sight to watch. and because it sends the message that they have no overall control over their internet connectivity, And we dare not tell them the truth? I said *their* internet connectivity. I know no-one has control of the internet as a whole, but I would like to think I can simply ring my current ISP, tell them they're fired, and I have a better deal elsewhere (for my definition of better) and not have to worry about what the hidden costs there are to me as I have to renumber my net. Sorry, I can't parse this. I think you're saying that the only routers that could ever get sold are one's that support your scheme. No, not at all. What I am saying is that routers will get a lot bigger regardless of any other influences than current hardware trends. I doubt you could build an IGS now if you wanted to, your hardware design people would tell you it is folly, and not because a small cheap box isn't saleable, because the parts can no longer be guaranteed. I am simply saying that the size increase I need for my scheme will naturally fall out what is going to be available anyway. I should point out that there are a VERY significant number of IP routers out there that not connected to the Internet. That's fine - they will get bigger too. They must, because you won't be able to build them that small. A company could EASILY decide to pass up the Internet router market during this interim period and jump straight to IPv6. Or only sell interior routers. Sure. A lot of this will depend on what the providers want to buy. If they decide they don't like my scheme, and won't implement it, whatever the router vendors do, then it doesn't make a lot of difference. Their decision will come from their customers, what they are willing to pay for and put up with. I think if I was an ISP now, I'd be asking customers whether they'd prefer to have to renumber every time they switch providers, or their providers switch bigger providers if they aren't huge enough to claim a globally routable prefix, or whether they'd rather pay a slightly increased rate so the providers can implement and manage a mapping scheme to eventually make renumbering obsolete. I know which way I will vote - but perhaps there aren't enough people like me around, perhaps your average consumer likes renumbering, or considers it easy enough that they will be willing to do that when required. If so, perhaps the hold outs like me (not many of us after all) can simply keep our unrenumbered nets - and note that includes future hold outs, who don't yet have numbers or connections. If there aren't many of us, the routing should cope OK anyway, right? If there are a lot however, the ISP's may prefer to ask for the mapping scheme. At that point they will look for some vendor willing to supply it to them. Now there's no doubt that the straight $ profits from selling these boxes wouldn't make it worth the effort, but if vendor XXX provides this, and the ISP's all stop buying whatever they are buying now, and start buying from XXX instead, then the newspaper, and magazine headlines "Internet switches to XXX routers" just might not be what the old router vendor's management & sales types really want to see. The public relations benefit from supplying the internet core has to be worth orders of magnitude more than the $ profits from the boxes sold there. Please send me your resume. No ;-). No, not looking for a job ... but if no-one with suitable hardware is willing to look at implementing this, and no-one will let me have a go at implementing it in their boxes, then proceeding further on specifying it seems pointless. I think I could implement this, it would take me much longer than you to have a go at it and produce something, and the result would be of much lower quality (you wouldn't want to ship it), but I think I could demonstrate it can be done. Just ship me the code to modify... (non disclosure is fine...) And I suppose you're adding stable storage so all this persists past router reboots, etc. I never said that I was building a NAT.... The original question, if I remember it correctly, was along the lines of putting a NAT in the router in the ISP to which the customers connect. I assume you're not about to build it, NATS are almost impossible to do right, but you did say it might be feasible. By carefully controlling the DNS TTL and watching active flows, we have a really good idea of how long it's alive. No, no, you're falling into the trap of assuming that DNS TTL's mean anything other than how long DNS servers can cache the results. Perhaps they should mean the actual lifetime of the address returned, but in practice, they simply don't. The API's used by the applications lose this value - the applications simply get the address, and assume it a constant, forever. Once having obtained the addr, applications simply don't validate it again. That may be broken, or wrong, or whatever, but it is a fact. This is all a part of the "assume addresses are immutable" that has existed in the Internet for a very long time. It is ingrained everywhere. DNS TTL's are irrelevant to anything but DNS servers. One place IP addresses appear is in Received headers, And the proper way to do a NAT is to translate those as well. Yes, I was assuming that happened - or more accurately, I was assuming that the header address was translated, my mailer gets the address from there, and puts it in the Received header, it is the translated address that is of interest. Admittedly, the stored address isn't going to remain bound. Which is the problem. Currently I can look at mail I received ages ago, and if something was wrong with the From or something, that IP address will often get mail back again. At the very least I can look up the owner of the number in the whois database and attempt to figure out an address starting with the responsible person for that net number. All this breaks if numbers start being altered (either by NAT boxes that don't keep a constant mapping, or renumbering) So you're proposing that your prefix mapping table be dynamically assigned? Sorry, I don't see how this works. No, not dynamically assigned, but obtained dynamically from somewhere. And no, I am not really proposing that, just saying that if it could work for a NAT it could also work for mapping. I don't really believe either. Please do NOT make the rash assumption that cisco will buy into this scheme. No, I was not. "you guys" meant "router vendors". As long as one router vendor has a go at this, and it works, and the ISP's (core ISP's) consider it worth implementing, that is enough. And it's not clear that the tradeoff makes sense. If it's used at the leaves, then there are lots more of them. I don't think it's 50-50 here. No, I have no idea where the balance point would be. That doesn't matter to me, the point is that the ISP's can stick this mapping function at any point, just as they can run their default free routing completely through their net, or only at the few key points that connect to other ISP's. There are trade offs involved, they are not for me to make. My feelings are based on my implementation experience. That I respect - but I have also seen how much other stuff that has been demanded by the customer base you have been able to make work, and make work fast. Access lists now are much more complex, and much more quickly processed, than the first routers I saw. Access list (filter) processing just has to be more complex than anything I am asking for - and that you can't cache any part of the result for, each packet needs the full treatment. Even if all of the nits get worked out, everyone buys off and gets cranking, I think that things are still farther off than you suspect. That may be. I suspect that we still have to push on CIDR very hard. Push hard, just leave that final step. And if we push hard enough to keep the net running long enough for your scheme to be deployed, we'll also have the technology just to run with CIDR. No, that we will not get. That is, we may develop it, but it will never be deployed soon enough to matter. IPv6 will be the replacement for many boxes being shipped now - whatever we stick in the next generation of end user boxes is too late to really help. You cancertainly develop and ship, to the Internet core, several versions of anything at all before the end user system people can get even one new generation of anything to be widespread enough to matter. Continued CIDR means continued renumbering, if mapping works that renumbering can be avoided, for everyone. Even if we had forced renumbering for some time in the interim, being able to end it would make everyone's life easier. I too am in the situation where I cannot prove this without actually trying it. Yes, if our roles were reversed I would have a big advantage, in that I could write the code and try it in my spare time (instead of reading B-I for example...) and see if I could make it work. To test high level aggregation means actually using it on the net, which means asking people to renumber. And then renumber again, and again - because its going to be when it gets to about the third "you have to renumber" that the customer base is going to decide that enough is enough, even the ones that could renumber once. kre From owner-Big-Internet@munnari.OZ.AU Sun Aug 27 23:27:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29824; Sun, 27 Aug 1995 23:27:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA13221; Sun, 27 Aug 1995 23:26:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA13204; Sun, 27 Aug 1995 23:23:28 +1000 Received: from chops.icp.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29683; Sun, 27 Aug 1995 23:23:19 +1000 (from smd@icp.net) Received: by chops.icp.net with SMTP id <20697>; Sun, 27 Aug 1995 09:23:11 -0400 To: Robert Elz Cc: asp@uunet.uu.net (Andrew Partan), big-internet@munnari.OZ.AU Subject: Re: Administrivia. In-Reply-To: Your message of "Sat, 26 Aug 1995 17:43:09 +1000." <12880.809422989@munnari.OZ.AU> Date: Sun, 27 Aug 1995 09:23:04 -0400 From: Sean Doran Message-Id: <95Aug27.092311-0400_edt.20697+626@chops.icp.net> Precedence: bulk In message <12880.809422989@munnari.OZ.AU>, Robert Elz writes: | One thing that is out of order here is meta discussions about | whether other discussions should be carried on here or not. | Those discussions are definitely not related to the growth | or size of the internet. On the contrary; I have observed first hand that the signal to noise ratio of any given publically-subscribable list worsens as the population of the Internet increases. I have also noticed that there is a relation between the size of the Internet and meta discussions about whether other discussions should be carried on in any given publically-joinable place. Finally, I have even noticed that the depth of the meta-discussion stack (that is, discussions about discussions about discussions) has a tendency to increase as the size of the Internet increases. I think, therefore, that Andrew's comments, while not precisely apropos to the growth or to the size of the Internet, they certainly are related to both, and I would wager are particularly symptomatic of the former. Sean. (who, btw, tends to be very quiet here for much the same reasons that my evil twin asp stays quiet on CIDRD) From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 00:08:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01446; Mon, 28 Aug 1995 00:08:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA13284; Mon, 28 Aug 1995 00:06:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA13276; Sun, 27 Aug 1995 23:59:17 +1000 Received: from chops.icp.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00787; Sun, 27 Aug 1995 23:59:11 +1000 (from smd@icp.net) Received: by chops.icp.net with SMTP id <20697>; Sun, 27 Aug 1995 09:59:02 -0400 To: "William Allen Simpson" Cc: big-internet@munnari.OZ.AU (bigi) Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Fri, 25 Aug 1995 20:35:22 GMT." <4534.bsimpson@morningstar.com> Date: Sun, 27 Aug 1995 09:58:51 -0400 From: Sean Doran Message-Id: <95Aug27.095902-0400_edt.20697+627@chops.icp.net> Precedence: bulk In message <4534.bsimpson@morningstar.com>, "William Allen Simpson" writes: | The Routing Arbiter software is up and running, and provides exactly the | information that would be needed for mapping the 30K routes to ASs, to | be used for tunneling. It, in fact, does not. The RADB was populated from the PRDB, and as a consequence a great deal of information about the home ASes for any given prefix was wrong from the start of the RADB. Moreover, at the very beginning when the auto-dbm doors were thrown open, the RADB was being populated with more prefixes which have inconsistencies wrt the associations between prefix and home-as. This was happily glossed over quite a bit by a number of the folks waging the jihad in favour of the RADB, and unfortunately has already led to the point where the data in the RADB is of marginal use in debugging ANS's router configurations, and little else. This is somewhat fixable given some recent tools developed after the Stockholm IETF (thanks, MERIT), however there is a great deal of effort in moving from identifying inconsistencies to actually fixing them, particularly given the coordination effort imposed by the way maintainer objects work. The question of whether there is any point to putting this effort into making the RADB reflect reality is highly debatable, and is frequently debated by the folks who think it is marginally useful at best and the people who rely upon it for their router configs. Meanwhile, there are lots of people who are deciding that the effort required to install correct information into an originally and increasingly incorrect database that is moreover increasingly solely the ANS PRDB, is simply not worthwhile. | The problem is that many other places talking BGP, even in the US, still | aren't using the database. The problem is that it is considerably easier right now to track down and fix the kinds of problems (read, leaking prefixes) that the RADB can be used to avoid than it is to make sure that the RADB is correct in the first place. Moreover, it is the judgement of many providers that much more time and cost is spent on maintaining the RADB than on dealing with operational issues like leaking prefixes. That said, there is some value between a mapping from prefix to point-of-contact. That mapping currently exists at the various neutral IP address registries like the InterNIC. | But using it to route the "core" would be a real buy-in incentive.... The only incentive is that you need to use the RADB to talk to ANS because of some of their engineers' politics, and their inability to build the same type of router configs as everyone else who uses gated, pure and simple. (Un?)fortunately, as the size of the non-ANS Internet increases, this reliance upon the RADB will begin to hurt them and their customers like Seiden (just to pick a name out of a recent conversation and a couple of RADB-related trouble tickets from ANS) much more than it will act as an incentive for people to register anything at all (much less correct information) in the RADB. Sean. From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 00:47:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02641; Mon, 28 Aug 1995 00:47:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA13404; Mon, 28 Aug 1995 00:46:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA13389; Mon, 28 Aug 1995 00:32:51 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02309; Mon, 28 Aug 1995 00:32:48 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id HAA03496; Sun, 27 Aug 1995 07:32:39 -0700 Message-Id: <199508271432.HAA03496@hubbub.cisco.com> To: Tony Li Cc: big-internet@munnari.OZ.AU, atkinson@itd.nrl.navy.mil (Ran Atkinson) Subject: Re: Multi-homed sites In-Reply-To: Your message of "Fri, 25 Aug 95 23:30:53 PDT." <199508260630.XAA29501@greatdane.cisco.com> Date: Sun, 27 Aug 95 07:32:39 PDT From: Yakov Rekhter Precedence: bulk Tony, > > My preference for NRL-DC, which campus has not moved since it was created > just after WW-I and is pretty darn unlikely to ever move, would be for > NRL-DC to have an IPv6 address space that looked something like: > > > > The "Routing Prefix for FIX-EAST" chunk would be the only prefix > that most network providers would need to store in their routing tables. > > This is a close relative of metro addressing. Let's start by looking To be more correct, this is a close relative to an indirect (one hop away) provider-based address allocation. Just look at the address itself. There is nothing in the address above that identifies geography, but there is component, and upone some introspection one could realise that FIX-EAST is a provider as well. In fact, if there would be another exchange in the D.C. area, called FIX-EAST-PRIME, then NRL would have two choices: OR Yakov. From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 01:28:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03904; Mon, 28 Aug 1995 01:28:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA13477; Mon, 28 Aug 1995 01:27:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA13460; Mon, 28 Aug 1995 01:18:20 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03596; Mon, 28 Aug 1995 01:18:17 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id IAA04249; Sun, 27 Aug 1995 08:18:14 -0700 Message-Id: <199508271518.IAA04249@hubbub.cisco.com> To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Sat, 26 Aug 95 17:38:47 +0900." <12875.809422727@munnari.OZ.AU> Date: Sun, 27 Aug 95 08:18:14 PDT From: Yakov Rekhter Precedence: bulk Robert, In the encaps proposal you bound the size of the mapping table by constraining the entries in the table to be /24 prefixes. Correct ? How would your scheme work when a site that has /25 prefix changes its provider ? Yakov. From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 01:29:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03977; Mon, 28 Aug 1995 01:29:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA13499; Mon, 28 Aug 1995 01:28:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA13457; Mon, 28 Aug 1995 01:15:49 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03553; Mon, 28 Aug 1995 01:15:44 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id IAA04220; Sun, 27 Aug 1995 08:15:42 -0700 Message-Id: <199508271515.IAA04220@hubbub.cisco.com> To: Robert Elz Cc: big-internet@munnari.OZ.AU, yakov@cisco.com Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Sat, 26 Aug 95 17:38:47 +0900." <12875.809422727@munnari.OZ.AU> Date: Sun, 27 Aug 95 08:15:42 PDT From: Yakov Rekhter Precedence: bulk Robert, > Date: Fri, 25 Aug 95 13:35:38 PDT > From: Yakov Rekhter > Message-ID: <199508252035.NAA27703@hubbub.cisco.com> > > Let's assume that the total number of existing advertised prefixes is N. > > OK. > > Is it correct that the mapping table would need to have N entries as > well ? If not, then what is that number ? > > Yes, it is N. > > If you're about to claim, that then this obviously represents > no saving, then you're wrong, the saving is that the mapping > table entry is (much) smaller than the routing table entry, > with a reasonable upper bound on its size, and further, doesn't > depend on the number of paths to the destination. For now (based on your response) I claim that if the total number of advertised prefixes is N, then the mapping table would need to have *at least* N entries as well. In addition to the mapping table the encaps scheme would also need a forwarding table that maintains routing within the "core". Is that correct ? Yakov. From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 02:07:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05171; Mon, 28 Aug 1995 02:07:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA13548; Mon, 28 Aug 1995 02:07:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA13542; Mon, 28 Aug 1995 01:57:49 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04943; Mon, 28 Aug 1995 01:57:45 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.59] ([204.247.5.59]) by aimnet.com (8.6.12/8.6.12) with SMTP id IAA04809; Sun, 27 Aug 1995 08:56:58 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Aug 1995 08:57:42 -0700 To: Tony Li From: Dave Crocker Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 11:40 PM 8/26/95, Tony Li wrote: >Interesting. Assuming a site isn't bouncing around amongst providers >(and I have little reason to think that one would _want_ to), what >other causes of renumbering do you see? Interesting, indeed. Curious kind of question. Tony, I once dated a woman who thought we should get married. I pointed out to her that I didn't think we were ready, since our communication was not very good (actually it was terrible, though perhaps not as bad as between some participants on this list.) SHE responded that other than that we got along just fine. Your question presumes that subscribers and local providers do not change their providers. One way of describing this is that they are held hostage. So, yes. Other than needing to make it practical to change providers, renumbering probably isn't an issue. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 02:27:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05840; Mon, 28 Aug 1995 02:27:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA13599; Mon, 28 Aug 1995 02:27:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA13582; Mon, 28 Aug 1995 02:24:22 +1000 Received: from ACADEM.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05694; Mon, 28 Aug 1995 02:24:14 +1000 (from sob@academ.com) Received: (from sob@localhost) by academ.com (8.6.12/8.6.9) id LAA02398; Sun, 27 Aug 1995 11:22:38 -0500 Message-Id: <199508271622.LAA02398@academ.com> From: sob@academ.com (Stan Barber) Date: Sun, 27 Aug 1995 11:22:38 CDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Sean Doran , "William Allen Simpson" Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU (bigi) Precedence: bulk > The question of whether there is any point to putting this > effort into making the RADB reflect reality is highly > debatable, and is frequently debated by the folks who think > it is marginally useful at best and the people who rely upon > it for their router configs. Sean, you have left out the folks that use the RADB information as one source of debugging data when trying to figure out which provider should be announcing a particular route. Even with the inaccuracies you note, it (and other other parts of the GRR) is still the only way to get this information without turning to the stuff actually advertised. > Meanwhile, there are lots of people who are deciding that > the effort required to install correct information into an > originally and increasingly incorrect database that is > moreover increasingly solely the ANS PRDB, is simply not > worthwhile. Is there some survey that proves this point? Please substantiate this claim with any relevant survey infomation or stop making it. Just because a few folks are more vocal than others does not mean that everyone thinks that way. > The problem is that it is considerably easier right now to > track down and fix the kinds of problems (read, leaking prefixes) > that the RADB can be used to avoid than it is to make > sure that the RADB is correct in the first place. Moreover, > it is the judgement of many providers that much more time and > cost is spent on maintaining the RADB than on dealing with > operational issues like leaking prefixes. Is there some survey that proves this point? Please substantiate this claim with any relevant survey infomation or stop making it. Since I was already doing NACRs anyway, I find I spend no more time interacting with RADB than I did when I did NACRs. > That said, there is some value between a mapping from > prefix to point-of-contact. That mapping currently > exists at the various neutral IP address registries > like the InterNIC. I am confused. Do you not see the RADB as a neutral registry? If not, please explain. > The only incentive is that you need to use the RADB to talk > to ANS because of some of their engineers' politics, and > their inability to build the same type of router configs > as everyone else who uses gated, pure and simple. I disagree. I make use of the RADB (and the rest of the GRR) on a regular basis and I have no connection direct connection to ANS. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 02:47:39 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06784; Mon, 28 Aug 1995 02:47:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA13657; Mon, 28 Aug 1995 02:47:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA13620; Mon, 28 Aug 1995 02:34:49 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06024; Mon, 28 Aug 1995 02:34:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21962; Sun, 27 Aug 95 12:34:34 -0400 Date: Sun, 27 Aug 95 12:34:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508271634.AA21962@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, tli@cisco.com Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker > Assuming a site isn't bouncing around amongst providers (and I have > little reason to think that one would _want_ to), what other causes of > renumbering do you see? Your question presumes that subscribers and local providers do not change their providers. No. His question asked for causes of renumbering other than switching providers. His parenthetical comment I read to say that one wouldn't normally be constantly switching providers ("bouncing" doesn't imply, to me at least, an occasional, well-motivated switch). This latter point seems reasonable to me, BTW. Most of the individuals who switch long-distance carriers constantly are doing so in response to campaigns that offer people short-term benefits for switching. The LDC's now seeem to be realizing that these marketing campaigns aren't offering long-term beenfits, all they have done is create a class of switch-junkies, and I expect they will be wound down soon. I expect that most commercial customers do not constantly switch their long-distance providers. One way of describing this is that they are held hostage. So, yes. Other than needing to make it practical to change providers, renumbering probably isn't an issue. Your constant whining repetition of this point is not adding anything to the debate. Yes, we all know that renumbering is going to be less than painless, and we know that that's going to make switching providers less than painless. How is pointing this out for the 178th time to people who already appreciate that point quite well helping bring the debate to a closure? Noel From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 03:27:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07890; Mon, 28 Aug 1995 03:27:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA13741; Mon, 28 Aug 1995 03:26:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA13724; Mon, 28 Aug 1995 03:23:28 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07783; Mon, 28 Aug 1995 03:23:25 +1000 (from kre@munnari.OZ.AU) To: Yakov Rekhter Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Sun, 27 Aug 1995 08:15:42 PDT." <199508271515.IAA04220@hubbub.cisco.com> Date: Mon, 28 Aug 1995 03:22:58 +1000 Message-Id: <13383.809544178@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sun, 27 Aug 95 08:15:42 PDT From: Yakov Rekhter Message-ID: <199508271515.IAA04220@hubbub.cisco.com> For now (based on your response) I claim that if the total number of advertised prefixes is N, then the mapping table would need to have *at least* N entries as well. I'm not sure where the "at least" comes from, it needs exactly N entries. Of course, implementation techniques can decide to store that any way at all, just as they could for aggregated CIDR blocks, but N is the number, not one more or less. Further, any aggregation that happens to be possible will reduce that number for the mapping table, just as for CIDR routes. In addition to the mapping table the encaps scheme would also need a forwarding table that maintains routing within the "core". Is that correct? Yes. That of course can be made (almost) arbitrarily small by suitably aggregating the various internal routes (they can be renumbered as desired to assist in that). Ie: they can actually approach the cidr ideal. Of course, there's no point making this smaller than needed to keep it small enough to fit, as any aggregation loses some routing optimality. There's also the routing & forwarding tables for the "local" net whatever that is - which can also be reduced by splitting the local area into multiple smaller areas managed by different routers. kre From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 03:28:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07989; Mon, 28 Aug 1995 03:28:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA13763; Mon, 28 Aug 1995 03:28:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA13721; Mon, 28 Aug 1995 03:13:08 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07441; Mon, 28 Aug 1995 03:12:55 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.59] ([204.247.5.44]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA11033; Sun, 27 Aug 1995 10:12:07 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Aug 1995 10:12:51 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 9:34 AM 8/27/95, Noel Chiappa wrote: >No. His question asked for causes of renumbering other than switching >providers. His parenthetical comment I read to say that one wouldn't normally >be constantly switching providers ("bouncing" doesn't imply, to me at least, >an occasional, well-motivated switch). You're right as always, Noel. Tony clearly wouldn't be looking for ways to discount the concern for renumbering. No doubt his use of the term "bouncing" wasn't meant as hyperbole to encompass the entire class of users that would change providers, possibly even to be applied for large number of changes that occur for reasons beneficial to the users. I'm sure his question was simply to make sure that the list of reasons was complete. >that offer people short-term benefits for switching. The LDC's now seeem to be >realizing that these marketing campaigns aren't offering long-term beenfits, >all they have done is create a class of switch-junkies, and I expect they will That's why the rate of postal and telephone solicition from the LDCs has gone down from daily to weekly? >Your constant whining repetition of this point is not adding anything to the >debate. Yes, we all know that renumbering is going to be less than painless, "whining". Well, good to see a broad spectrum of support for the use of hyperbole. As for your complaint about repetition of strong concerns, I have to quote another Internet notable: "That's rich, coming from YOU." Perhaps the whining is due to the constant and facile dismissal of the concern by those in favor of cidr? No, no. That couldn't be the case. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 03:47:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08478; Mon, 28 Aug 1995 03:47:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA13810; Mon, 28 Aug 1995 03:47:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA13783; Mon, 28 Aug 1995 03:31:39 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08163; Mon, 28 Aug 1995 03:31:36 +1000 (from kre@munnari.OZ.AU) To: Yakov Rekhter Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Sun, 27 Aug 1995 08:18:14 PDT." <199508271518.IAA04249@hubbub.cisco.com> Date: Mon, 28 Aug 1995 03:31:12 +1000 Message-Id: <13388.809544672@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sun, 27 Aug 95 08:18:14 PDT From: Yakov Rekhter Message-ID: <199508271518.IAA04249@hubbub.cisco.com> In the encaps proposal you bound the size of the mapping table by constraining the entries in the table to be /24 prefixes. Correct ? That is how I bound the size estimates, yes. How would your scheme work when a site that has /25 prefix changes its provider ? This is a good question. For a site with a /25 I would renumber them, once, and give them a /24, and yes, waste that much address space, with the probablity that they will probably grow to need it anyway in the not too distant future. As the masks get longer I would tend to expect that renumbering is the better choice most of the time - down to the limiting case of a /32 (one host) which I would certainly renumber, and which is probably having its address assigned dynamically by PPP or something anyway (renumbering every day). However, I would allow anyone, however small, to acquire a /24 if they can justify a special case where renumbering would be a particular hardship for them. For very small sites, where the address waste would be biggest, I doubt that this will be easy to do - its the bigger ones (50 hosts and up) where renumbering starts to get harder (probably exponentially...) kre From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 08:07:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17513; Mon, 28 Aug 1995 08:07:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA14042; Mon, 28 Aug 1995 08:07:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA14038; Mon, 28 Aug 1995 08:00:49 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17227; Mon, 28 Aug 1995 08:00:45 +1000 (from bsimpson@morningstar.com) Received: from merit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA18302 Mon, 28 Aug 1995 07:24:34 +1000 (from bsimpson@morningstar.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-25.dialip.mich.net [141.211.7.36]) by merit.edu (8.6.12/merit-2.0) with SMTP id RAA14905 for ; Sun, 27 Aug 1995 17:19:30 -0400 Date: Sun, 27 Aug 95 20:22:16 GMT From: "William Allen Simpson" Message-Id: <4548.bsimpson@morningstar.com> To: big-internet@munnari.OZ.AU Subject: current MAE East losses Precedence: bulk Just thought I'd wait until the weekend to get a baseline for traffic through Mae-East (it fluctuates a lot during the week), so here it is, measured at: 204.70.57.10 mae-east-plusplus.Washington.mci.net. Short (0 data), 5 second spaced pings. Fairly stable values. sent rcvd % rtt avg mdev max min 400 301 75 281 295 20 640 247 401 302 75 314 297 20 640 247 402 303 75 270 294 22 640 247 403 304 75 274 292 22 640 247 405 305 75 396 297 41 640 247 Note that this is _better_ throughput than we see on weekdays! We are talking about one _very_ congested puppy.... All traffic across Ann Arbor goes through this link, via (bypassing) Chicago, Boston, and NewYork, despite the fact that Merit/MichNet has a direct link to Washington already, and so does MSEN. So much for regional NAPs and inter-provider cooperation.... I believe that KRE's proposal would alleviate this congestion, because it would provide a better human managed view of the actual topology, rather than the nearly all default routing we get now. Now, it could be that this is all because of the amazingly badly managed RADB, as Sean claims. Or it could be that some providers aren't _using_ the RADB and propagating it properly, as others claim. KRE's proposal would cause a serious amount of buy-in for the RADB, since the "core" routes would depend on it. I suspect those AS mappings would get fixed in a hurry.... Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 12:07:54 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26588; Mon, 28 Aug 1995 12:07:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA14257; Mon, 28 Aug 1995 12:06:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA14253; Mon, 28 Aug 1995 11:59:38 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26131; Mon, 28 Aug 1995 11:58:54 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00157 Mon, 28 Aug 1995 11:58:02 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzerf29054; Sun, 27 Aug 1995 21:56:39 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: ownership, leasing, renumbering, and that draft To: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 27 Aug 1995 21:56:39 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <13012.809502197@munnari.OZ.AU> from "Robert Elz" at Aug 27, 95 03:43:17 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1450 Precedence: bulk > Oh, no no, that was never the plan, we must have read the "install > NAT boxes" suggestion differently. I read that as suggesting > that you (ie: the providers) install NAT boxes (or more accurately, > install NAT code in the routers) at the point(s) where your > customers connect to you - no change in your customer's view of > the world, they do nothing, you do the translations. (No > comment about whether this could work, I myself see only a limited > future for NAT, but that was how I saw the suggestion). The 1st point that I control between my customer's LAN and my backbone boxes is my backbone box itself. Typically you have some backbone box, a leased line, a customer access router, and then the customer's LAN. Some ISPs run/control/own that customer access router. We don't (the customer owns that box). A perhaps 'ideal' place to put a box like a NAT box or a box doing your trick would be someplace that has limited bandwidth (limited packets) and 'extra' CPU - that would be the customer access router. However, we don't run that box - the customers do; and typically that box is put into place once when the customer first gets a conneciton & does not change it after that. Thus I am lead to the only other place that I can make changes - my backbone routers. In any case, I think that there was a bit of confusiton in the models here & thus which boxes could be changed easilly. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 13:10:06 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29149; Mon, 28 Aug 1995 13:10:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA14333; Mon, 28 Aug 1995 13:07:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA14314; Mon, 28 Aug 1995 12:50:39 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28434; Mon, 28 Aug 1995 12:50:22 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by shark.mel.dit.csiro.au with SMTP id AA10838 (5.65c/IDA-1.4.4/DIT-1.3); Mon, 28 Aug 1995 12:50:07 +1000 Received: by rodan.UU.NET id QQzerj12076; Sun, 27 Aug 1995 22:46:53 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Discussing encap/mapping proposal To: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 27 Aug 1995 22:46:52 -0400 (EDT) Cc: tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <13045.809517123@munnari.OZ.AU> from "Robert Elz" at Aug 27, 95 07:52:03 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 771 Precedence: bulk I was thinking about deployment issues of these various things. With NAT boxes and renumbering, its very easy - applying either to a single site effects just that site, perhaps their provider, and perhaps a few other places (like some external DNS servers & the like). However doing something like Robert's scheme means an encapsulator/mapper near the site and a large number of deencapsulators/demappers all around the edges of the 'core'. You have both all of the work of deploying these initially and then all of the work of doing the coordination needed so that you can know that you can turn on a new mapping at one place & actually have it work at all of the other places. A rather different scale of problem & coordination. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 13:29:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB00147; Mon, 28 Aug 1995 13:29:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA14379; Mon, 28 Aug 1995 13:27:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA14364; Mon, 28 Aug 1995 13:21:52 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29634; Mon, 28 Aug 1995 13:21:46 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id XAA10096; Sun, 27 Aug 1995 23:21:00 -0400 Date: Sun, 27 Aug 1995 23:21:00 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: William Allen Simpson Cc: big-internet@munnari.OZ.AU Subject: Re: current MAE East losses In-Reply-To: <4548.bsimpson@morningstar.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 27 Aug 1995, William Allen Simpson wrote: > We are talking about one _very_ congested puppy.... All traffic across > Ann Arbor goes through this link, via (bypassing) Chicago, Boston, and > NewYork, despite the fact that Merit/MichNet has a direct link to > Washington already, and so does MSEN. So much for regional NAPs and MSEN does have a direct link to Washington, via AGIS, but Merit/MichNet does not have a direct link to Washington. The only thing close to it, to my knowledge is a dail up link between CIESIn and sura net. Perhaps I'm misunderstanding something here. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 14:09:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01956; Mon, 28 Aug 1995 14:09:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA14428; Mon, 28 Aug 1995 14:07:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA14424; Mon, 28 Aug 1995 14:03:17 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01577; Mon, 28 Aug 1995 14:03:08 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id AAA10335; Mon, 28 Aug 1995 00:01:19 -0400 Date: Mon, 28 Aug 1995 00:01:19 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: William Allen Simpson Cc: big-internet@munnari.OZ.AU Subject: Re: current MAE East losses In-Reply-To: <4548.bsimpson@morningstar.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 27 Aug 1995, William Allen Simpson wrote: > We are talking about one _very_ congested puppy.... All traffic across > Ann Arbor goes through this link, via (bypassing) Chicago, Boston, and > NewYork, despite the fact that Merit/MichNet has a direct link to > Washington already, and so does MSEN. So much for regional NAPs and My mistake. Merite does have a connection to Washington for the Route Servers and such. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 15:50:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06121; Mon, 28 Aug 1995 15:50:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA14538; Mon, 28 Aug 1995 15:47:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA14532; Mon, 28 Aug 1995 15:42:44 +1000 Received: from panix3.panix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05868; Mon, 28 Aug 1995 15:42:31 +1000 (from hal9001@panix.com) Received: (from hal9001@localhost) by panix3.panix.com (8.6.12/8.6.12+PanixU1.1) id BAA21094; Mon, 28 Aug 1995 01:42:07 -0400 X-Sender: hal9001@popserver.panix.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Mac Eudora Pro 2.1.3 Date: Mon, 28 Aug 1995 01:42:05 -0400 To: Tony Li From: "Robert A. Rosenberg" Subject: Re: Discussing encap/mapping proposal Cc: kre@munnari.OZ.AU, big-internet@munnari.OZ.AU Precedence: bulk At 23:40 8/26/95, Tony Li wrote: >Interesting. Assuming a site isn't bouncing around amongst providers >(and I have little reason to think that one would _want_ to), what >other causes of renumbering do you see? How about their provider hopping around. My provider has just gone dual homed with the stated intent to get a third connection and then drop the original unreliable ISP connection. If they had to renumber to go to another provider, I would too (since my number come from them). In this case they have a InterNIC supplied Prefix and the block is big enough for them to be a CIDR in and of themself. From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 17:10:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09022; Mon, 28 Aug 1995 17:10:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA14620; Mon, 28 Aug 1995 17:07:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA14616; Mon, 28 Aug 1995 16:57:04 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08359; Mon, 28 Aug 1995 16:56:09 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA14225; Sun, 27 Aug 1995 23:55:34 -0700 Date: Sun, 27 Aug 1995 23:55:34 -0700 From: Tony Li Message-Id: <199508280655.XAA14225@greatdane.cisco.com> To: hal9001@panix.com Cc: kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: (hal9001@panix.com) Subject: Re: Discussing encap/mapping proposal Precedence: bulk How about their provider hopping around. My provider has just gone dual homed with the stated intent to get a third connection and then drop the original unreliable ISP connection. If they had to renumber to go to another provider, I would too (since my number come from them). In this case they have a InterNIC supplied Prefix and the block is big enough for them to be a CIDR in and of themself. Then you have no problems, correct? This is exactly the situation of a organization which (in the eyes of the InterNIC or other registry) aggregates a sufficient amount of address space that they get their own CIDR block. The point that I was trying to make is that very frequent "hopping" is very unlikely. There are substantial up front costs to changing providers which are well known. For example, if you have a leased line, you have a line installation fee. Even if you don't have a leased line, you probably either don't have a permanent address (in which case renumbering happens EVERY time you dial) and you have more tangible costs, such as a changing user name. Or you receive some other tangible benefit from the provider (e.g. DNS support, mail queueing for POP delivery). Switching providers implies changing these services as well. Clearly in the latter case, these costs are imposed on the providers, who in turn MAY choose to relay those costs to the moving site. Tony From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 17:29:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB09652; Mon, 28 Aug 1995 17:29:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA14676; Mon, 28 Aug 1995 17:27:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA14641; Mon, 28 Aug 1995 17:11:07 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08847; Mon, 28 Aug 1995 17:07:44 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id AAA21399; Mon, 28 Aug 1995 00:07:35 -0700 Date: Mon, 28 Aug 1995 00:07:35 -0700 From: Tony Li Message-Id: <199508280707.AAA21399@greatdane.cisco.com> To: asp@uunet.uu.net Cc: kre@munnari.OZ.AU, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: (asp@uunet.uu.net) Subject: Re: Discussing encap/mapping proposal Precedence: bulk However doing something like Robert's scheme means an encapsulator/mapper near the site and a large number of deencapsulators/demappers all around the edges of the 'core'. You have both all of the work of deploying these initially and then all of the work of doing the coordination needed so that you can know that you can turn on a new mapping at one place & actually have it work at all of the other places. Here's a niggling question that has been bothering me: how does one transition onto Robert's scheme without a flag day? Tony From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 18:48:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12948; Mon, 28 Aug 1995 18:48:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA14808; Mon, 28 Aug 1995 18:47:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA14771; Mon, 28 Aug 1995 18:35:32 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12367; Mon, 28 Aug 1995 18:35:04 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA24761; Mon, 28 Aug 1995 01:34:57 -0700 Date: Mon, 28 Aug 1995 01:34:57 -0700 From: Tony Li Message-Id: <199508280834.BAA24761@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: <13045.809517123@munnari.OZ.AU> (message from Robert Elz on Sun, 27 Aug 1995 19:52:03 +1000) Subject: Re: Discussing encap/mapping proposal Precedence: bulk Robert, Frankly, I don't see how we can deviate from our current path, I am not asking for anyone to deviate from the current path, just to avoid the new draconian one - which I don't think actually achieves a lot anyway. By "new draconian one", I infer that you mean renumbering and that by "current" you imply the status quo. That is pretty clearly insufficient. We will still have new sites requesting "portable" addresses, no explanation for why they are suboptimal, and a resulting exponential growth in the routing table. Nothing left for you to save. If the providers tell people they have to renumber to connect, whether their previous number was "owned" or "leased" makes very little difference. Further, if someone has a "leased" number and they disconnect (and not connect elsewhere) I don't see them going about renumbering, just because their lease expired, or however it is put, if then they want to connect someplace else later, that provider will tell them to renumber, leased or owned, so what would be gain. We all agree that nothing we say can control what the providers actually do here, they're going to do whatever is necessary for them to survive - whether that means to keep their routers functioning, or to attract enough clients. Agreed. Fortunately, there is some significant business case for them to keep the net working as smoothly as possible. Assuming a site isn't bouncing around amongst providers (and I have little reason to think that one would _want_ to), You have to be kidding, or maybe the US is just different. I do DNS updates here, I see sites changing providers constantly. Whether its because the last lot don't have adequate bandwidth, or their service is lousy, or their charges too high, or ... I can't tell, but remain loyal, for lots of them, no way. As I mentioned in a previous message to someone else, many individual users do change frequently. [Usually this is due to scaling problems (I sense a theme here) at an ISP which cannot deploy support personnel {modems, cycles, etc.} quickly enough. I digress.] Such users normally have only a temporary IP address, negotiated via PPP. For them renumbering is a non-issue. For those paying permanent line costs, there's a large installation charge. And for the remainder (intermittent connectivity, fixed addresses), they still have to bother people like you to change providers. This is a service that someone is providing, and I expect that at some point, folks will get around to distributing that cost. I should also note that many ISPs here have some sort of "setup" fee to cover exactly these costs. I said *their* internet connectivity. I know no-one has control of the internet as a whole, but I would like to think I can simply ring my current ISP, tell them they're fired, and I have a better deal elsewhere (for my definition of better) and not have to worry about what the hidden costs there are to me as I have to renumber my net. Let's make no mistake about it: changing providers wasn't free before. At best, the costs are absorbed by the providers, but I don't expect that situation to last for a significant amount of time as competition increases. Yes, renumbering is _another_ cost. No, not at all. What I am saying is that routers will get a lot bigger regardless of any other influences than current hardware trends. I doubt you could build an IGS now if you wanted to, your hardware design people would tell you it is folly, and not because a small cheap box isn't saleable, because the parts can no longer be guaranteed. Actually, we're making boxes much smaller than the IGS now, both physically and memory wise. See the 1003, for example. At that point they will look for some vendor willing to supply it to them. Now there's no doubt that the straight $ profits from selling these boxes wouldn't make it worth the effort, but if vendor XXX provides this, and the ISP's all stop buying whatever they are buying now, and start buying from XXX instead, then the newspaper, and magazine headlines "Internet switches to XXX routers" just might not be what the old router vendor's management & sales types really want to see. The public relations benefit from supplying the internet core has to be worth orders of magnitude more than the $ profits from the boxes sold there. I think you greatly overestimate the benefits and the risks of such a marketing campaign. Further, you greatly overestimate the extent to which cisco (or anyone else) "holds" the Internet. No, not looking for a job ... but if no-one with suitable hardware is willing to look at implementing this, and no-one will let me have a go at implementing it in their boxes, then proceeding further on specifying it seems pointless. I think I could implement this, it would take me much longer than you to have a go at it and produce something, and the result would be of much lower quality (you wouldn't want to ship it), but I think I could demonstrate it can be done. Just ship me the code to modify... (non disclosure is fine...) Sorry, no source code off-campus. I suspect that if you're after a proof-of-concept, you can do that just fine with your local workstation. To come up to speed on our internals would take you a great deal longer than modifying a system you already know. No, not dynamically assigned, but obtained dynamically from somewhere. And no, I am not really proposing that, just saying that if it could work for a NAT it could also work for mapping. I don't really believe either. They are two wildly different schemes, so I'm confused about the analogy that you're trying to draw. I believe I understand each in isolation. My feelings are based on my implementation experience. That I respect - but I have also seen how much other stuff that has been demanded by the customer base you have been able to make work, and make work fast. Access lists now are much more complex, and much more quickly processed, than the first routers I saw. After a suitable business case was presented. Over time. Access list (filter) processing just has to be more complex than anything I am asking for - and that you can't cache any part of the result for, each packet needs the full treatment. Perhaps. However, you should recall that the hardware was explicitly designed for that task. Your near-immediate deployment leaves no time for such luxuries. You get to fit a square peg into the round hole. I suspect that we still have to push on CIDR very hard. Push hard, just leave that final step. I infer that you mean renumbering. I don't see how we can continue without it given the risk of your scheme failing/not being deployed in time. You can certainly develop and ship, to the Internet core, several versions of anything at all before the end user system people can get even one new generation of anything to be widespread enough to matter. Only if it requires no hardware modifications. I too am in the situation where I cannot prove this without actually trying it. Yes, if our roles were reversed I would have a big advantage, in that I could write the code and try it in my spare time (instead of reading B-I for example...) and see if I could make it work. Yes, except that even that is only proof of implementation. Please realize that the real difficulty occurs not during the implementation and testing of an isolated situation, but when the architecture is actually stressed by deployment. Only then do the cracks really show. Note that this is true for all architectures. To test high level aggregation means actually using it on the net, which means asking people to renumber. And then renumber again, and again - because its going to be when it gets to about the third "you have to renumber" that the customer base is going to decide that enough is enough, even the ones that could renumber once. I'm not convinced that you have to have mandatory renumbering to have hierarchical aggregation. Note that it is perfectly acceptable to have high level aggregation of those sites which happen to fall into the block for the high level region. You can also continue to advertise specific routes for legacy sites. Surely, this is not optimal, but perfect optimality is not a necessity -- just a significant reduction in growth. Tony From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 21:48:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18158; Mon, 28 Aug 1995 21:48:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA15047; Mon, 28 Aug 1995 21:47:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA15043; Mon, 28 Aug 1995 21:45:30 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18077; Mon, 28 Aug 1995 21:45:08 +1000 (from kre@munnari.OZ.AU) Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26308 Mon, 28 Aug 1995 21:31:11 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Mon, 28 Aug 1995 00:07:35 MST." <199508280707.AAA21399@greatdane.cisco.com> Date: Mon, 28 Aug 1995 21:29:30 +1000 Message-Id: <13487.809609370@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Mon, 28 Aug 1995 00:07:35 -0700 From: Tony Li Message-ID: <199508280707.AAA21399@greatdane.cisco.com> Here's a niggling question that has been bothering me: how does one transition onto Robert's scheme without a flag day? Ah yes, my apologies, someone rained that before, though as I recall not in quite such a direct way, and I managed to allow that to slip past, and never sent the message I intended to on that topic. The answer is, very easily, though there is an event sequence that needs to be followed. Perhaps if I explain the sequence, the absence of a flag day will be more obvious than simply asserting that it doesn't exist. Note, this is a logical sequence, some of the steps can be combined and done simultaneously, others, such as developing the new iternal addressing plan (the aggregatable internal addresses inside the core) can be done any time, provided they are ready at the appropriate time - those I omit below. First, all default free exit routers need to be able to handle packets addressed to them that are IP in IP, or IP in whatever is chosen as the underlying protocol, decapsulate them, and route the resulting packet. That may be the case already, I must admit not having attempted to send IP in IP to a router to see what it does with the enclosed packet... Second, all default-free routers need to be able to be configured with a new address (in whatever protocol is chosen as the encapsulating protocol), that they will consider as being "their" addres (one of their addresses) when they receive packets, but will not use as a source address. I suspect that most routers available today can be configured with that info already. Third, all these default free exit routers need to be configured with the addresses that have been allocated to the areas they represent (that may be one address per router, or one address for many routers, depending on all kinds of operational considerations) based on the internal addressing plan that has been developed in the meantime. Some routers may need several of those addresses. Those addresses are aggregated and advertised via BGP into the routing core - and yes, this will increase the size of the default free routing tables for a while, for which reason it would make sense to start with very highly aggregated, and so less than optimally routed, addressing, then as the existing default free routes are withdrawn the degree of aggregation here can be relaxed to improve routing characteristics. Fourth the mapping table needs to be made available, with the mappings from address prefixes to internal addresses. At this point all of the ingredients are available for anyone to switch their router(s) from default routing to encapsulation. Any one router can start. Note that the routers will still need to send traditional BGP style routing info for their local nets until all of the core is converted, but once switched they won't need to process routing info received. Any individual router can switch to encapsulating packets using the mapping table, they will reach the correct exit point and be decapsulated and routed locally. The reverse path may well still be using traditional routing, with a full default free router. When everyone is able to use the mapping scheme, the old default free route advertisments can be turned off completely. No flag days - but sequence points along the way. kre From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 22:42:46 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19725; Mon, 28 Aug 1995 22:42:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26264 Mon, 28 Aug 1995 21:29:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA14991; Mon, 28 Aug 1995 21:27:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA14972; Mon, 28 Aug 1995 21:18:01 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17277; Mon, 28 Aug 1995 21:17:55 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: hal9001@panix.com, big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Sun, 27 Aug 1995 23:55:34 MST." <199508280655.XAA14225@greatdane.cisco.com> Date: Mon, 28 Aug 1995 20:57:24 +1000 Message-Id: <13482.809607444@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sun, 27 Aug 1995 23:55:34 -0700 From: Tony Li Message-ID: <199508280655.XAA14225@greatdane.cisco.com> The point that I was trying to make is that very frequent "hopping" is very unlikely. There are substantial up front costs to changing providers which are well known. For example, if you have a leased line, you have a line installation fee. ... Ah, so you do have a culture difference there. Here to change providers you program a new number in your ISDN call (or calls if you have multiple aggregated B channels). I know this is a comms pricing issue - in Aust there is basically nothing between 48Kbit and 2Mbit, as far as leased lines goes, and both of those are very expensive. Aggregated B channels turn out to be a lot cheaper until the data rate gets quite high (though not as far as the 2Mbit I don't think, if it is being heavily used). 802.6 (I think) switched circuits are another option at the higher end, also simple (though not quite as simple) to switch to a new provider. These people are not dial in two or three host users, entire (relatively large) ISP types connect using this technology, and they certainly have dedicated IP addresses. The only basic costs and impediments they currently have on switching homes are their agreements with their current homes, and any the Internet chooses to impose upon them, like requiring renumbering. kre From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 22:49:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20019; Mon, 28 Aug 1995 22:49:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA15141; Mon, 28 Aug 1995 22:47:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA15137; Mon, 28 Aug 1995 22:40:12 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19645; Mon, 28 Aug 1995 22:40:07 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 28 Aug 1995 05:40:04 -0700 Posted-Date: Mon, 28 Aug 1995 05:37:08 -0700 (PDT) Message-Id: <199508281237.AA19383@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 28 Aug 1995 05:37:13 -0700 Subject: Re: numbering/address spaces To: presotto@plan9.att.com Date: Mon, 28 Aug 1995 05:37:08 -0700 (PDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9508250243.6789@munnari.oz.au> from "presotto@plan9.att.com" at Aug 24, 95 10:22:43 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 821 Precedence: bulk > > > Assume: > - it wants to number its << 16 million SLIP/PPP customers > using its Class A > - a certain NIC told it to use its Class A or give it back. > > What could it do with its Class A address? CIDR would be nice > but it seems meant for aggregating class C's and not for > chunking up a Class A. Does anyone even support CIDR for > Class A's? Multilevel subnetting seems doable using OSPF > but this wastes a good chunk of the space. I also don't > know who supports it. The only reference I found in a > Cisco manual just said 'be careful'. > > Any suggestions? > Two very good answers already. Here is my 0.02. What to do with the Class A? - Give up the idea of ownership. Addresses don't "belong" to anyone. - Return it to the IANA for a better fit. - Keep the delegation and use it. --bill From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 23:08:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20832; Mon, 28 Aug 1995 23:08:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA15186; Mon, 28 Aug 1995 23:07:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA15147; Mon, 28 Aug 1995 22:48:11 +1000 Received: from bodhi.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19945; Mon, 28 Aug 1995 22:46:42 +1000 (from rja@bodhi.cs.nrl.navy.mil) From: Ran Atkinson Message-Id: <9508280840.ZM1572@bodhi.nrl.navy.mil> Date: Mon, 28 Aug 1995 08:40:18 -0400 In-Reply-To: Tony Li "Re: Multi-homed sites" (Aug 25, 23:30) References: <199508260630.XAA29501@greatdane.cisco.com> Reply-To: rja@cs.nrl.navy.mil X-Mailer: Z-Mail (3.2.1 10apr95) To: big-internet@munnari.OZ.AU Subject: Re: Multi-homed sites Cc: Ran Atkinson Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rja@bodhi.cs.nrl.navy.mil Precedence: bulk Tony, Thanks for your note. My goal is more narrow than "solving" the general problem of address aggregation. My goal is providing a reasonable alternative approach for those large sites/campuses that are located near an existing NAP/FIX/CIX/MAE, are multi-homed to different providers, and can't bear the administrative burden of renumbering. I freely admit that it does limit the set of providers such a site could choose from, but limiting to a set is MUCH better than limiting to a single provider (as is currently the case with provider-oriented addresses). No it isn't a panacea. I still think it would be worth experimenting with. I actually doubt that any kind of renumbering is going to solve the multi-homed campus problem. Anyone who thinks multiple addresses per interface (e.g. one per provider) are sensible and reasonable needs to spend more time in campus-sized network/system administration. I also doubt that massive renumbering is going to be as safe and painless as it will need to be to be a general solution. Still, thanks very much for your detailed note. It was educational. :-) Ran rja@cs.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 23:09:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20894; Mon, 28 Aug 1995 23:09:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA15209; Mon, 28 Aug 1995 23:09:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA15180; Mon, 28 Aug 1995 22:55:13 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20142; Mon, 28 Aug 1995 22:55:04 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 28 Aug 1995 05:54:58 -0700 Posted-Date: Mon, 28 Aug 1995 05:52:11 -0700 (PDT) Message-Id: <199508281252.AA19401@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 28 Aug 1995 05:52:12 -0700 Subject: Re: renumbering To: kre@munnari.OZ.AU (Robert Elz) Date: Mon, 28 Aug 1995 05:52:11 -0700 (PDT) Cc: big-internet@munnari.OZ.AU, pier@ISI.EDU In-Reply-To: <12636.809347321@munnari.OZ.AU> from "Robert Elz" at Aug 25, 95 08:42:01 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1232 Precedence: bulk > And it's going to take renumbering to keep [The Internet] > going [until mapping is ready]. Since at that point we've > bitten the bullet, why waste extra energy going backward? > > Renumbering isn't a bullet, its a million bullets, and they keep > being shot out all the time, like forever, until the death of > IPv4. We can probably convince the public to undergo some > renumbering in order to keep the net functioning - the evidence > supports that possibility. However I am not convinced we can > keep doing that (at ever increasing rates - remember exponential > growth) long enough (to the death of IPv4 do us part) that we > can guarantee that we con continue to survive. > > Are you sure that we can keep on renumbering, and renumbering > more, with IPv4, until we no longer need the protocol? > Absolutely sure? > A minor point. I -think- that it is a really good idea to get everyone in the habit of periodic, global renumbering. If we can start them in the habit -now-, then when we get to IPv6, it will be assumed. I think that global, periodic renumbering will extend the life expectancy of IPv4. I don't know if it will be the endall/beall for protocol life expectancy. -- --bill From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 23:12:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20950; Mon, 28 Aug 1995 23:12:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA15260; Mon, 28 Aug 1995 23:12:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA15166; Mon, 28 Aug 1995 22:54:00 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20114; Mon, 28 Aug 1995 22:53:56 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Mon, 28 Aug 1995 01:34:57 MST." <199508280834.BAA24761@greatdane.cisco.com> Date: Mon, 28 Aug 1995 22:53:32 +1000 Message-Id: <13510.809614412@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Mon, 28 Aug 1995 01:34:57 -0700 From: Tony Li Message-ID: <199508280834.BAA24761@greatdane.cisco.com> By "new draconian one", I infer that you mean renumbering and that by "current" you imply the status quo. I mean mandatory renumbering, aka address leasing, and requesting renumbering, where possible, as reportedly is being done now. As I think I said before, we can't prohibit renumbering, if a provider can convice their customers (new or existing) to renumber, that is just fine. By all means they should try to convince people to renumber (now, while it is required), just not require it. As I mentioned in a previous message to someone else, many individual users do change frequently. Much more than that. Our messages have clearly been interspersed here, I won't repeat what I said in the last one on this thread. At least in this part of the world though there is a lot more of this than you think, and no that they remain in Australia doesn't help, Aus has many links into the Internet now, and they all seem to go to different parts of the default free core, to be topologically rational these people would have to renumber. And for the remainder (intermittent connectivity, fixed addresses), This isn't the remainder, there's also permanent (or the equivalent, like IDSN dial on demand) connectivity, with fixed addresses - and cheap (aka free) ability to move the connectivity. they still have to bother people like you to change providers. Only if they have to renumber - if they can keep their numbers and run their own nameservers, the DNS doesn't need to be touched. The ones I see are the ones where the provider runs their DNS, either as primary or secondary, so when they change providers they change at least some of their DNS setup. I suspect this is relatively common, so I may see many of the changes (in the part of the DNS here I maintain, which isn't all of it), but I doubt I see all of them. Last night (after I finished with B-I stuff and was doing DNS) I saw 5 of those, one of which I could still see their previous change in my records. This is a service that someone is providing, Absolutely! and I expect that at some point, folks will get around to distributing that cost. Quite likely - I can see someone doing this more professionally than I do, and charging a fee for these changes. That $20 or $30 or so is going to be a real deterrent! I should also note that many ISPs here have some sort of "setup" fee to cover exactly these costs. Yes, that too - but that's all part of the expected costs you get when you make changes. People expect $ costs in this kind of transaction, that's part of what they take into account when they decide to change - the fees are generally quite small in comparson with other costs. You get the same thing when you buy and sell shares, there are brokerage fees involved, etc - that wouldn't stop you selling shares in order to buy others if you decided that was the best course of action. On the other hand, if you were required to write to every existing shareholder, advising them you were selling your shares, you might find it somewhat more difficult to proceed with this option (esp if they were cisco shares, with large numbers of existing shareholders). You wouldn't find it very reassusing to be told by numbers of brokers that their customers had sold shares in various small enterprises, and had managed to write to all of the shareholders OK... Further, you greatly overestimate the extent to which cisco (or anyone else) "holds" the Internet. "Internet" perhaps, but transformed into "Information Super Highway" and a lot of publicity is generated... Further, my experience has been that a lot of the end user type buyers buy routers on the basis of "what is it that you use?" questions directed at their providers. As long as the costs aren't unreasonable, the benefits of obvious hardware compatability (no finger pointing, etc) tend to push towards buying whatever the service provider uses. Sorry, no source code off-campus. I didn't really expect it. I suspect that if you're after a proof-of-concept, No, that's easy, what I was looking for was to be able to convince you that it could be implemented in your hardware base without costs that are too horrible.] you can do that just fine with your local workstation Believe it or not, that's a Sun 3/50 (yes, really!). I mention this just to show how long ancient systems remain in existence out in the field (no, its not running as an X term, its a "real workstation"). I don't have source code for this one. More, one of my fileservers is a Sun 3/140. I am looking forward to the new code releases from Sun for these things that include all the renumbering technology we need. :-( Push hard, just leave that final step. I infer that you mean renumbering. No, I mean mandatory renumbering - aka address leasing. You can certainly develop and ship, to the Internet core Only if itrequires no hardware modifications. I suspect that a first version of this can be done on existing hardware. Yes, except that even that is only proof of implementation. Yes - I know that real operating experience is needed with any of these schemes to see where the hidden problems are. I'm not convinced that you have to have mandatory renumbering to have hierarchical aggregation. Oh good - please say more. The last time we discusses this, leaving an option for people (even comparatively small users) to avoid renumbering you were of the opinion, I believe, that this would leave things too wide open - there'd be no way to verify they weren't just leaving the work to others, the "someone else can do this, my one number won't hurt" approach. Note that it is perfectly acceptable to have high level aggregation of those sites which happen to fall into the block for the high level region. Sure, the problem is that the topological high level regions really have nothing whatever to do with where users connect. They are just as likely to move between regions you consider to be as far apart as possible, as within one small region. The problem is that no two end-users move the same way, they switch around all over the place. You can also continue to advertise specific routes for legacy sites. I am not worried about those - if anyone should renumber, everyone should. I would be interested in more details of this new, milder, approach. In any case, when the net grows, a pure cidr based approach is necessarily going to have to become more and more strict to maintain agregation levels. I still feel we should be developing al alternative approach that can avoid this requirement. kre From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 23:47:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22334; Mon, 28 Aug 1995 23:47:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA15326; Mon, 28 Aug 1995 23:47:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA15294; Mon, 28 Aug 1995 23:34:25 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21841; Mon, 28 Aug 1995 23:34:20 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 28 Aug 1995 06:34:11 -0700 Posted-Date: Mon, 28 Aug 1995 06:31:25 -0700 (PDT) Message-Id: <199508281331.AA19483@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 28 Aug 1995 06:31:25 -0700 Subject: Re: Benefits of Geographic examples To: asp@uunet.uu.net (Andrew Partan) Date: Mon, 28 Aug 1995 06:31:25 -0700 (PDT) Cc: bsimpson@MorningStar.Com, big-internet@munnari.OZ.AU In-Reply-To: from "Andrew Partan" at Aug 25, 95 06:22:01 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 486 Precedence: bulk > > > So, they have the usual IP number which is _NOT_ under MCI or Sprint, > > and has to be advertised worldwide separately. Hopefully, we can all > > agree that this is bad. > > Why? If every multihomed site (customer or provider) in the world got > a seperate address block, things would work just fine - there are only > 814 of them today. > --asp@uunet.uu.net (Andrew Partan) Er, thats 814 visable to you... right? There are over 6000 of them delegated now. :) -- --bill From owner-Big-Internet@munnari.OZ.AU Mon Aug 28 23:50:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22504; Mon, 28 Aug 1995 23:50:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA15348; Mon, 28 Aug 1995 23:50:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA15308; Mon, 28 Aug 1995 23:43:19 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22235; Mon, 28 Aug 1995 23:43:13 +1000 (from kre@munnari.OZ.AU) To: bmanning@ISI.EDU Cc: big-internet@munnari.OZ.AU, pier@ISI.EDU Subject: Re: renumbering In-Reply-To: Your message of "Mon, 28 Aug 1995 05:52:11 MST." <199508281252.AA19401@zed.isi.edu> Date: Mon, 28 Aug 1995 23:42:49 +1000 Message-Id: <13538.809617369@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Mon, 28 Aug 1995 05:52:11 -0700 (PDT) From: bmanning@ISI.EDU Message-ID: <199508281252.AA19401@zed.isi.edu> If we can start them in the habit -now-, then when we get to IPv6, it will be assumed. For IPv6 I want the practice to be that renumbering can take place without (almost, or ideally absolutely) anyone at all at the end user even knowing it has happened (without actually looking for it - if you query the DNS for your own address every hour you would see it). There is a lot of work to do before IPv6 is ready for that, but that is what we should be aiming for. If we could (somehow) make renumnbering in IPv4 possible without anyone knowing it had happened, then I would be all I favour of it. I just dont' see that being possible, however good a job the pier group does. kre ps: Bill, please check if I am on that list, I have seen no evidence of it yet, and I did send a subscribe request. From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 00:47:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25067; Tue, 29 Aug 1995 00:47:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA15557; Tue, 29 Aug 1995 00:47:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA15534; Tue, 29 Aug 1995 00:38:07 +1000 Received: from news.ti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24646; Tue, 29 Aug 1995 00:37:55 +1000 (from w-rolph@ds.mc.ti.com) Received: from ganesh.mc.ti.com ([157.87.4.175]) by gate.ti.com (8.6.12/) with SMTP id JAA09429; Mon, 28 Aug 1995 09:37:37 -0500 Received: by ganesh.mc.ti.com; id AA17612; Mon, 28 Aug 1995 10:35:10 -0400 Message-Id: <9508281435.AA17612@ganesh.mc.ti.com> X-Sender: a722756@mail-ad.mc.ti.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 10:35:25 -0400 To: bmanning@isi.edu, kre@munnari.OZ.AU (Robert Elz) From: "W. Donald Rolph III" Subject: Re: renumbering Cc: big-internet@munnari.OZ.AU, pier@isi.edu Precedence: bulk >> Renumbering isn't a bullet, its a million bullets, and they keep >> being shot out all the time, like forever, until the death of >> IPv4. We can probably convince the public to undergo some >> renumbering in order to keep the net functioning - the evidence >> supports that possibility. However I am not convinced we can >> keep doing that (at ever increasing rates - remember exponential >> growth) long enough (to the death of IPv4 do us part) that we >> can guarantee that we con continue to survive. >> > A minor point. I -think- that it is a really good idea > to get everyone in the habit of periodic, global renumbering. > > If we can start them in the habit -now-, then when we > get to IPv6, it will be assumed. > > I think that global, periodic renumbering will extend the > life expectancy of IPv4. I don't know if it will be > the endall/beall for protocol life expectancy. > >-- >--bill > > I guess I demure vociferously. If we force the user community to renumber (unless it is totally transparent to them) then the internet is doomed. I reiterate. What ever happens must happen at the gateways, and make the addressing issues invisible to the end user. It may mean we give up the ability to use numerical IP addresses for end user access outside the local environment. That is an acceptable price, I would argue. To force the end user to reconfigure regularly is physically impossible, and will I assert guarantee failure of the internet. Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-236-1263 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 01:07:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26044; Tue, 29 Aug 1995 01:07:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA15604; Tue, 29 Aug 1995 01:07:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA15579; Tue, 29 Aug 1995 00:51:13 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25142; Tue, 29 Aug 1995 00:51:06 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01808 Tue, 29 Aug 1995 00:50:54 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.58] ([204.247.5.26]) by aimnet.com (8.6.12/8.6.12) with SMTP id HAA17884; Mon, 28 Aug 1995 07:48:43 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 07:49:32 -0700 To: Robert Elz From: Dave Crocker Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 4:29 AM 8/28/95, Robert Elz wrote: > Here's a niggling question that has been bothering me: how does one > transition onto Robert's scheme without a flag day? .. >The answer is, very easily, though there is an event sequence This is intended to be compatible with Robert's excellent response but I thought a brief version might be helpful: An NDZ router uses Encaps when it finds a destination address listed in the mapping table. The entry will only be there if the final NDZ router supports decapsulation. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 01:10:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26114; Tue, 29 Aug 1995 01:10:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA15632; Tue, 29 Aug 1995 01:10:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA15593; Tue, 29 Aug 1995 00:57:48 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25503; Tue, 29 Aug 1995 00:57:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23658; Mon, 28 Aug 95 10:57:35 -0400 Date: Mon, 28 Aug 95 10:57:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508281457.AA23658@ginger.lcs.mit.edu> To: bmanning@isi.edu, kre@munnari.OZ.AU Subject: Re: renumbering Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, pier@isi.edu Precedence: bulk From: Robert Elz For IPv6 I want the practice to be that renumbering can take place without .. anyone at all at the end user even knowing it has happened ... If we could .. make renumnbering in IPv4 possible ... I just dont' see that being possible Why do you feel it will be impossible? Is it just the massive amount of deployed stuff that assumes addresses will be constant? Are there some features of IPv6 that we will never, ever be able to transplant into IPv4, such as local addresses (serverless autoconfiguration we can perhaps add using an Appletalk-like challenge scheme)? The reason your statement interests me should be obvious: I feel that one of the things about IPv4 that will make invisible renumbering hard is the poor choice of namespaces, and the use of the routing namespace for endpoint naming. However, I don't see that IPv6 is really any different in this regard (at least, yet, anyway). Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 01:13:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26199; Tue, 29 Aug 1995 01:13:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA15660; Tue, 29 Aug 1995 01:13:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA15599; Tue, 29 Aug 1995 01:07:01 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26010; Tue, 29 Aug 1995 01:06:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23711; Mon, 28 Aug 95 11:06:31 -0400 Date: Mon, 28 Aug 95 11:06:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508281506.AA23711@ginger.lcs.mit.edu> To: bmanning@isi.edu, kre@munnari.OZ.AU, w-rolph@ds.mc.ti.com Subject: Re: renumbering Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, pier@isi.edu Precedence: bulk From: "W. Donald Rolph III" If we force the user community to renumber (unless it is totally transparent to them) then the internet is doomed. This statement may be true. It is, however, also true (in the mathematical sense) that the namespace used by the routing must be one where the abstraction hierarchy can be adjusted over time, to match the changing topology. I don't know, quite, how this irresistable force, and immovable object above, are to be prevented from colliding. Perhaps we can make the renumbering totally transparent to the users. Perhaps we will need two different namespaces. I just don't know. However, I can guarantee you that the names used by the routing will have to change over time. I'm not sure how automatic this can be, for reasons that are perhaps beyond the scope of this mailing list (and certainly beyond my patience to write down, as it would be a long explanation and I don't have the time or energy right now). To force the end user to reconfigure regularly is physically impossible, and will I assert guarantee failure of the internet. I do not ask this sarcastically, but quite seriously: what ideas do you have on how to avoid this? Do you think we can renumber in a way which is totally invisible to the users (if not to everyone, see above)? Failing that, will we need a second namespace? If so, can that second namespace be DNS names, or must it be something else? Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 01:28:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26914; Tue, 29 Aug 1995 01:28:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA15704; Tue, 29 Aug 1995 01:27:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA15698; Tue, 29 Aug 1995 01:25:22 +1000 Received: from foobar.Ipsilon.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26720; Tue, 29 Aug 1995 01:25:19 +1000 (from hinden@ipsilon.com) Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id IAA26492; Mon, 28 Aug 1995 08:24:30 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 08:27:25 -0700 To: "Brian Carpenter CERN-CN" From: hinden@Ipsilon.COM (Bob Hinden) Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU (bigi) Precedence: bulk Brian, >Win95 ships with PPP and with SLIP as an easy add-on (there even >seems to be a free version). It also has DHCP and WinNT has a >functional DHCP server. Correct. >Win95 systems will mainly get their IP addresses dynamically, >whichever ISP they connect to. PPP has dealt with dynamic addresses for some time now. I would think that DHCP will be used inside of a site not from a dialup ISP. So there still has to be a site wide renumbering. I had thought that the address assignment in DHCP was mostly focused on giving a new host an address. I am not sure how it would be used (w/ IPv4) to renumber. For example if the DHCP server was renumbered (it's own address) how would it's client hosts talk to it to renumber? Does it have to be renumbered last? If so, do the renumbered hosts loose contact with it? Then there are all the issues with DNS updating, caching, etc. >I own no shares in Microsoft. Me either :-) Bob From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 01:31:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27007; Tue, 29 Aug 1995 01:31:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA15726; Tue, 29 Aug 1995 01:31:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA15614; Tue, 29 Aug 1995 01:09:07 +1000 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26072; Tue, 29 Aug 1995 01:09:01 +1000 (from swb1@cornell.edu) Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id LAA07678 for ; Mon, 28 Aug 1995 11:08:58 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 11:09:19 -0400 To: big-internet@munnari.OZ.AU From: Scott W Brim Subject: Re: 1. core; 2. conformance Precedence: bulk At 13:44 08/26/95, Greg Minshall wrote: >Metro addressing, on the other hand, says "we would like to put some >constraints on the *topology*, and how it will evolve, such that it will >continue to, in the main, conform to the *addressing*; we will thus gaze into >our crystal ball and determine some set of constraints that will accomplish >our goal." There are constraints that something must not take place and constraints that something must take place. Noel says metro addressing requires topology constraints but these are two very different categories. The former, which is what you would usually think of given the word "constraint", is very hard to guarantee. Luckily metro addressing falls in the second category, in that it requires some sort of connectivity between providers within a metro area. In the days since Steve first tossed out his metro addressing idea we've had plenty of practice with this, and it shouldn't be daunting anymore. All the providers have created exchange points and know how to talk to each other. It's almost routine. ...Scott From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 01:34:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27066; Tue, 29 Aug 1995 01:34:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA15748; Tue, 29 Aug 1995 01:34:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA15684; Tue, 29 Aug 1995 01:23:15 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26621; Tue, 29 Aug 1995 01:23:05 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzeth02778; Mon, 28 Aug 1995 11:17:46 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: renumbering To: w-rolph@ds.mc.ti.com (W. Donald Rolph III) Date: Mon, 28 Aug 1995 11:17:46 -0400 (EDT) Cc: bmanning@isi.edu, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU, pier@isi.edu In-Reply-To: <9508281435.AA17612@ganesh.mc.ti.com> from "W. Donald Rolph III" at Aug 28, 95 10:35:25 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1271 Precedence: bulk > I guess I demure vociferously. If we force the user community to renumber > (unless it is totally transparent to them) then the internet is doomed. The problem is that the Intenret' routing tables are growing too fast. The number of routes is getting to be too large for some routers to hold already today (and has exceeded it in some cases), and the number of route flaps is also getting very large. We need to figure out how to exponentially grow the Internet (doubling time is something on the order of 5-9 months) without exponentially growing things like the routing table and the number of route flaps. Route flaps (with the bgp route dampening work) is probably handled (time will tell), but route tables are not. We need to figure out how to do this & do it soon. Renumbering sites into more aggregatable routes is one way that works. We know how to make it work & we know how to make it work today. Other methods (NAT, Robert's ideas) are not there yet. They may be there in the future, they may not be. We have to do something now (& if we figure out how to do something better later, so much the better). Continuing our current course of adding routes at random will break the Internet. How do you want to die? --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 01:50:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27870; Tue, 29 Aug 1995 01:50:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA15790; Tue, 29 Aug 1995 01:47:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA15754; Tue, 29 Aug 1995 01:34:59 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27078; Tue, 29 Aug 1995 01:34:49 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch id AA19063; Mon, 28 Aug 1995 17:34:09 +0200 Received: by dxcoms.cern.ch id AA03341; Mon, 28 Aug 1995 17:34:07 +0200 Message-Id: <9508281534.AA03341@dxcoms.cern.ch> Subject: PLEASE Re: renumbering To: big-internet@munnari.OZ.AU Date: Mon, 28 Aug 1995 17:34:07 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9508281506.AA23711@ginger.lcs.mit.edu> from "Noel Chiappa" at Aug 28, 95 11:06:31 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 541 Precedence: bulk PLEASE PLEASE take pier out of the header on this thread! Save my brain from frying with N copies of this old, old argument. I have work to do, figuring out how to renumber my site, and I look forward to constructive discussion of that on pier, while dead horses are flogged over on big-internet. Thank you Brian > > If we force the user community to renumber (unless it is totally > transparent to them) then the internet is doomed. > > This statement may be true. It is, however, also true (in the mathematical ...... From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 01:56:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28067; Tue, 29 Aug 1995 01:56:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA15832; Tue, 29 Aug 1995 01:56:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA15784; Tue, 29 Aug 1995 01:45:41 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27602; Tue, 29 Aug 1995 01:45:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23883; Mon, 28 Aug 95 11:44:10 -0400 Date: Mon, 28 Aug 95 11:44:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508281544.AA23883@ginger.lcs.mit.edu> To: asp@uunet.uu.net, w-rolph@ds.mc.ti.com Subject: Re: renumbering Cc: big-internet@munnari.OZ.AU, bmanning@isi.edu, jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU, pier@isi.edu Precedence: bulk From: asp@uunet.uu.net (Andrew Partan) Renumbering sites into more aggregatable routes is one way that works. We know how to make it work & we know how to make it work today. Other methods (NAT, Robert's ideas) are not there yet. May I point out that NAT's (along with all the other similar solutions, such as Transport-Layer-Gateways - e.g. SOCKS - and Application Layer Gateways) do not in fact *replace* aggregable routes, just make them more palatable by avoiding the necessity of renumbering all the user hosts. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 03:09:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00817; Tue, 29 Aug 1995 03:09:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA15976; Tue, 29 Aug 1995 03:07:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA15964; Tue, 29 Aug 1995 03:01:32 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00456; Tue, 29 Aug 1995 03:01:30 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03490 Tue, 29 Aug 1995 02:25:34 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzetl17143; Mon, 28 Aug 1995 12:23:01 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Benefits of Geographic examples To: bmanning@ISI.EDU Date: Mon, 28 Aug 1995 12:23:01 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199508281331.AA19483@zed.isi.edu> from "bmanning@ISI.EDU" at Aug 28, 95 06:31:25 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 228 Precedence: bulk > Er, thats 814 visable to you... right? > There are over 6000 of them delegated now. :) If you look at all BGP routes today, you only see some 800 ASs in real use (on the global Internet). --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 03:18:04 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01345; Tue, 29 Aug 1995 03:18:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03290 Tue, 29 Aug 1995 02:10:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA15860; Tue, 29 Aug 1995 02:07:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA15810; Tue, 29 Aug 1995 01:54:55 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27997; Tue, 29 Aug 1995 01:54:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23902; Mon, 28 Aug 95 11:54:36 -0400 Date: Mon, 28 Aug 95 11:54:36 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508281554.AA23902@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, swb1@cornell.edu Subject: Re: 1. core; 2. conformance Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Scott W Brim There are constraints that something must not take place and constraints that something must take place. I fail to see the difference, but let's not get buried in philosophy. metro addressing ... requires some sort of connectivity between providers within a metro area. In the days since Steve first tossed out his metro addressing idea we've had plenty of practice with this, and it shouldn't be daunting anymore. All the providers have created exchange points and know how to talk to each other. Ah. So, tell me, how does a system which uses metro-addressing respond when a provider loses its link to a given metro-exchange? Metro addressing also implies a constant two levels of hierarchy, to the level of the individual subscriber (unless you have more topology constraints than the one you have listed); is such a two level hierarchy going to be enough? I'll leave aside (for now) other points, as well as a number of practical points, such as i) the need for more as yet undefined mechanism, at least for metro-addressing a la Steve, such as the mapping between subscriber id and provider, and ii) the fact that to deploy it everyone will have to renumber. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 03:18:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01357; Tue, 29 Aug 1995 03:18:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16011; Tue, 29 Aug 1995 03:16:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA15961; Tue, 29 Aug 1995 03:01:28 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00450; Tue, 29 Aug 1995 03:01:26 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03360 Tue, 29 Aug 1995 02:16:33 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzetk15212; Mon, 28 Aug 1995 12:13:17 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: renumbering To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 28 Aug 1995 12:13:17 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9508281544.AA23883@ginger.lcs.mit.edu> from "Noel Chiappa" at Aug 28, 95 11:44:10 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 455 Precedence: bulk > May I point out that NAT's (along with all the other similar solutions, such > as Transport-Layer-Gateways - e.g. SOCKS - and Application Layer Gateways) do > not in fact *replace* aggregable routes, just make them more palatable by > avoiding the necessity of renumbering all the user hosts. This is true - thanks. This is renumbering a site by hiding the addresses that they really are using. If sites can use these methods, I'm all for it. --asp From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 03:18:08 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01351; Tue, 29 Aug 1995 03:18:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03336 Tue, 29 Aug 1995 02:14:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA15893; Tue, 29 Aug 1995 02:11:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA15836; Tue, 29 Aug 1995 01:56:32 +1000 Received: from news.ti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28057; Tue, 29 Aug 1995 01:56:25 +1000 (from w-rolph@ds.mc.ti.com) Received: from ganesh.mc.ti.com ([157.87.4.175]) by gate.ti.com (8.6.12/) with SMTP id KAA12658; Mon, 28 Aug 1995 10:56:02 -0500 Received: by ganesh.mc.ti.com; id AA22564; Mon, 28 Aug 1995 11:53:47 -0400 Message-Id: <9508281553.AA22564@ganesh.mc.ti.com> X-Sender: a722756@mail-ad.mc.ti.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 11:53:48 -0400 To: asp@uunet.uu.net (Andrew Partan) From: "W. Donald Rolph III" Subject: Re: renumbering Cc: bmanning@isi.edu, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU, pier@isi.edu Precedence: bulk At 11:17 AM 8/28/95 -0400, Andrew Partan wrote: >> I guess I demure vociferously. If we force the user community to renumber >> (unless it is totally transparent to them) then the internet is doomed. > >The problem is that the Intenret' routing tables are growing too fast. >The number of routes is getting to be too large for some routers to >hold already today (and has exceeded it in some cases), and the number >of route flaps is also getting very large. >Continuing our current course of adding routes at random will break the >Internet. > >How do you want to die? > --asp@uunet.uu.net (Andrew Partan) > > I guess as the first step, I challenge the assumptions behind continued doubling. No exponential process grows forever, and we have, as I understand it, about one doubling left with present technology. Again, I am not an internals guru, but I believe the assumption of continued doubling forever needs to be examined. Second, as mentioned before, I have no problem with drastic surgery at the external gateways from given environments. If we posit giving up direct numeric IP addressing by the end users (a design freedom I believe we have), then remapping of numeric IP addresses can occur at the boundary gateways, trans parent to the internal user. I am not positing that we give up renumbering (or its logical analogy), I am positing that we can not accept as a design freedom that we will change the IP address encoded on the end users machines. Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-236-1263 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 03:22:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01511; Tue, 29 Aug 1995 03:22:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16035; Tue, 29 Aug 1995 03:20:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA15970; Tue, 29 Aug 1995 03:02:14 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00530; Tue, 29 Aug 1995 03:02:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03455 Tue, 29 Aug 1995 02:22:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24097; Mon, 28 Aug 95 12:20:21 -0400 Date: Mon, 28 Aug 95 12:20:21 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508281620.AA24097@ginger.lcs.mit.edu> To: kre@munnari.OZ.AU, tli@cisco.com Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz I mention this just to show how long ancient systems remain in existence out in the field ... I don't have source code for this one. ... I am looking forward to the new code releases from Sun for these things that include all the renumbering technology we need. :-( I would suggest things such as NAT's as perhaps the easiest way to deal with legacy systems. In fact, for all sites which don't want to go through the pain of renumbering (which we are continually told is a lot of sites), NAT, SOCKS, etc all form attractive options. (Hmmm. Can anyone send me the names of companies which sell these products? Speaking of brokers.... I'm quite serious.) > I'm not convinced that you have to have mandatory renumbering > to have hierarchical aggregation. leaving an option for people (even comparatively small users) to avoid renumbering ... there'd be no way to verify they weren't just leaving the work to others, the "someone else can do this, my one number won't hurt" approach. If we charged for advertising routes, this would all work fine. The larger a scope your address had to be advertised over (because you were too lazy to renumber, or because you wanted multi-homing, or whatever), the more it would cost you. That would serve as a built-in incentive to renumber as your addresses got too far out of tune. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 03:24:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01709; Tue, 29 Aug 1995 03:24:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16057; Tue, 29 Aug 1995 03:23:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA15967; Tue, 29 Aug 1995 03:02:02 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00464; Tue, 29 Aug 1995 03:01:44 +1000 (from evanw@sabine.us.dell.com) Received: from sabine.us.dell.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03410 Tue, 29 Aug 1995 02:19:24 +1000 (from evanw@sabine.us.dell.com) Received: from localhost (evanw@localhost) by sabine.us.dell.com (8.6.5/8.6.5) id LAA13625; Mon, 28 Aug 1995 11:10:45 -0500 From: Evan Wetstone Message-Id: <199508281610.LAA13625@sabine.us.dell.com> Subject: Re: IP Encapsulation Growth Proposal To: hinden@Ipsilon.COM (Bob Hinden) Date: Mon, 28 Aug 1995 11:10:45 -0500 (CDT) Cc: brian@dxcoms.cern.ch, big-internet@munnari.OZ.AU In-Reply-To: from "Bob Hinden" at Aug 28, 95 08:27:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1895 Precedence: bulk > Brian, > > >Win95 ships with PPP and with SLIP as an easy add-on (there even > >seems to be a free version). It also has DHCP and WinNT has a > >functional DHCP server. > > Correct. > > >Win95 systems will mainly get their IP addresses dynamically, > >whichever ISP they connect to. > > PPP has dealt with dynamic addresses for some time now. I would think that > DHCP will be used inside of a site not from a dialup ISP. So there still > has to be a site wide renumbering. > > I had thought that the address assignment in DHCP was mostly focused on > giving a new host an address. I am not sure how it would be used (w/ IPv4) > to renumber. For example if the DHCP server was renumbered (it's own > address) how would it's client hosts talk to it to renumber? Does it have > to be renumbered last? If so, do the renumbered hosts loose contact with > it? The server being renumbered would not be a great problem. Hosts try to renew their lease by sending unicast packets to the server that assigned them the address at 50% of the lease time. If no answer is given, the host is supposed to send a broadcast to all servers at 85% of the lease time. This should deal with the renumbering of the server. Unfortunately, DHCP is not going to help us with the major problem we would face with renumbering. Our major problem will be our large legacy systems that have had their IP addresses hardcoded in client applications. I know this is bad, and I've told others (many times) that this is bad. The fact remains that the addresses are there, and I can not renumber those machines without bringing the entire organization to a halt. And that's unacceptable. -- Evan Wetstone evanw@dell.com "Next week, a doctor with a flashlight shows us where sales projections come from." -- Dilbert 12/18/94 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 03:28:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB01773; Tue, 29 Aug 1995 03:28:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16087; Tue, 29 Aug 1995 03:27:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA15945; Tue, 29 Aug 1995 02:50:37 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29688; Tue, 29 Aug 1995 02:50:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24308; Mon, 28 Aug 95 12:50:31 -0400 Date: Mon, 28 Aug 95 12:50:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508281650.AA24308@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, rja@cs.nrl.navy.mil Subject: Re: Multi-homed sites Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Ran Atkinson My goal is providing a reasonable alternative approach for those large sites/campuses that are located near an existing NAP/FIX/CIX/MAE, are multi-homed to different providers, and can't bear the administrative burden of renumbering. I freely admit that it does limit the set of providers such a site could choose from, but limiting to a set is MUCH better than limiting to a single provider (as is currently the case with provider-oriented addresses). This shows exactly why the use of the term "provider-based addressing" is wrong (and, moreover, displays the shallow technical grip of those who push use of it). To the extant that you are proposing a connection to an interconnect, and an interconnect-based address, that is *exactly* a "topology-based address", and is fine with me. (Of course, one can view the interconnect as the "provider"....) It is true that the routing overhead of such a "interconnect-based address" is going to be a *little* higher than one which is relative to given provider, since it will have to be advertised over a somewhat wider scope than the latter. However, it is still a rather restricted scope (assuming rational address allocation), and will have no impact on most of the "non-default" (i.e. non-stub, with certain exceptions) routers in the rest of the Internet. Also, since presumably many customers will share the interconnect, and this the routign overhead of that entry, the individual overhead will be quite low. This may appear similar to geographic addressing, but it's quite different. It only says "if you connect to this point in the topology, you can have a fixed address", which is a very different statement. The only hitch I can see with it is that to the extent that major providers attach to many, many different interconnects, it makes no sense to try and group those providers' networks inside a single exchange's "circle" (i.e. abstraction naming boundary, to be technical). You can go several ways: i) you can split a provider's mesh up, so that different bits are associated with different topology aggregates (which is effectiuvely what geographic addresing does), ii) you can allow the circles to overlap (ech, multiple addresses), or iii) you make the major providers topological agggregates of their own, appearing in the abstraction hierarchy at the same level at which the exchanges appear. I suspect iii) is the most palatable. I would imagine that one way this all would work in practise is that each customer would arrange with one or more of the providers who touch an interconnect to carry their traffic. The customer's router would then contain routing tables set up to use those providers. The other alternative would be for the traffic from the interconnect to be shared by the all the providers, on a "best-exit-router" basis. A customer would pay a fee to the "interconnect", which would be split up among the providers. Of course, this all assumes you connect directly to the interconnect (or to providers which are numbered out of that interconnect address space). If you want to connect *only* to a number of large providers, and *appear* to be connected to an interconnect, you run into some problems, depending on what you did about the paragraph above about large providers. For one, each provider to which you are attached will have to have a route (with scope probably their network) which directs traffic to your site to the place it is actually connected. Also, they will have to be attached to the interconnect (or connected to one which is, thus increasing the scope over which your route has to be known). Also, since people cannot reach you directly through the interconnect, traffic may take very non-optimal paths by going there first to get to one of the providers which does connect to you. These (and more) are all consequnces of the fact that your address is no longer topology-based. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 03:49:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02648; Tue, 29 Aug 1995 03:49:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16129; Tue, 29 Aug 1995 03:48:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA16111; Tue, 29 Aug 1995 03:31:53 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01906; Tue, 29 Aug 1995 03:31:48 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24604; Mon, 28 Aug 95 13:31:46 -0400 Date: Mon, 28 Aug 95 13:31:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508281731.AA24604@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, evanw@sabine.us.dell.com Subject: Re: IP Encapsulation Growth Proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Evan Wetstone Our major problem will be our large legacy systems that have had their IP addresses hardcoded in client applications. ... I can not renumber those machines without bringing the entire organization to a halt. And that's unacceptable. Clearly. However, would NAT boxes, SOCKS, etc (all available technology) work to support those machines? Do they even need to talk to the rest of the Internet? Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 03:51:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02710; Tue, 29 Aug 1995 03:51:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA16151; Tue, 29 Aug 1995 03:51:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA16125; Tue, 29 Aug 1995 03:41:07 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02327; Tue, 29 Aug 1995 03:40:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24691; Mon, 28 Aug 95 13:40:52 -0400 Date: Mon, 28 Aug 95 13:40:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508281740.AA24691@ginger.lcs.mit.edu> To: kre@munnari.OZ.AU, tli@cisco.com Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz the absence of a flag day will be more obvious than simply asserting that it doesn't exist. True, there is no flag day (I can't imagine anyone would try and suggest a scheme which had one, it's clearly impossible with a system of this sized), but the hitch comes at the end of your note: routers will still need to send traditional BGP style routing info for their local nets until all of the core is converted ... When everyone is able to use the mapping scheme, the old default free route advertisments can be turned off completely. In other words, i) until this new stuff is widely deployed, everyone has to keep going with the (exploding) current tables, and ii) people who don't switch over to the new system get stuck with the current tables (or can get converted into a stub). all default free exit routers need to be able to handle packets [in the] underlying protocol, decapsulate them, and route the resulting packet. That may be the case already, I must admit not having attempted to send IP in IP to a router to see what it does with the enclosed packet... Well, there's an Experimental spec for an encapsulation protocol (RFC-1241), but I'm not sure it's widely supported. There's also GRE (RFC's 1701, 1702), ditto. Also, the MBone uses encapsulation, but I'm not sure of the details. So I doubt this is actually an availble piece. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 04:08:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03500; Tue, 29 Aug 1995 04:08:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA16190; Tue, 29 Aug 1995 04:07:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA16184; Tue, 29 Aug 1995 04:05:49 +1000 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03270; Tue, 29 Aug 1995 04:05:39 +1000 (from swb1@cornell.edu) Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id OAA11123 for ; Mon, 28 Aug 1995 14:05:36 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 14:05:58 -0400 To: big-internet@munnari.OZ.AU From: Scott W Brim Subject: Re: Discussing encap/mapping proposal Precedence: bulk A major reason not to mandate provider-based addressing is that multihoming between providers will have to be seriously discouraged, and I find this as unacceptable as others. Multi-homing with multiple providers is critical and fundamental to the health of the Internet. This isn't for some architectural reason or for economics, or whatever. The fact is that the way the providers work these days they just don't satisfy the users' needs for quality connectivity. Therefore, KRE's "intra-core" (define "core" as the routers within the area where the higher-level addressing is used) address prefixes should refer to chunks that are large enough that "most" multi-homing would take place within them, so multi-homing will not cause extra "higher-level" routes to be propagated across the "core", and also so that this "intra-core" addressing and topology have something to do with each other. I suspect the size of this chunk will need to be on the order of half a continent or so -- anything smaller and most multi-homing would be done between chunks, and KRE's scheme would do little good to reduce the number of entries in "core" routers. However, would this be small enough granularity to be worth it? Would the reduction of the problem by about an order of magnitude, by localizing it within half-continents, be enough? I don't think so. On another topic, I assume the router vendors are all at least poking at IPv6, and IPv6-IPv4 interworking. *If* KRE's scheme goes forward, perhaps we could use some of the ideas generated and soundly criticized in 2 years of IPv6 transition planning, instead of some new one-shot encapsulation scheme? Could the "core" use IPv6 and not some quick single-use encapsulation? That way the vendors could actually benefit from developing this capability. ...Scott From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 04:29:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04451; Tue, 29 Aug 1995 04:29:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA16243; Tue, 29 Aug 1995 04:27:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA16196; Tue, 29 Aug 1995 04:08:25 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03512; Tue, 29 Aug 1995 04:08:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25017; Mon, 28 Aug 95 14:08:14 -0400 Date: Mon, 28 Aug 95 14:08:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508281808.AA25017@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: current MAE East losses Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "William Allen Simpson" I believe that KRE's proposal would alleviate this congestion, because it would provide a better human managed view of the actual topology, rather than the nearly all default routing we get now. I expect that people are using the "nearly all default" routing since the addresses currently used by the routing are allocated so poorly (i.e. without respect to topology), it's not possible to have any non-default routing without having to have the full table. Now, it could be that this is all because of the amazingly badly managed RADB, as Sean claims. Or it could be that some providers aren't _using_ the RADB and propagating it properly, as others claim. I fail to see how the RADB can be causing congestion directly, and as to your supposition that the congestion is caused by too much traffic going over default (non-optimal) paths, since the AS numbers have been allocated randomly, a routing system based on AS numbers is going to present the same problem of needing a full table as the only alternative to default. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 04:49:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05255; Tue, 29 Aug 1995 04:49:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA16313; Tue, 29 Aug 1995 04:47:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA16275; Tue, 29 Aug 1995 04:34:30 +1000 Received: from sabine.us.dell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04530; Tue, 29 Aug 1995 04:34:19 +1000 (from evanw@sabine.us.dell.com) Received: from localhost (evanw@localhost) by sabine.us.dell.com (8.6.5/8.6.5) id NAA16909; Mon, 28 Aug 1995 13:25:15 -0500 From: Evan Wetstone Message-Id: <199508281825.NAA16909@sabine.us.dell.com> Subject: Re: IP Encapsulation Growth Proposal To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 28 Aug 1995 13:25:14 -0500 (CDT) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9508281731.AA24604@ginger.lcs.mit.edu> from "Noel Chiappa" at Aug 28, 95 01:31:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 442 Precedence: bulk > Clearly. However, would NAT boxes, SOCKS, etc (all available technology) work > to support those machines? Do they even need to talk to the rest of the > Internet? True, NAT boxes, SOCKS, etc. will work in this situation. -- Evan Wetstone evanw@dell.com "Next week, a doctor with a flashlight shows us where sales projections come from." -- Dilbert 12/18/94 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 04:53:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05366; Tue, 29 Aug 1995 04:53:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA16337; Tue, 29 Aug 1995 04:51:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA16245; Tue, 29 Aug 1995 04:28:13 +1000 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04399; Tue, 29 Aug 1995 04:28:07 +1000 (from swb1@cornell.edu) Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id OAA16143; Mon, 28 Aug 1995 14:28:03 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 14:28:25 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Scott W Brim Subject: Re: Comments on draft-ietf-cidrd-ownership-01.txt Cc: big-internet@munnari.OZ.AU Precedence: bulk At 03:24 08/24/95, Noel Chiappa wrote: >You appear to have missed the distinction between a hierarchical topology, and >an address hierarchy. One can apply hierarchical addressing to a perfectly >regular topology, e.g. a North-East-West-South mesh in which each node has >precisely four neighbours. (True, one doesn't need full-blown dynamic routing >for that case, but it's a useful test case.) This disproves your implicit >suggestion that one cannot use hierarchical routing in a network which does >not have a hierarchical topology. Noel, would you agree that hierarchical addressing constrains the use of the topology to be hierarchical? If the topology includes connections which are not represented in the addressing hierarchy which is chosen, the address hierarchy will lead to some links not being used, unless extra routing information is added? Specifically in this case, if I have address space which is a suballocation from one provider, then any connection to another provider will not be used unless extra information about my bit of the address space is propagated in addition. But fundamentally I think you're presenting a red herring in this paragraph, since regardless of the underlying topology, addressing forces a pattern of use of the topology, and hierarchical addressing forces hierarchical use of the topology. That's why multi-homing is an issue, and why geographic addressing of any sort has started to look pretty good again (like Nixon, in his day). Addressing, and topology use, are hierarchical. If addressing is provider-based then multi-homing between providers causes details to be propagated over far too much of the topology. If addressing is geographical (with interconnects in metro areas) then multi-homing between geographical areas causes details to be propagated too far. Perhaps we didn't make decent predictions the last time this was debated. At this point, though, it looks like a large number of organizations want to (indeed, must, for business reasons) multi-home between providers, but that fewer of them, basically the large providers and some large corporations, want to multi-home at more than one geographic area. At 11:54 08/28/95, Noel Chiappa wrote: >Ah. So, tell me, how does a system which uses metro-addressing respond when a >provider loses its link to a given metro-exchange? Metro addressing also >implies a constant two levels of hierarchy, to the level of the individual >subscriber (unless you have more topology constraints than the one you have >listed); is such a two level hierarchy going to be enough? The same way the current Internet responds when a provider loses a connection to a multi-homed organization -- to the extent that routing supports it, the other providers take the traffic. >I'll leave aside (for now) other points, as well as a number of practical >points, such as i) the need for more as yet undefined mechanism, at least for >metro-addressing a la Steve, such as the mapping between subscriber id and >provider, and ii) the fact that to deploy it everyone will have to renumber. The first is straightforward, the second is a problem which could be addressed with IPv6 deployment. I don't claim that metro addressing is a perfect solution for anything. I look forward to the dawn of the new architecture (nimrod, yay). I just find the recently-uncovered implications of the provider-based scheme to be unacceptable, and that we've had some experience which would make geographic addressing easier to deploy as a medium-term strategy now than 2 years ago (or was it 3?). ...Scott From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 05:09:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06065; Tue, 29 Aug 1995 05:09:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA16382; Tue, 29 Aug 1995 05:07:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA16372; Tue, 29 Aug 1995 04:59:42 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05550; Tue, 29 Aug 1995 04:59:39 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id OAA12003 for ; Mon, 28 Aug 1995 14:59:34 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id OAA04827 for ; Mon, 28 Aug 1995 14:59:38 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA23714; Mon, 28 Aug 95 14:46:33 EDT Message-Id: <9508281846.AA23714@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 14:35:25 -0400 To: Dave Crocker From: Robert Moskowitz Subject: Re: firewalls and data integrity Cc: big-internet@munnari.OZ.AU Precedence: bulk At 02:21 PM 8/25/95 -0700, Dave Crocker wrote: >Bob, > >>> With the advent of firewalls/proxies, we've just violated that >>>basis. Those files WILL eventually come across corrupted. I said WILL, >>>not maybe. >> >>Dave, having done this a lot already, I do not agree with this. >> >>The proxy process for an FTP is basically a byte pipe. Bytes in one process >>out the other. Perhaps if you are running on a Pentium based firewall ( : ) >>), something might get corrupted. > > The proxy process is an interface. Interfaces are the exact >architectural places for "interesting" forms of failure and data >corruption/loss. As I said in my earlier note, we have lots and lots of >Internet experience with the truth of these failures. They DO occur. In >the absence of end-to-end reliability mechanisms, they occur in a manner >which is, at least sometimes, undetected in real time. > I should also point out that the business uses are NOT doing the byte pipe, but a store and forward at the firewall. Whether it is a HTTP proxy to a CGI DB2 access or an smtp forwarder. The end-to-end is commonly between the firewalls. This is not being done to address end-to-end transport reliablity, but rather to address authentication and other security concerns. I don't think I'll have a single production FTP through our firewall. Rather we will have a FTP drop box system on the firewall. Management is still too insecure as to their risks in this brave new world. This gives the community time to address some of the underlying deficiencies. I hope that IPSP will be the way to address them. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 06:09:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08860; Tue, 29 Aug 1995 06:09:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA16560; Tue, 29 Aug 1995 06:07:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA16542; Tue, 29 Aug 1995 05:59:49 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08365; Tue, 29 Aug 1995 05:58:59 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Big-Internet@munnari.OZ.AU Subject: Administrivia, replying & quoting Date: Tue, 29 Aug 1995 05:58:28 +1000 Message-Id: <13689.809639908@munnari.OZ.AU> Sender: kre@munnari.OZ.AU Precedence: bulk Just a note of (minor) warning, and a request. There are recipients of Big-Internet that gateway the messages into local usenet groups. That's fine (as long as they don't gateway the groups back to the list again, not even by making the group appear to be a moderated usenet group). If you're reading this via a news reader, and want to reply (to any message), please make sure that you send mail, not post news. But that's not the reason for this message ... that is that those usenet gateways tend to like to object to messages where there is "more included text than new text". If you send messages to the list like that, those people who read it as news tend to miss seeing your words of wisdom. That's especially true if your mailer has a habit of quoting included text with the ">" character at the start of the line. Please, help make sure your message gets to everyone, and at the same time make it easier for everyone to read, include much less of the message to which you are replying, and if you can, use some other quoting mechanism than ">". kre ps: of course, I am not just sending this because I get to see all the bounce messages from those (pretty silly) news gateways. Nothing nearly so selfish... ;-) From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 06:48:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11186; Tue, 29 Aug 1995 06:48:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA16650; Tue, 29 Aug 1995 06:47:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA16646; Tue, 29 Aug 1995 06:45:18 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10871; Tue, 29 Aug 1995 06:44:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08360 Tue, 29 Aug 1995 06:25:51 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25901; Mon, 28 Aug 95 16:23:10 -0400 Date: Mon, 28 Aug 95 16:23:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508282023.AA25901@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz > until this new stuff is widely deployed, everyone has to keep going with > the (exploding) current tables, No, that was deliberately not the way I described it. Sites get to choose ... to either use the mapping, or to use current routes. As soon as (all) the recipients are ready to decapsulate, any router can decide to drop its old default free table. I think you've just made my point. To paraphrase, until the recipients are ready to decapsulate, you have to keep the old default-free table. In other words, until a large enough proportion of the Internet has transitioned to the new scheme, you have to keep the old one running. Which is what I said. To provide a slightly more useful image of it (and, as you may have guessed, thinking about how to make transitions from one routing architecture to another work is something I have spent some time on :-), until the "new stuff" has formed a large contiguous cloud, reducing the "old stuff" to a bunch of smaller, disjoint clouds, the "old stuff" will remain the "backbone" of the system wide routing, and will have to be fully supported. You don't get to start transitioning the "old stuff" to a less-functional, "stub" mode of operation until is *is* stubs. Fortunately BGP isn't a DV protocol (I believe) Depends what you mean by DV. "Distance-Vector", no. "Destination-Vector", yes. so sites don't need to calculate routing tables themselves in order to broadcast their state to others. You don't need to maintain routing tables to let others know where you are in either flavor of DV. (I crashed the entire Internet, back in '79 or so, doing just this in GGP, which I was too lazy to implement in full! :-) I will need to think about Dave's plan more carefully to see if it will work, I kind of suspect that it might lead to some of the problem you are alluding to above though. I assure you the problems are generic. Until you get a contigous "core" running in the new scheme, the old scheme has to keep going. > There's an Experimental spec for an encapsulation protocol Deployed now or not, this part I really can't see as being the big stumbling block in this protocol. Technically, no. Timewise, yes. You know that you don't get anything deployed widely in the Internet in less than a year; the vendors have release cycles (and the bigger they get, the longer the lead time to get into one), people have to upgrade, etc, etc. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:11:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12207; Tue, 29 Aug 1995 07:11:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16711; Tue, 29 Aug 1995 07:09:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA16703; Tue, 29 Aug 1995 07:00:51 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11849; Tue, 29 Aug 1995 07:00:47 +1000 (from kre@munnari.OZ.AU) Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07537 Tue, 29 Aug 1995 05:55:05 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: renumbering In-Reply-To: Your message of "Mon, 28 Aug 1995 10:57:35 -0400." <9508281457.AA23658@ginger.lcs.mit.edu> Date: Tue, 29 Aug 1995 05:53:27 +1000 Message-Id: <13686.809639607@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Mon, 28 Aug 95 10:57:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9508281457.AA23658@ginger.lcs.mit.edu> From: Robert Elz Why do you feel it will be impossible? Is it just the massive amount of deployed stuff that assumes addresses will be constant? "just" ? But basically, yes. IPv4 will be dead before current shipped technology becomes obsolete (ie: when people replace some equipment running now, it will be with post IPv4 networking). As long as IPv4 remains, some equipment won't be upgraded. NAT boxes don't really cope with this - you might be able to isolate an entire stub with old equipment in it, but that is likely to be almost everyone for a long time yet. They can't really be used to allow some new, and some old to fix in a net, or not until the old is so minute a fraction that it can reasonably be moved into an internal stub behind a NAT, that's also likely to be too far away to matter. The reason your statement interests me should be obvious: I feel that one of the things about IPv4 that will make invisible renumbering hard is the poor choice of namespaces, Yes, you know I agree. More work is needed to make this work on IPv6, it isn't there yet. But then again, all IPv6 is (so far) is the IP layer protocol (plus ICMP) - it has no endpoint names, etc. It is not impossible to get the rest of this fixed, but we do need to be quick. We need TCPng to become active like right now - and to concentrate purely on the required fixes to allow IPv6's potential to be realised (not the luxuries that would be nice to have it do as well until later). kre From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:12:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12279; Tue, 29 Aug 1995 07:12:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16749; Tue, 29 Aug 1995 07:12:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA16664; Tue, 29 Aug 1995 06:49:56 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11247; Tue, 29 Aug 1995 06:49:47 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07831 Tue, 29 Aug 1995 06:11:03 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.59] (dial-cup2-29.iway.aimnet.com [204.118.88.59]) by aimnet.com (8.6.12/8.6.12) with SMTP id NAA17130; Mon, 28 Aug 1995 13:07:38 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 13:08:30 -0700 To: Robert Moskowitz From: Dave Crocker Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 12:05 PM 8/28/95, Robert Moskowitz wrote: >Hey this raises an interesting point. Would the encap be TCP? how will >UDP, ICMP, and XYZ be handled and maybe fragmented across this 'core'? The original Hinden proposal was called "IP in IP". That name answers your question. The "interior" IP datagram (inside of which is the transport protocol) contains the IP address of the final, destination host interface. The outside one, being used inside the NDZ cloud, contains the address of the exit border NDZ router. This is NOT a NAT scheme. No address changes are made to the original datagram. This is IDENTICAL to what is done today on an ethernet. You take an IP datagram and encapsulate it with an ethernet header, choosing the ethernet address of the next station that should perform decapsulation of the ethernet header. With IP Encaps, you put a (second) IP header on, instead of an ethernet header, and store into it the IP address of the next station that should perform decapsulation of the (outside) IP header. You might, then, observe that this means that ethernet transmission -- and all other media -- constitute encapsulation. You would be right. With luck, you might also then view this idea as architecturally clean and conceptually familiar. The only hard part -- and yes, it IS hard -- is to make sure that the address resolution process is viable. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:15:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12421; Tue, 29 Aug 1995 07:15:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16771; Tue, 29 Aug 1995 07:15:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA16694; Tue, 29 Aug 1995 06:55:57 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11598; Tue, 29 Aug 1995 06:55:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26122; Mon, 28 Aug 95 16:54:39 -0400 Date: Mon, 28 Aug 95 16:54:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508282054.AA26122@ginger.lcs.mit.edu> To: kre@munnari.OZ.AU, tli@cisco.com Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz > I missed that we were replacing the entire Internet. No, we are changing some number of routers in providers. They get to decide which to change - which will depend on what is available from you guys. If you make available something not too expensive, but that is limited in forwarding rates, they will use those things at the edges. If you make available something much more expensive, and much faster, they'll buy less, and stick them closer to the core of the net. Sorry, but I don't agree. To make your encapsulation scheme useful, we have to be able to decomission the old "routing-based-on-non-topological-addresses" routing system (at least in the non-default mode, and part of the network running it in that mode), since that system is not able to keep up with the growth. So, the real indicator of whether boxes will need to be replaced is whether or not they have full routing tables. (Of course, if these hypothetical boxs appear, but are fabulously expensive, then perhaps the topology will be rejiggered so we need less full-table routers. On the other hand, do that, and you have bigger traffic hot-spots..) I have been avoiding using AS# though for several reasons Then you can't use an existing translation databse, such as the RADB (leaving aside whether it's correct, etc, etc). it isn't possible then to demonstrate an equivalence between the mapped numbers and CIDR prefixes in the most general case (ie: widespread flat routing). That would allow Yakov and Noel Err, it's Yakov who's pushing that point about table size... to dream up some weird cases where CIDR (really flat routing) can handle, Err, how is CIDR "flat routing"? The whole point of CIDR is that it's *not* flat routing... is exactly equivalent to no more than 2^16 CIDR prefixes, and does not assume that only /16's are advertised Well, technically, it assumes that the *output* of the mapping needs no more than 2^16 distinct values. The actual table could be far larger, e.g. up to 2^24; many entries would just map to the same value. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:19:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12521; Tue, 29 Aug 1995 07:19:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16794; Tue, 29 Aug 1995 07:19:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA16700; Tue, 29 Aug 1995 07:00:45 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11833; Tue, 29 Aug 1995 07:00:38 +1000 (from kre@munnari.OZ.AU) Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07281 Tue, 29 Aug 1995 05:37:00 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Mon, 28 Aug 1995 13:40:52 -0400." <9508281740.AA24691@ginger.lcs.mit.edu> Date: Tue, 29 Aug 1995 05:35:22 +1000 Message-Id: <13676.809638522@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Mon, 28 Aug 95 13:40:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9508281740.AA24691@ginger.lcs.mit.edu> i) until this new stuff is widely deployed, everyone has to keep going with the (exploding) current tables, No, that was deliberately not the way I described it. Sites get to choose (one by one - and actually, not sites, but routers), to either use the mapping, or to use current routes. As soon as (all) the recipients are ready to decapsulate, any router can decide to drop its old default free table. What they have to do is keep advertising their routing info so that those still using full routing can continue to do so. Fortunately BGP isn't a DV protocol (I believe) so sites don't need to calculate routing tables themselves in order to broadcast their state to others. Incidentally, though Dave Crocker gave a very concise summary of a deployment plan - it wasn't mine ... I wish I could write that concisely, and then perhaps people would be able to understand what I am attempting to say with less iterations. I will need to think about Dave's plan more carefully to see if it will work, I kind of suspect that it might lead to some of the problem you are alluding to above though. ii) people who don't switch over to the new system get stuck with the current tables (or can get converted into a stub). Yes. Though "stub" is probably too harsh, they can be converted to replace some of their routing table with a default route, keeping as much of it as they can handle. Remember "people" here are the default free providers (transit nets). I don't know how many of them there are (world wide), but my guess would be something under a hundred. Well, there's an Experimental spec for an encapsulation protocol Any encapsulation protocol will do. Further, the part that needs to be widely deployed soonest is decapsulation, which is the easy part (there should be no tricky issues in this part of any rational encapsulation protocol - encapsulation sometimes faces some problems, decapsulation is "strip headers and forward"). Deployed now or not, this part I really can't see as being the big stumbling block in this protocol. kre From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:22:48 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12646; Tue, 29 Aug 1995 07:22:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07865 Tue, 29 Aug 1995 06:13:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA16591; Tue, 29 Aug 1995 06:10:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA16520; Tue, 29 Aug 1995 05:47:49 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07827; Tue, 29 Aug 1995 05:47:43 +1000 (from kre@munnari.OZ.AU) Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07423 Tue, 29 Aug 1995 05:46:23 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: renumbering In-Reply-To: Your message of "Mon, 28 Aug 1995 11:06:31 -0400." <9508281506.AA23711@ginger.lcs.mit.edu> Date: Tue, 29 Aug 1995 05:44:45 +1000 Message-Id: <13681.809639085@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Mon, 28 Aug 95 11:06:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9508281506.AA23711@ginger.lcs.mit.edu> From: "W. Donald Rolph III" If we force the user community to renumber (unless it is totally transparent to them) then the internet is doomed. This statement may be true. It is, however, also true (in the mathematical sense) that the namespace used by the routing must be one where the abstraction hierarchy can be adjusted over time, to match the changing topology. I believe that the only way both those statements can be true is if the two name spaces are separated. That is exactly the purpose of the encaps proposal (as you well know Noel, as you're one of the people I borrowed it from). NAT boxes achieve the same result - however are technically more complex to get right, especially in complex topologies, I rather suspect a NAT box would need to be a sole exit point for a net to be able to work correctly (if it really can at all). SOCKS and application gateways only solve the renumbering problem if you are willing to always renumber into newly allocated numbers, discarding those left behind - or you find someone behind an appl gwy or similar still using your new number, and while it isn't visible to the routing, it is visible inside their net, and without a NAT to translate addresses, their application gateway can't distinguish the two routes it gets. This is certainly not a robust design. I do not ask this sarcastically, but quite seriously: what ideas do you have on how to avoid this? Your, and others' ideas. Do you think we can renumber in a way which is totally invisible to the users (if not to everyone, see above)? Yes (in a hidden way). Failing that, will we need a second namespace? Yes, exacvtly, and it is that that is renumbered. If so, can that second namespace be DNS names, or must it be something else? Something else, DNS names live above IP addresses, nothing we can possibly do with them can have any affect in the current protocols (we could redesign the world to make this possible, but right now, for IPv4, building a cubic world isn't a feasible option). kre From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:23:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12664; Tue, 29 Aug 1995 07:23:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16820; Tue, 29 Aug 1995 07:22:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA16675; Tue, 29 Aug 1995 06:54:38 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11499; Tue, 29 Aug 1995 06:54:34 +1000 (from kre@munnari.OZ.AU) Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07836 Tue, 29 Aug 1995 06:11:58 +1000 (from kre@munnari.OZ.AU) To: Scott W Brim Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Mon, 28 Aug 1995 14:05:58 -0400." Date: Tue, 29 Aug 1995 06:10:20 +1000 Message-Id: <13696.809640620@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Mon, 28 Aug 1995 14:05:58 -0400 From: Scott W Brim Message-ID: Therefore, KRE's "intra-core" (define "core" as the routers within the area where the higher-level addressing is used) address prefixes should refer to chunks that are large enough that "most" multi-homing would take place within them, ... However, would this be small enough granularity to be worth it? Would the reduction of the problem by about an order of magnitude, by localizing it within half-continents, be enough? I don't think so. At this level, my proposal is identical to pure CIDR, the same number of routes need to be exported around a "perfectly" numbered CIDR environment as in mine (since I postulate exactly that environment). If my scheme doesn't work for this reason (as distinct from Tony's implementation reasons, or some other we haven't encountered yet), then CIDR doesn't (can't) work either, and we had better be looking for some other, very different, solution very quickly. I assume the router vendors are all at least poking at IPv6, and IPv6-IPv4 interworking. *If* KRE's scheme goes forward, perhaps we could use some of the ideas generated and soundly criticized in 2 years of IPv6 transition planning, instead of some new one-shot encapsulation scheme? I'm not sure that the transition schemes really address the problem we have been addressing. They mostly assume that IPv4 is still alive and at least wiggling its toes, if not exactly kicking... Don't they? Could the "core" use IPv6 and not some quick single-use encapsulation? That's certainly a possibility - if fast IPv6 routing can be done in time. As I said in some of the exchanges with Tony any underlying protocol that works will do. I selected IPv4 purely because that one I know is deployed everywhere that matters (and by that, I dont' mean that there are places that don't matter, but that by definition, as we have an IPv4 problem to solve, IPv4 must be deployed). But the choice of the bit layouts of the encapsulating packets is the least important consideration of the proposal. Anything that works will do. kre ps: astute (or more accurately, readers with time to kill who actually read my messages) will recall I said earlier that IPv6 had been suggested to me, it was Scott who suggested it. From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:24:02 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12760; Tue, 29 Aug 1995 07:24:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07217 Tue, 29 Aug 1995 05:30:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA16458; Tue, 29 Aug 1995 05:27:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA16392; Tue, 29 Aug 1995 05:09:50 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06059; Tue, 29 Aug 1995 05:08:55 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id PAA13550 for ; Mon, 28 Aug 1995 15:07:07 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id PAA04955 for ; Mon, 28 Aug 1995 15:07:12 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA24186; Mon, 28 Aug 95 15:16:35 EDT Message-Id: <9508281916.AA24186@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 15:05:27 -0400 To: Dave Crocker , Vince Fuller From: Robert Moskowitz Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 11:10 PM 8/25/95 -0700, Dave Crocker wrote: >Vince (or anyone else), > >At 6:28 PM 8/25/95, Vince Fuller wrote: >>Many of the problems associated with the original IP Encaps proposal, i.e. >>ICMP semantics, MTU sizes/fragmentation, etc. are just as applicable now as > > I made a request for information about real and hard MTU limits for >"core" routers and would appreciate some response on this. The query is >not for the current limit, per se, but for a description of the underlying >reasons for it or some other number to be a hard limit that can't >reasonably be changed. Hey this raises an interesting point. Would the encap be TCP? how will UDP, ICMP, and XYZ be handled and maybe fragmented across this 'core'? Or since the encap is a single packet, TCP is totally the wrong model? And UDP should be used and thus we need an MTU for UDP much larger than 'currently' supported? I am all of a sudden having trouble visualizing this 'tunnel'. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:24:07 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12765; Tue, 29 Aug 1995 07:24:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07242 Tue, 29 Aug 1995 05:33:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA16484; Tue, 29 Aug 1995 05:30:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA16452; Tue, 29 Aug 1995 05:26:10 +1000 Received: from news.ti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06904; Tue, 29 Aug 1995 05:25:39 +1000 (from w-rolph@ds.mc.ti.com) Received: from ganesh.mc.ti.com ([157.87.4.175]) by gate.ti.com (8.6.12/) with SMTP id OAA13760; Mon, 28 Aug 1995 14:25:23 -0500 Received: by ganesh.mc.ti.com; id AA04991; Mon, 28 Aug 1995 15:22:56 -0400 Message-Id: <9508281922.AA04991@ganesh.mc.ti.com> X-Sender: a722756@mail-ad.mc.ti.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 15:23:11 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa), bmanning@isi.edu, kre@munnari.OZ.AU From: "W. Donald Rolph III" Subject: Re: renumbering Cc: big-internet@munnari.OZ.AU Precedence: bulk >I do not ask this sarcastically, but quite seriously: what ideas do you have >on how to avoid this? Do you think we can renumber in a way which is totally >invisible to the users (if not to everyone, see above)? Failing that, will >we need a second namespace? I mentioned in my message that direct access by the end user using numeric IP addresses can probably be sacrificed. Most dont use numerica IP addresses anyway. I have posited that we might as a demonstration of feasiblity imagine an environment where directly connected networks (on interconnected lans, behind firewalss etc) were accessed by ip addresses. For names not in the local environment we could envision a "proxy like" capability (e.g. the proxy capabiltiy in the cern httpd server) which would take the named request and map at the boundary to a roting structure independent of the numerica ip addresses. It appears on its surface feasible, and avoid affecting end users (it only affect the "gateways"). >If so, can that second namespace be DNS names, >or must it be something else? DNS names would work just fine based on my thought experiments. > > Noel > > To properly calibrate my comments, I am not a TCP/IP internals guru. I am a working stiff trying to internet enable the vast majority of users in my company. We have just succeeded in getting them to accept IP at all! Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-236-1263 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:27:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12820; Tue, 29 Aug 1995 07:27:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16855; Tue, 29 Aug 1995 07:26:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA16679; Tue, 29 Aug 1995 06:55:01 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11518; Tue, 29 Aug 1995 06:54:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07710 Tue, 29 Aug 1995 06:03:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25789; Mon, 28 Aug 95 16:00:48 -0400 Date: Mon, 28 Aug 95 16:00:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508282000.AA25789@ginger.lcs.mit.edu> To: kre@munnari.OZ.AU, tli@cisco.com Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz We all agree that nothing we say can control what the providers actually do here, they're going to do whatever is necessary for them to survive And what I hear them saying is "deploy CIDR, renumbering and all". Which, together with your point, seems to indicate that almost this entire discussion of the last several weeks is a waste of time. the small scale providers change their connectivity amongst the bigger guys as well - the current proposals mean that when that happens all the small guy's customers have to renumber, which would be a sight to watch. Widespread deployment of interchanges, and use of them by small-scale providers, would avoid this. That's an example of something we *can* do to ameliorate the pain of CIDR. If we'd stop spending all out time and energy arguing about whether we have to do it (which by the above point we know we will), perhaps we could spend more time thinking up things to make it less painful. I'd be asking customers whether they'd prefer to have to renumber ... or whether they'd rather pay a slightly increased rate so the providers can implement and manage a mapping scheme to eventually make renumbering obsolete. You keep acting like the second is a realistic alternative. Some of us are mildly to blame, for humoring you by looking at the technical details of your alternatives. However, I see no evidence that any such alternative (and, don't forget, a mapping solution was *my* first choice, so it's not that I don't like mapping solutions) can be deployed in time. The IETF made a decision several years ago. Now we have to live with it. If so, perhaps the hold outs like me ... can simply keep our unrenumbered nets - and note that includes future hold outs, who don't yet have numbers or connections. If there aren't many of us, the routing should cope OK anyway, right? Yes, but if there are too many (and, somehow, the fishermen always seem to overfish), don't be surprised when all of a sudden, with little/no warning, you start not being able to reach some places because some provider on the other side of the world has decided to filter your route, and doesn't feel they have to track you down to tell you that. Now there's no doubt that the straight $ profits from selling these boxes wouldn't make it worth the effort, but if vendor XXX provides this, and the ISP's all stop buying whatever they are buying now, and start buying from XXX instead, then the newspaper, and magazine headlines "Internet switches to XXX routers" just might not be what the old router vendor's management & sales types really want to see. The public relations benefit from supplying the internet core has to be worth orders of magnitude more than the $ profits from the boxes sold there. Funny, I used to use this line all the time when I was associated with a router vendor. It didn't work inside the company, and it didn't work outside it either. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:29:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13044; Tue, 29 Aug 1995 07:29:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16866; Tue, 29 Aug 1995 07:28:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA16717; Tue, 29 Aug 1995 07:09:24 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12161; Tue, 29 Aug 1995 07:09:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26210; Mon, 28 Aug 95 17:07:05 -0400 Date: Mon, 28 Aug 95 17:07:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508282107.AA26210@ginger.lcs.mit.edu> To: minshall@ipsilon.com Subject: Re: 1. core; 2. conformance Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Greg Minshall provider-based addressing says ... "so, we will deploy measures that allow us to constrain/permute the *addressing* to conform to the evolving topology." Metro addressing, on the other hand, says "we would like to put some constraints on the *topology*, and how it will evolve... we will thus gaze into our crystal ball and determine some set of constraints that will accomplish our goal." Exactly. Note that both result in "topology-based-addresses", in some sense, in that there is a correlation between the addresses and the topology. In other words, either addressing determines topology, or topology determines addressing. Yes. To react to what you said above, though, to put the addressing first implies that we understand what we will want to do in the future with the topology. This, I am not at all sure of, and I'm even less sure that the Internet will be willing to accept restrictions on topology, since that will break *another* long-standing Internet architectural principle. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:34:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13138; Tue, 29 Aug 1995 07:34:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16900; Tue, 29 Aug 1995 07:33:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA16777; Tue, 29 Aug 1995 07:15:53 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12413; Tue, 29 Aug 1995 07:15:48 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Mon, 28 Aug 1995 16:23:10 -0400." <9508282023.AA25901@ginger.lcs.mit.edu> Date: Tue, 29 Aug 1995 07:15:24 +1000 Message-Id: <13857.809644524@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Mon, 28 Aug 95 16:23:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9508282023.AA25901@ginger.lcs.mit.edu> To paraphrase, until the recipients are ready to decapsulate, you have to keep the old default-free table. Yes, of course, that is the state right now. Something has to happen first. In other words, until a large enough proportion of the Internet has transitioned to the new scheme, you have to keep the old one running. But these aren't other words... "transitioned to the new scheme" means a lot more than "be able to decapsulate". People who decided, for one reason or other, that they would always just use default free routing could do that forever, they'd cause people to still have to send them the default free routing info, but as long as they are able to decapsulate, they're OK. Go back and read my transition plan message again. It may not be the only way, but it is certainly a possible way to move without deadlocks. Decapsulation has to be endemic - the mapping table has to be complete, beyond that individual routers can switch whenever they feel inclined. Clouds, or even storms, irrelevant. kre From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:48:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13575; Tue, 29 Aug 1995 07:48:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16943; Tue, 29 Aug 1995 07:47:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA16937; Tue, 29 Aug 1995 07:44:53 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13506; Tue, 29 Aug 1995 07:44:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26424; Mon, 28 Aug 95 17:44:20 -0400 Date: Mon, 28 Aug 95 17:44:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508282144.AA26424@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, tli@cisco.com Subject: Re: Multi-homed sites Cc: atkinson@itd.nrl.navy.mil, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li [WARNING: Extra long. Get coffee now.] To heck with coffee, what I need by now is amphetamines, or something... we need to provide some space for the organization identifier. If we make this too large, it becomes extremely painful because we must have flat routing at the metro interconnect. ... The lookup that needs to happen at switching time is now a completely flat table of all customers of the metro interconnect. ... Deering would have this space be in the millions. In Steve's defense, everyone needs to remember that metro-addressing a la Deering (which is *not* the same thing as "geographic addressing", and Steve will no doubt correct any errors I make here :-) does not route on the organization identifier directly, rather that is mapped into a provider identifier, so the routing overhead is not an issue. As to needing a "flat table of all customers", Steve indicates each provider would only have to have an exception table of customers who have switched (although we are now being told that there will be many such people, so renumbering is going to be too expensive as a solution a la CIDR :-), although of course the metro-exchange point would have to have the concatentation of all these exception tables. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:51:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13760; Tue, 29 Aug 1995 07:51:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16971; Tue, 29 Aug 1995 07:50:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA16910; Tue, 29 Aug 1995 07:36:11 +1000 Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13193; Tue, 29 Aug 1995 07:36:00 +1000 (from vjs@mica.denver.sgi.com) Received: from mica.denver.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id OAA27202; Mon, 28 Aug 1995 14:35:49 -0700 Received: by mica.denver.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for Big-Internet@munnari.OZ.AU id PAA21151; Mon, 28 Aug 1995 15:35:17 -0600 Date: Mon, 28 Aug 1995 15:35:17 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199508282135.PAA21151@mica.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: firewalls and data integrity Precedence: bulk > From: Robert Moskowitz > I should also point out that the business uses are NOT doing the byte pipe, > but a store and forward at the firewall. Whether it is a HTTP proxy to a > CGI DB2 access or an smtp forwarder. The end-to-end is commonly between the > firewalls. > > This is not being done to address end-to-end transport reliablity, but > rather to address authentication and other security concerns. > > I don't think I'll have a single production FTP through our firewall. > Rather we will have a FTP drop box system on the firewall. Silicon Graphics had a what I understand to be meant by "a FTP drop box system" for many years. We survived with it only because the company was fairly small, with fewer than 500 people who used FTP more than once a year. Even so, we survived only because we imposed draconian rules on the "drop box." Those rules include not giving permanent and private accounts on the firewalls; they must share. Even so, things would have become unworkable if we had not started to shift to SOCKSified FTP and other applications. For example, what happens the week when 10 people need to send or receive 100 MByte files over the Internet, say some kind of design file? 10*100MB is only 1GB, so you can let them do a manual copy to and from the firewall, and you can probably let their data stay on the firewall for days. What happens if you have 100 or 1000 people each of whom needs to move 100MB next week? By the way, many people think it is draconian to force them to remove their files from such a system in a matter of two or three weeks, not to mention days. > Management is still too insecure as to their risks in this brave new world. > ... Give them time. A T1 is good for about 15 GB/day, enough for 100MB/person for 700 people/week. By the time you really need a T1 or several T1's, a "drop box" becomes hard to keep going. As far as the data is concerned, SOCKSified FTP is not "store and forward." A SOCKS server only a screwy and rather slow router. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 07:53:54 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13797; Tue, 29 Aug 1995 07:53:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA16996; Tue, 29 Aug 1995 07:53:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA16917; Tue, 29 Aug 1995 07:37:32 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13250; Tue, 29 Aug 1995 07:37:21 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Mon, 28 Aug 1995 16:54:39 -0400." <9508282054.AA26122@ginger.lcs.mit.edu> Date: Tue, 29 Aug 1995 07:36:58 +1000 Message-Id: <13867.809645818@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Mon, 28 Aug 95 16:54:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9508282054.AA26122@ginger.lcs.mit.edu> To make your encapsulation scheme useful, we have to be able to decomission the old "routing-based-on-non-topological-addresses" routing system (at least in the non-default mode, and part of the network running it in that mode), since that system is not able to keep up with the growth. Yes. The point was that it is the borders of this area that need the modified algorithm, not the centre, that keeps working as it does now (but sees smaller routing tables, just the internal stuff). The providers can decide where to put the border. So, the real indicator of whether boxes will need to be replaced is whether or not they have full routing tables. Yes, but right now providers can decide which have full routing tables, and which don't. Further, to restate the previous paragraph, not all full routing boxes need adjusting - just those at the border (for some providers that may be all, for others, not, they dont' send me their inventory & deployment plans...) Err, it's Yakov who's pushing that point about table size... It wasn't the table size, it was the "how do you handle this weird routing case?" type questions I was referring to there. Err, how is CIDR "flat routing"? No, CIDR isn't - the weird routing problems I was being asked to solve were flat routing .. they were ignoring the information lost by CIDR aggregation (which is also lost by my scheme, since it also does CIDR aggregation, and hence is no better than CIDR in general - in practice it may be slightly, as CIDR has to live with prefixes advertised out of the numbering blocks, just because they haven't been renumbered, and hence must aggregate more to keep the rest of the info smaller - the mapping scheme doesn't have the first problem, so can afford slightly less aggregation, and hence perhaps slightly better routing). Well, technically, it assumes that the *output* of the mapping needs no more than 2^16 distinct values. Yes, I know, and I suspect that would be enough. However it is no longer then mathematically equivalent to CIDR routing in its most general form (which is flat routing - "most general" equals "aggregate nothing"). The actual table could be far larger, e.g. up to 2^24; many entries would just map to the same value. Yes, of course. If things were implemented by a 2^24 table you would expect that anyway, all the historic class A numbers still in use map into 64K copies of the same value... It doesn't matter how big the value is. The advantage of a 24 bit value (to me, right now) is that every table entry can have a distinct mapping value if required - which generates flat routing (or can do, the routing might still aggregate some of this), and would be useless in practice. That is where the equivalence of the routing comes from. Once you and Yakov stop attempting to dream up routing scenarios for me to solve (which you seem to have done recently) I can forget this, and then we can consider 16 bit values. kre From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 08:08:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14319; Tue, 29 Aug 1995 08:08:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA17038; Tue, 29 Aug 1995 08:07:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA16977; Tue, 29 Aug 1995 07:51:11 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13747; Tue, 29 Aug 1995 07:51:01 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10093 Tue, 29 Aug 1995 07:50:52 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzeuh18661; Mon, 28 Aug 1995 17:49:29 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: renumbering To: w-rolph@ds.mc.ti.com (W. Donald Rolph III) Date: Mon, 28 Aug 1995 17:49:29 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9508281553.AA22564@ganesh.mc.ti.com> from "W. Donald Rolph III" at Aug 28, 95 11:53:48 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 719 Precedence: bulk > I guess as the first step, I challenge the assumptions behind continued > doubling. No exponential process grows forever, and we have, as I > understand it, about one doubling left with present technology. Again, I am > not an internals guru, but I believe the assumption of continued doubling > forever needs to be examined. Indications to date are that the number of sites connected to the Internet is doubling every 5-9 months and that the doubling time is getting shorter. I agree with you that at some point this will stop, but I don't know when that will be. Given that we are having problems today, with the current size of the routing tables, what are we going to do? --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 08:13:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14558; Tue, 29 Aug 1995 08:13:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA17073; Tue, 29 Aug 1995 08:11:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA16952; Tue, 29 Aug 1995 07:49:24 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13595; Tue, 29 Aug 1995 07:49:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26437; Mon, 28 Aug 95 17:48:53 -0400 Date: Mon, 28 Aug 95 17:48:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508282148.AA26437@ginger.lcs.mit.edu> To: davidc@iij.ad.jp, dcrocker@brandenburg.com Subject: Re: firewalls and data integrity Cc: big-internet@munnari.OZ.AU, davidc@ns.iij.ad.jp, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker > If you want to be sure your data isn't corrupted, use something like MD5 you can DESIGN an extra layer of protection to take care of any issue like this. All you are doing then is to create an end-to-end integrity mechanism and that is just spiffy for a NEW service. I just had a horrible thought. If any new application includes both i) a checksum, and ii) IP addresses, then that will give a NAT box indigestion, unless it is taught the checksum algorithm. However, with authentication schemes, where one *cannot* modify the data, there is *no way* to make a NAT box work, at least if the covered data includes any IP addresses. Dependng on exactly how an TLG/ALG works, they might have a similar problem. Somethign to think about... Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 08:15:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14632; Tue, 29 Aug 1995 08:15:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA17101; Tue, 29 Aug 1995 08:15:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA16949; Tue, 29 Aug 1995 07:49:14 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13591; Tue, 29 Aug 1995 07:49:06 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id OAA16069; Mon, 28 Aug 1995 14:48:44 -0700 Date: Mon, 28 Aug 1995 14:48:44 -0700 From: Tony Li Message-Id: <199508282148.OAA16069@greatdane.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU, tli@cisco.com, atkinson@itd.nrl.navy.mil, jnc@ginger.lcs.mit.edu In-Reply-To: <9508282144.AA26424@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: Multi-homed sites Precedence: bulk In Steve's defense, everyone needs to remember that metro-addressing a la Deering (which is *not* the same thing as "geographic addressing", and Steve will no doubt correct any errors I make here :-) does not route on the organization identifier directly, rather that is mapped into a provider identifier, so the routing overhead is not an issue. While the _routing_ overhead is not an issue (it's again the "FTP the table" model), the _switching_ overhead is a very serious issue, which remains unaddressed. As to needing a "flat table of all customers", Steve indicates each provider would only have to have an exception table of customers who have switched (although we are now being told that there will be many such people, so renumbering is going to be too expensive as a solution a la CIDR :-), although of course the metro-exchange point would have to have the concatentation of all these exception tables. Which, as Brownian motion continues, ends up looking like a full table, yes? Tony From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 08:28:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15195; Tue, 29 Aug 1995 08:28:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA17139; Tue, 29 Aug 1995 08:27:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA17124; Tue, 29 Aug 1995 08:20:23 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14741; Tue, 29 Aug 1995 08:20:17 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.11] (dial-cup1-18.iway.aimnet.com [204.118.88.18]) by aimnet.com (8.6.12/8.6.12) with SMTP id PAA01550; Mon, 28 Aug 1995 15:19:02 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Aug 1995 15:19:54 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: firewalls and data integrity Cc: big-internet@munnari.OZ.AU Precedence: bulk At 2:48 PM 8/28/95, Noel Chiappa wrote: >However, with authentication schemes, where one *cannot* modify the data, >there is *no way* to make a NAT box work, at least if the covered data good point. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 08:31:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15324; Tue, 29 Aug 1995 08:31:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA17165; Tue, 29 Aug 1995 08:31:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA17111; Tue, 29 Aug 1995 08:17:47 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14662; Tue, 29 Aug 1995 08:17:41 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 28 Aug 1995 15:17:35 -0700 Posted-Date: Mon, 28 Aug 1995 15:14:52 -0700 (PDT) Message-Id: <199508282214.AA20040@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 28 Aug 1995 15:14:52 -0700 Subject: Re: IP Encapsulation Growth Proposal To: bound@zk3.dec.com Date: Mon, 28 Aug 1995 15:14:52 -0700 (PDT) Cc: dcrocker@brandenburg.com, sob@newdev.harvard.edu, big-internet@munnari.OZ.AU In-Reply-To: <9508250406.AA28331@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Aug 25, 95 00:05:57 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1185 Precedence: bulk > > > > Given prevailing opinion, I'm no doubt wrong about this, but it > >would be helpful if someone took me (us) through the details that show how > >easy renumbering handles these two issues well. You see, I'm increasingly > >suspecting a case of mass hypnosis on the operational realities associated > >with this. > > I am willing to do this on pier list. It can be done in IPv6 the piece > of core technology we are missing is adding the initial addresses to the > routers or dhcpv6 servers. Then using DNSIND from that vantage point so > DNS I think is much further ahead than people realize and being > implemented now. But if we can do autoconfiguration from the providers > routers to init the process of renumbering that will work nice. Clearly > as asp pointed out a new market for someone. > > I am being more positive than Bob I guess. ND was just one part of it > lots of work has been going on parts that are not on the IPNG list only. > It has been a point of architecture on DNS namedroppers for at least 9 > months and DHCP wg list too. Addr conf is the base. > Pier is working now. Feel free to discuss details of renumbering there. --bill From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 09:08:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16948; Tue, 29 Aug 1995 09:08:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA17229; Tue, 29 Aug 1995 09:07:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA17225; Tue, 29 Aug 1995 09:02:30 +1000 Received: from chops.icp.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16638; Tue, 29 Aug 1995 09:02:27 +1000 (from smd@icp.net) Received: by chops.icp.net with SMTP id <20697>; Mon, 28 Aug 1995 19:02:11 -0400 To: sob@academ.com (Stan Barber) Cc: "William Allen Simpson" , big-internet@munnari.OZ.AU (bigi) Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Sun, 27 Aug 1995 11:22:38 CDT." <199508271622.LAA02398@academ.com> Date: Mon, 28 Aug 1995 19:01:58 -0400 From: Sean Doran Message-Id: <95Aug28.190211-0400_edt.20697+665@chops.icp.net> Precedence: bulk In message <199508271622.LAA02398@academ.com>, Stan Barber writes: | > That said, there is some value between a mapping from | > prefix to point-of-contact. That mapping currently | > exists at the various neutral IP address registries | > like the InterNIC. | | I am confused. Do you not see the RADB as a neutral registry? If not, | please explain. I use "neutral IP address registries" to refer to the InterNIC, RIPE, and APNIC and suchlike generally, rather than to various other (sub-)registries. That said, I do consider the RADB and the MERIT part of the RA team to be completely beholden to ANS unless beaten-upon or shamed into being otherwise. Sean. From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 09:11:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17090; Tue, 29 Aug 1995 09:11:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA17266; Tue, 29 Aug 1995 09:11:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA17220; Tue, 29 Aug 1995 09:00:18 +1000 Received: from chops.icp.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16574; Tue, 29 Aug 1995 09:00:07 +1000 (from smd@icp.net) Received: by chops.icp.net with SMTP id <20697>; Mon, 28 Aug 1995 18:59:47 -0400 To: sob@academ.com (Stan Barber) Cc: "William Allen Simpson" , big-internet@munnari.OZ.AU (bigi) Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: Your message of "Sun, 27 Aug 1995 11:22:38 CDT." <199508271622.LAA02398@academ.com> Date: Mon, 28 Aug 1995 18:59:38 -0400 From: Sean Doran Message-Id: <95Aug28.185947-0400_edt.20697+664@chops.icp.net> Precedence: bulk In message <199508271622.LAA02398@academ.com>, Stan Barber writes: | Sean, you have left out the folks that use the RADB information as one | source of debugging data when trying to figure out which provider should | be announcing a particular route. Even with the inaccuracies you note, it | (and other other parts of the GRR) is still the only way to get this | information without turning to the stuff actually advertised. This is true, and in fact it's one reason that I'd like to see MERIT get going for real on the RADB. However, "for real" means developing still more tools and taking Peter Lothberg's lists of requirements and suggestions seriously. Meanwhile, I humbly offer up as a proposal the quick development of a simple (nay, trivial) tool which tracks changes to BGP advertisements, and will tell you where prefixes that disappear or change paths were last heard from. The RA's RS, in fact, would be a useful place to do the tracking, however a couple views from just about anywhere would do. Most of the work is in efficiency and user interface; the stuff I use myself is very slow and is somewhat, um, idiosyncratic. I note that the combination of finding routes that have disappeared or changed as well as being able to tell you where things are now (what's the home-as of prefix X/y?) is among the more important things I'd ask for in a debugging tool. The RADB does both, but not very well, and certainly not reliably. :( Sean. From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 09:47:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18918; Tue, 29 Aug 1995 09:47:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA17317; Tue, 29 Aug 1995 09:47:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA17302; Tue, 29 Aug 1995 09:34:14 +1000 Received: from chops.icp.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18283; Tue, 29 Aug 1995 09:34:04 +1000 (from smd@icp.net) Received: by chops.icp.net with SMTP id <20697>; Mon, 28 Aug 1995 19:31:29 -0400 To: asp@uunet.uu.net (Andrew Partan) Cc: kre@munnari.OZ.AU (Robert Elz), big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Sun, 27 Aug 1995 21:56:39 EDT." Date: Mon, 28 Aug 1995 19:31:24 -0400 From: Sean Doran Message-Id: <95Aug28.193129-0400_edt.20697+666@chops.icp.net> Precedence: bulk >I think there was a bit of confusion Yup, let's clarify some terms first, according to my usage. :) backbone box: a box that generally has only high-speed long-haul links to other backbone boxes, and an interface to some medium through which to talk to customer-access boxes, and often other local media for service machines and the like. customer-access box: a box that generally has an interface to talk to one or more backbone boxes and many generally lower-speed interfaces to talk to CPE boxes. CPE boxes: (CPE is Customer Premises Equipment) things that talk to a customer-access box on one end and customer-owned media on the other. The divisions are not always pure. SprintLink, for example, has some backbone boxes which are also customer-access boxes, although the customers tend to be exclusively high-speed (faster than 6Mbps, generally 45Mbps) speed ones. AlterNet was in a position with the national ethernet wherein essentially all boxes were both customer-access and backbone boxes. There are also some variants of backbone boxes which I call edge routers which are used at MAEs and the like and generally have one LAN interface and one WAN interface, and do nothing else but manage the peering interface between its owner network and one or more others. Some providers own all CPE boxes and provide and manage them as part of their service, making them somewhat akin to a very smart CSU/DSU (BBN seems fond of this). Other providers own and control some CPE boxes but not others. Some lease CPE routers to customers and share maintenance to some degree. Finally, some providers own essentially no CPE boxes, and do no configuration or maintenance except possibly for an initial setup, or for extra money. Of three types of boxes, the best suited to NAT and other play-with-each-packet technologies is the CPE router, particularly ones which are akin to edge routers in functionality, but which do much less traffic in pps and bps than edge routers that belong to large providers (which, incidentally, often do more than 10kpps in each direction, which is alot, but substantially less than some backbone boxes which can do more than 100kpps in several directions, and a contrast to customer-access boxes which can do 6kpps or more across sixty or more interfaces). Sean. From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 10:08:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19871; Tue, 29 Aug 1995 10:08:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA17369; Tue, 29 Aug 1995 10:07:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA17326; Tue, 29 Aug 1995 09:48:09 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18956; Tue, 29 Aug 1995 09:47:56 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id TAA18806; Mon, 28 Aug 1995 19:47:43 -0400 Date: Mon, 28 Aug 1995 19:47:43 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: Sean Doran Cc: Stan Barber , William Allen Simpson , bigi Subject: Re: IP Encapsulation Growth Proposal In-Reply-To: <95Aug28.190211-0400_edt.20697+665@chops.icp.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 28 Aug 1995, Sean Doran wrote: > That said, I do consider the RADB and the MERIT part of the > RA team to be completely beholden to ANS unless beaten-upon > or shamed into being otherwise. I thought ANS - Merit association ended with the sale of ANS. Maybe you should appeal to the real powers, like U of Michigan, for example. ;) -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 10:11:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20077; Tue, 29 Aug 1995 10:11:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA17397; Tue, 29 Aug 1995 10:10:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA17319; Tue, 29 Aug 1995 09:47:27 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18876; Tue, 29 Aug 1995 09:47:23 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id QAA14385; Mon, 28 Aug 1995 16:46:16 -0700 Message-Id: <199508282346.QAA14385@hubbub.cisco.com> To: "W. Donald Rolph III" Cc: big-internet@munnari.OZ.AU, pier@isi.edu Subject: Re: renumbering In-Reply-To: Your message of "Mon, 28 Aug 95 10:35:25 EDT." <9508281435.AA17612@ganesh.mc.ti.com> Date: Mon, 28 Aug 95 16:46:15 PDT From: Yakov Rekhter Precedence: bulk Don, > > I guess I demure vociferously. If we force the user community to renumber > (unless it is totally transparent to them) then the internet is doomed. > > I reiterate. What ever happens must happen at the gateways, and make the > addressing issues invisible to the end user. It may mean we give up the > ability to use numerical IP addresses for end user access outside the local > environment. That is an acceptable price, I would argue. To force the end > user to reconfigure regularly is physically impossible, and will I assert > guarantee failure of the internet. Do you object to renumbering in the context of IPv6 as well ? Yakov. From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 11:07:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22937; Tue, 29 Aug 1995 11:07:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA17475; Tue, 29 Aug 1995 11:07:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA17467; Tue, 29 Aug 1995 10:55:28 +1000 Received: from chops.icp.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22236; Tue, 29 Aug 1995 10:55:19 +1000 (from smd@icp.net) Received: by chops.icp.net with SMTP id <20696>; Mon, 28 Aug 1995 20:54:42 -0400 To: Scott W Brim Cc: big-internet@munnari.OZ.AU Subject: Re: 1. core; 2. conformance In-Reply-To: Your message of "Mon, 28 Aug 1995 11:09:19 EDT." Date: Mon, 28 Aug 1995 20:54:40 -0400 From: Sean Doran Message-Id: <95Aug28.205442-0400_edt.20696+668@chops.icp.net> Precedence: bulk In message , Scott W Brim writes: [metro addressing] | requires some sort | of connectivity between providers within a metro area. A minor but important corrigendum: metro addressing requires complete interconnectivity among all providers within a metro area. It also requires complete willingness on the part of all providers to any carry traffic into a metro area they connect to, no matter which provider is the destination. As I noted in an old (and very long) note to kre on CIDRD ages ago, this has some advantages and disadvantages, which I partially enumerated. The two key disadvantages, impractacibilty of scale in both the requirement for full interconnectivity and universal carriage, are very important. Essentially, if you wish to guarantee being charged on a per-packet basis, please encourage this model. The LECs will love you, and so will the people working at various long-haul NSPs and local ISPs who like the idea of unit billing for bandwidth and reachability. | In the days | since Steve first tossed out his metro addressing idea we've had plenty | of practice with this, and it shouldn't be daunting anymore. All the | providers have created exchange points and know how to talk to each | other. It's almost routine. No, there is no experience at all with _universal_ interconnectivity among an area's ISPs. Moreover, I will happily admit that I do not, in fact, know for sure how to do this (although I have some nasty ideas I could sell to Mark Knopper to make his RBOC even more incredibly rich and powerful :-) ). Sean. From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 12:10:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26153; Tue, 29 Aug 1995 12:10:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA17555; Tue, 29 Aug 1995 12:07:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA17545; Tue, 29 Aug 1995 11:55:59 +1000 Received: from cu.nih.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25161; Tue, 29 Aug 1995 11:55:11 +1000 (from RAF@CU.NIH.GOV) Message-Id: <9508290155.25161@munnari.oz.au> To: rgm3@is.chrysler.com Cc: big-internet@munnari.OZ.AU From: "Roger Fajman" Date: Mon, 28 Aug 1995 21:52:34 EDT Subject: Re: firewalls and data integrity Precedence: bulk > I should also point out that the business uses are NOT doing the byte pipe, > but a store and forward at the firewall. Whether it is a HTTP proxy to a > CGI DB2 access or an smtp forwarder. The end-to-end is commonly between the > firewalls. It seems to be true that a lot of business have firewalls, but that doesn't mean that everyone does. We are a research institution and not a business, and require very high speed links and leading edge applications that seem incompatible with firewalls (and NAT boxes) and with our decentralized organizational structure. Some businesses need very high speed links too. We may put firewalls at certain places within our network, but not at the point of connection to the Internet. Also, not everyone builds firewalls exclusively with proxies. Some use packet filters on a router and proxies for certain applications. And isn't it true that firewall implementations today, even with proxies, generally rely on the address space on the two sides being disjoint? So isn't it true that if someone behind a firewall today with unique numbers lost those unique numbers, they would have to renumber into RFC 1597 address space or address space from their provider(s) in order to avoid collisions of their addresses with other addresses in the Internet (using the numbers that used to be theirs)? Does anyone know if current NAT boxes depend on the addresses on both sides being disjoint? It seems like they would need a special protocol stacks to deal with that, as packets inside the box would need to be tagged somehow with which side they belong to. From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 14:32:39 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03509; Tue, 29 Aug 1995 14:32:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA17717; Tue, 29 Aug 1995 14:27:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA17700; Tue, 29 Aug 1995 14:18:30 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02864; Tue, 29 Aug 1995 14:17:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27478; Tue, 29 Aug 95 00:16:07 -0400 Date: Tue, 29 Aug 95 00:16:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508290416.AA27478@ginger.lcs.mit.edu> To: asp@uunet.uu.net, bill@wizard.gsfc.nasa.gov Subject: Re: ownership, leasing, renumbering, and that draft Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, yakov@cisco.com Precedence: bulk From: bill@wizard.gsfc.nasa.gov (Bill Fink) how much traffic is being blackholed due to the loss of more specific routing information that is an inherent feature of route aggregation? Err, in a system which supports aggregation exceptions (aka "longest-match"), traffic shouldn't be blackholed unless somehow you're outside the scope of the route to the exception, and you need to be inside it to have the traffic get there. The only inherent feature of route aggregation is that due to loss of info, you may not always be taking the *most optimal route* to some destinations. Explanation of the caveat "not always" is a lengthy process, but making the boundary of the area to be aggregated (what I call the "abstraction action boundary") larger than the boundary (outside that) where info on the elements of the aggregate is collapsed into a single entry (i.e. what I call the "abstraction naming boundary") ameliorates this. (Interestingly, as I explained previously, K+K seems to show that you can equate the two and still get pretty good routes, so why we need the to make the AAB larger than the ANB is not clear to me, unless we want almost optimal routing all the time). (If any of this stuff about "scopes" is confusing people, just take a blank sheet of paper, and draw a large blob on it. Imagine that the inside of the blob is filled with an even mesh of lots and lots and lots of nodes and arcs. You can now do things like: Draw a smallish aggregate (i.e. what I call an ANB) and the boundary where it get aggregated (i.e. what I call the AAB). You can see that when you get far enough away from the aggregate, your traffic to all parts of it *will* head in the same direction, and it's only when you get closer that you need more info, at least if you're going to head for the optimal entry point for your particular destination. Always, when thinking about routing, draw lots and lots of pictures. After about 10 years or so - at least that's how long it took me, but I'm not exactly Ramanujan - you may discover that you don't need to draw as many, but it sure helped me to draw lot of pictures for may years. Now I can see them in my head, but it took lots of practise.) Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 15:09:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05110; Tue, 29 Aug 1995 15:09:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA17780; Tue, 29 Aug 1995 15:07:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA17774; Tue, 29 Aug 1995 14:56:45 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04561; Tue, 29 Aug 1995 14:56:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27614; Tue, 29 Aug 95 00:56:26 -0400 Date: Tue, 29 Aug 95 00:56:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508290456.AA27614@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: "Provider-based addresses" is bad terminology Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "William Allen Simpson" > broken idea that a topology-based address hierarchy doesn't work in a > mesh. It does. Note that I didn't say "theoretically cannot work", I said "don't work". There's no reason it shouldn't work darn well, if the ANB's and AAB's are set decently. Draw a picture, of a few dozen nodes connected by arcs. Draw a circle around a small group of nodes; that's the ANB of your test aggregate. Unless you have a pretty wierd topology, you can go through all the nodes, marking all the ones where the first hop to all the nodes in the aggregate is the same, and wind up with a pretty substantial set of marked nodes. If you draw a line which encloses all the unmarked nodes, you have drawn an AAB which results in hierarchical routing producing *exactly* the same routes as flat routing. The difference, of course, is that every node *outside* the AAB has only one routing table entry for the entire aggregate. You can generalize this to many layers of aggregation, on a *very* large graph, but the result remains; you can get pretty close to "optimal" routing with *much* smaller routing tables than flat routing. Heck, if you don't believe that, look at K+K. They *prove* what the upper bounds are on the increase in path length for hierarchical as opposed to non-hierarchical routing, and K+K assumes that AAB=ANB... And it is a fact that it IS NOT actually working. ... This appears to be because of shortest prefix matching, which forces everything into a heirarchy instead of a mesh. What? I though Internet routing operating on *longest prefix matching*. If it didn't, you *couldn't* pick up your address block from a CIDR block and move it to a new provider. Anyway, even if we did have shortest prefix matching, it still wouldn't mean the routing would have to be hierarchical. For example, suppose A.1.x had, by virtue of the AAB for A.2 being outside A.2, and including all of A.1, separate routing table entries for A.2.*. Routing from A.1.x to any points in A.2 would effectively be "flat", i.e. optimal. What kind of routing you get all depends on where you set the AAB. It's almost always possible (albeit perhaps not computationally trivial) to pick an AAB for any abstraction which give you the exact same routing as flat routing, but with smaller routing tables in most places. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 15:30:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06326; Tue, 29 Aug 1995 15:30:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA17836; Tue, 29 Aug 1995 15:27:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA17821; Tue, 29 Aug 1995 15:25:03 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06108; Tue, 29 Aug 1995 15:24:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27711; Tue, 29 Aug 95 01:23:16 -0400 Date: Tue, 29 Aug 95 01:23:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508290523.AA27711@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: Benefits of Geographic examples Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "William Allen Simpson" This statement so annoyed me that I actually spent the money to call Noel and get higher bandwidth. Unforunately, this message does not contain details of the actual proposed geographic addressing scheme you mentioned to me on the phone (which went, as I recall, ). So I'm not positioned to discuss that particular scheme (which I would like to do, if you will describe it again), but I will comment on your points here. WWA is a Chicago BBS ... They are multihomed with MCInet and SprintNet. ... The alternative pushed by the providers that WWA should be re-numbered under one of them, say MCI ... reduces the routing table for MCI, but not for Sprint I'm not sure I see this. Both MCI and Sprint have to carry a route for WWA around, whether WWA is addressed under MCI, or separately. My solution was a geographic address matching the actual NAP near which they are connected -- that is, Chicago. This is nothing mroe than topology-base addressing, drawing on the fact that there is a topology-connection point in Chicago. If there were none, geographic addressing wouldn't help you. While a wonderful intellectual exercise for purists, I do NOT agree with Noel that drawing circles which include some other set of links and no exchange is worthwhile. A given graph can produce an almsot infinite number of abstraction hierarchies. However, some will have nice characteristics, but to decide which ones are more useful, you have to set some goals for your addressing; e.g. being able to multihome with a single address, and limit the scope over which your aggregate has to be separate advertised When WVN becomes multi-homed, either by connecting to Old-Miss in Oxford or someone else in Tupelo, then their exception route needs to be propagated worldwide. Bad news, since it will be yet another hole in the NA block and in WWA's block ... This would have been avoided if geographic was used in the first place for WVN. Well, not as long as it maintains a multihomed link to WWA. If it did, and were numebred geographically out of Mississippi, then the route to it via WWA would need to be propogated worldwide. Widely space dual-homing is expensive is you support it in the routing, not matter *what* address scheme is being used, since you need to have such a large AAB to make it useful. The local freenet BBS Arbornet.Org is a harder case. It is connected to 2 regional providers (MichNet & MSEN), who are connected to multiple national providers (MCInet & PSInet). Since these only peer at MAE-East ... we have to assign them a _CONTINENTAL_ topological address. Yes, unless you assign them an address on one provider or another, in which case i) you will need an exception route in the other provider (this, along with an exception route in their "primary" provider, can be used to handle traffic to them if their link to their primary goes down), and ii) as you mention, incoming traffic will tend to bias to come in their primary provider. While assigning a geographic address results in no routing table reduction TODAY, should both regional or national providers someday interconnect in Chicago, or Michigan, or eventually in Ann Arbor, each such STEP would result in a GLOBAL and CONTINENTAL savings in routing table size. In other words, pick an addressing hierarchy that you think will match the eventual physical topology. Suppose you guess wrong? I expect some coordination and restrictions on where topology would be located. I think that planning our topology better would have gone a long way toward fixing many of our routing problems. A statement with which we can all agree. Instead, we have a bunch of independent "providers" all refusing to interconnect in any way that might improve competition. There is nothing to stop people setting up regional interconnection points, as I described in my message to Ran. That would give you the benefits of geographic addressing (for those who wanted them) in the current system. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 16:14:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08043; Tue, 29 Aug 1995 16:14:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA17889; Tue, 29 Aug 1995 16:07:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA17885; Tue, 29 Aug 1995 16:00:04 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07596; Tue, 29 Aug 1995 15:59:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05053 Tue, 29 Aug 1995 15:57:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27912; Tue, 29 Aug 95 01:55:01 -0400 Date: Tue, 29 Aug 95 01:55:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508290555.AA27912@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu Subject: Re: "Provider-based addresses" is bad terminology Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker > Do you mean Steve's metro-addressing, or some variant Noel, yes, I mean something along the line of Steve's metro-addressing. Ah, well, as far as I'm concerned the salient points of Steve's scheme were a three part organization, with the middle field mapped (with a scope local to a given metro) to a provider, via a mapping table. If yours is different, you need only point out the differences. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 16:31:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09020; Tue, 29 Aug 1995 16:31:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA17946; Tue, 29 Aug 1995 16:27:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA17927; Tue, 29 Aug 1995 16:23:14 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08497; Tue, 29 Aug 1995 16:22:59 +1000 (from deering@parc.xerox.com) Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16745(1)>; Mon, 28 Aug 1995 23:22:43 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 28 Aug 1995 23:22:40 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Benefits of Geographic examples In-Reply-To: jnc's message of Mon, 28 Aug 95 22:23:16 -0800. <9508290523.AA27711@ginger.lcs.mit.edu> Date: Mon, 28 Aug 1995 23:22:35 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Aug28.232240pdt.75270@digit.parc.xerox.com> Precedence: bulk > In other words, pick an addressing hierarchy that you think will match > the eventual physical topology. Suppose you guess wrong? "The best way to predict the future is to invent it." From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 16:33:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09094; Tue, 29 Aug 1995 16:33:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA17984; Tue, 29 Aug 1995 16:31:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA17924; Tue, 29 Aug 1995 16:15:58 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08062; Tue, 29 Aug 1995 16:15:16 +1000 (from deering@parc.xerox.com) Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16702(6)>; Mon, 28 Aug 1995 23:13:02 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 28 Aug 1995 23:12:54 -0700 To: big-internet@munnari.OZ.AU Cc: deering@parc.xerox.com Subject: metro-based addressing In-Reply-To: jnc's message of Mon, 28 Aug 95 14:44:20 -0800. <9508282144.AA26424@ginger.lcs.mit.edu> Date: Mon, 28 Aug 1995 23:12:45 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Aug28.231254pdt.75270@digit.parc.xerox.com> Precedence: bulk There have a been a few inaccuracies in folks' characterization of my metro addressing proposal, for which I assume all blame, since I've never done a proper write-up of the scheme. I hope to find time next week, after SIGCOMM, to respond to some of the mail on this list, and more importantly, to start working on a write-up. Until then, perhaps the slides from the talk I gave in Lixia's plenary session in Stockholm will help to fill in a little more detail about metro addressing, for those who might be interested. The PostScript of the slides can be fetched from: ftp://parcftp.xerox.com/pub/net-research/metro-addr-slides-jul95.ps Note: the metro proposal is for IPv6. It certainly won't work with what's left of the IPv4 address space, though something based on much larger geographic units than metros could probably be made to work in IPv4, as a stop-gap and as a proof-of-concept. Steve From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 16:51:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09816; Tue, 29 Aug 1995 16:51:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA18019; Tue, 29 Aug 1995 16:47:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA18015; Tue, 29 Aug 1995 16:46:17 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09659; Tue, 29 Aug 1995 16:46:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28774; Tue, 29 Aug 95 02:44:22 -0400 Date: Tue, 29 Aug 95 02:44:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508290644.AA28774@ginger.lcs.mit.edu> To: w-rolph@ds.mc.ti.com Subject: Re: renumbering Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: "W. Donald Rolph III" I mentioned in my message that direct access by the end user using numeric IP addresses can probably be sacrificed. ... For names not in the local environment we could envision a "proxy like" capability .. which would take the named request and map at the boundary to a roting structure independent of the numerica ip addresses. If we did that, those numbers would not be globally unique (or visible) anyway. So what's the harm in changing them? Also, the names in the "routing structure"; I assume you would allow them to change? Noel PS: Here in the future, probably the number in every host that you *can't* change will be their private key. From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 17:31:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11366; Tue, 29 Aug 1995 17:31:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA18079; Tue, 29 Aug 1995 17:27:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA18064; Tue, 29 Aug 1995 17:22:47 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10890; Tue, 29 Aug 1995 17:22:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28838; Tue, 29 Aug 95 03:22:09 -0400 Date: Tue, 29 Aug 95 03:22:09 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508290722.AA28838@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, swb1@cornell.edu Subject: Re: Comments on draft-ietf-cidrd-ownership-01.txt Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Scott W Brim Noel, would you agree that hierarchical addressing constrains the use of the topology to be hierarchical? No, absolutely not. It depends on the scope over which you advertise the elements of an abstraction. Remember, if the scope for the elements of every abstraction is set to the optimal AAB for that abstraction, you get the exact same routes as with flat addressing... Also, even if the AAB's are all set equal to the ANB's, it's not at all clear that the resulting traffic patterns are "hierarchical". See K+K for an explanation of why this is not so. They explicity state: Note that the hierarchical routing procedure we propose need *not* imply a hierarchical topological structure; indeed this routing procedure provide very significant improvements when applied to a distributed network topology. If the topology need not be constrained to a hierarchy, that's because they can make use of non-hierarchical links. To put it another way, if the use were hierarchical as you content, there'd be no benefit to non-hierarchical links, but that's not so. If the topology includes connections which are not represented in the addressing hierarchy which is chosen, the address hierarchy will lead to some links not being used, unless extra routing information is added? Your premise (topological hierarchy) is wrong. You need to think about the topological scopes over which routing information is distributed. Specifically in this case, if I have address space which is a suballocation from one provider, then any connection to another provider will not be used unless extra information about my bit of the address space is propagated in addition. Yes, and the overhead cost of doing so will be exactly the same as if the multi-homed area had been assigned out of a higher abstraction that included both providers. I.e. using addresses of the form A.M, A.1.M, or A.2.M has identical overhead costs *everywhere*, assuming the scopes over which that entity is seen as a distinct destination are identical. They will also have no difference in the way inbound traffic is treated, again assuming identical scopes. If they aren't visible over identical scopes, then the ability to do this is related in part to the address you picked (e.g. A.M more or less has to be visible everywhere inside A, whereas A.1.M could be resticted to A.1 and A.2), and also has corresponding affects on the routing (e.g. A.1.M would bias inbound traffic to A.1). Whether you like those affects, and the concomittant changes in the overhead cost, is not for me to say. But fundamentally I think you're presenting a red herring in this paragraph, since regardless of the underlying topology, addressing forces a pattern of use of the topology Well, depending on the scopes you set for routing info, you can get many different patterns of usage, all with the same addressing hierarchy. and hierarchical addressing forces hierarchical use of the topology. No, that's incorrect. Depending on how much you restrict the AAB from the optimal AAB, you can bias things more and more to hierarchical routing, but from the perfectly optimal routign you'd get with totally flat addresses. That's why ... why geographic addressing of any sort has started to look pretty good again This remains to be seen. Propose a scheme in a little more detail, and I'll analyze it. Addressing, and topology use, are hierarchical. If addressing is provider-based then multi-homing between providers causes details to be propagated over far too much of the topology. Depends on the topology, and where you set the ANB's and AAB's. If addressing is geographical (with interconnects in metro areas) then multi-homing between geographical areas causes details to be propagated too far. This is the same, essentially, as picking non-optimal topology, etc, with plain topology-based adresses. At this point, though, it looks like a large number of organizations want to (indeed, must, for business reasons) multi-home between providers Hmm. Why, just out of interest? How many have multiple long-distance carriers? > So, tell me, how does a system which uses metro-addressing respond when a > provider loses its link to a given metro-exchange? The same way the current Internet responds when a provider loses a connection to a multi-homed organization -- to the extent that routing supports it, the other providers take the traffic. If a provider becomes disconnnected from a metro, there is no easy way (depending on exactly which geographic scheme you're using) to route inbound traffic from other providers to that provider's customers in that metro, by going outside the metro to another place where that provider connects. (Actually, I threw you a bit of a curve ball there, in two ways. First, the provider might have multiple links to the exchange point, or more likely, I'd design a system with multiple exchange points for real reliabilty. Second, the most analagous problem in topological-based addressing is area partition, which is also not solvable trivially... That's the problem with routing, the complete answer is almost always not simple.) > a number of practical points, such as i) the need for more as yet > undefined mechanism, at least for metro-addressing a la Steve, such as > the mapping between subscriber id and provider, and ii) the fact that to > deploy it everyone will have to renumber. The first is straightforward Relatively so, but since when could the IETF tie its own shoelaces and get them deployed in less than two years? the second is a problem which could be addressed with IPv6 deployment. But we need to keep IPv4 running short-term. I don't claim that metro addressing is a perfect solution for anything. I look forward to the dawn of the new architecture (nimrod, yay). Don't get too enthusiastic. Nimrod can't make a perpetual motion machine either. Some of these problems (e.g. providing multi-homing for free) just don't have solutions. All Nimrod does is give you a very flexible framework, one I hope will serve for decades, to try new stuff. we've had some experience which would make geographic addressing easier to deploy as a medium-term strategy now than 2 years ago As I said, give me some techical details of such a geographic addressing scheme so I can analyze it. Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 17:52:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12411; Tue, 29 Aug 1995 17:52:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA18128; Tue, 29 Aug 1995 17:47:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA18095; Tue, 29 Aug 1995 17:38:11 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11740; Tue, 29 Aug 1995 17:38:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10303 Tue, 29 Aug 1995 17:37:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28950; Tue, 29 Aug 95 03:34:49 -0400 Date: Tue, 29 Aug 95 03:34:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508290734.AA28950@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, swb1@cornell.edu Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Scott W Brim A major reason not to mandate provider-based addressing is that multihoming between providers will have to be seriously discouraged It depends on what the topology looks like, how optimal you want the routign to be, and a host of other factors. If we want to make multi-provider multi-homing a goal, there are ways to arrange *some parts of the topology*, and *the relevant addressing*, to make it pretty easy, even in "topology- based addressing" system. (My note to Ran this morning covered all that.) address prefixes should refer to chunks that are large enough that "most" multi-homing would take place within them, so multi-homing will not cause extra "higher-level" routes to be propagated across the "core", and also so that this "intra-core" addressing and topology have something to do with each other. Of course, this is true of a number of schemes, not just KRE's. I suspect the size of this chunk will need to be on the order of half a continent or so -- anything smaller and most multi-homing would be done between chunks Not necessarily. It all depends on how you do it. If we set up "interchange" points for people who want to be multi-homed (set up duplicates if you want redundancy, it will work) we can provide that capabiltity with smaller scopes. Topology-based-addresses can do more or less anything geographic addresses can do, with more flexibility. (I except metro-addressing, since that contains a mapping step which gives it even more flexibility.) Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 18:11:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13142; Tue, 29 Aug 1995 18:11:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA18171; Tue, 29 Aug 1995 18:07:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA18134; Tue, 29 Aug 1995 17:51:26 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12369; Tue, 29 Aug 1995 17:51:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29150; Tue, 29 Aug 95 03:50:25 -0400 Date: Tue, 29 Aug 95 03:50:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508290750.AA29150@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz > To paraphrase, until the recipients are ready to decapsulate, you have > to keep the old default-free table. Yes, of course, that is the state right now. > In other words, until a large enough proportion of the Internet has > transitioned to the new scheme, you have to keep the old one running. But these aren't other words... "transitioned to the new scheme" means a lot more than "be able to decapsulate". True, but it turns out the latter formulation is true too. You need not only i) the destinations ready to decapsulate (which will take some time), but also ii) the new style routing more or less up, which means most "core" routers need to be participating in the new-style routing. (Any which aren't you can turn into stubs). In other words, until you have a routing backbone up with the new routing, you can't turn off the old one. You do need more than just the encapsulation/ decapsulation. Also, of course, you have to have enough routers converted to provide a contiguous core (i.e. default-free-zone). People who decided, for one reason or other, that they would always just use default free routing could do that forever, they'd cause people to still have to send them the default free routing info If people could run default-free routing with the old system, we wouldn't be discussing any of these options... Go back and read my transition plan message again. It may not be the only way, but it is certainly a possible way to move without deadlocks. I didn't say there were deadlocks. I said you have to get the new routing up and running in the "core" before you can turn off the old routing. If you have some way of getting around that, and running without the new routing up yet, while being able to turn off the old, let's just do that, and to heck with the new routing... Noel From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 18:29:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14038; Tue, 29 Aug 1995 18:29:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA18220; Tue, 29 Aug 1995 18:27:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA18205; Tue, 29 Aug 1995 18:15:18 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13298; Tue, 29 Aug 1995 18:14:50 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA11984 Tue, 29 Aug 1995 18:14:47 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA18841; Tue, 29 Aug 1995 01:12:49 -0700 Date: Tue, 29 Aug 1995 01:12:49 -0700 From: Tony Li Message-Id: <199508290812.BAA18841@greatdane.cisco.com> To: w-rolph@ds.mc.ti.com Cc: asp@uunet.uu.net, bmanning@ISI.EDU, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <9508281553.AA22564@ganesh.mc.ti.com> (w-rolph@ds.mc.ti.com) Subject: Re: renumbering Precedence: bulk I guess as the first step, I challenge the assumptions behind continued doubling. No exponential process grows forever, and we have, as I understand it, about one doubling left with present technology. Again, I am not an internals guru, but I believe the assumption of continued doubling forever needs to be examined. A good point. Logistic curves have been plotted [by Frank Solensky] and based on the current growth show that we run out of address space before exponential growth stops. This is, of course, based on what we know _today_. Tony From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 18:34:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14172; Tue, 29 Aug 1995 18:34:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA18242; Tue, 29 Aug 1995 18:32:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA18192; Tue, 29 Aug 1995 18:11:36 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13167; Tue, 29 Aug 1995 18:11:28 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA18798; Tue, 29 Aug 1995 01:09:27 -0700 Date: Tue, 29 Aug 1995 01:09:27 -0700 From: Tony Li Message-Id: <199508290809.BAA18798@greatdane.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: kre@munnari.OZ.AU, tli@cisco.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9508281740.AA24691@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: Discussing encap/mapping proposal Precedence: bulk all default free exit routers need to be able to handle packets [in the] underlying protocol, decapsulate them, and route the resulting packet. That may be the case already, I must admit not having attempted to send IP in IP to a router to see what it does with the enclosed packet... Well, there's an Experimental spec for an encapsulation protocol (RFC-1241), but I'm not sure it's widely supported. There's also GRE (RFC's 1701, 1702), ditto. GRE is already supported in a whole lot of the routers in the Internet. Also, the MBone uses encapsulation, but I'm not sure of the details. So I doubt this is actually an availble piece. Mbone uses IP in IP encapsulation. Please note that the encapsulation scheme is the LEAST of our worries. Tony From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 19:30:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16259; Tue, 29 Aug 1995 19:30:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA18336; Tue, 29 Aug 1995 19:27:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA18317; Tue, 29 Aug 1995 19:12:43 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15629; Tue, 29 Aug 1995 19:12:34 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id CAA19606; Tue, 29 Aug 1995 02:12:18 -0700 Date: Tue, 29 Aug 1995 02:12:18 -0700 From: Tony Li Message-Id: <199508290912.CAA19606@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: <13510.809614412@munnari.OZ.AU> (message from Robert Elz on Mon, 28 Aug 1995 22:53:32 +1000) Subject: Re: Discussing encap/mapping proposal Precedence: bulk [Warning: this too seems to be long. More coffee.] I'm not convinced that you have to have mandatory renumbering to have hierarchical aggregation. Oh good - please say more. The last time we discusses this, leaving an option for people (even comparatively small users) to avoid renumbering you were of the opinion, I believe, that this would leave things too wide open - there'd be no way to verify they weren't just leaving the work to others, the "someone else can do this, my one number won't hurt" approach. I think you misunderstand me, but that's my fault for not being more verbose. As the ownership draft points out, anyone who aggregates a sufficient amount of IP address space (and how much is not currently defined) need not aggregate further. That is to say, ~"if you're big enough, and we get one prefix from you, we'll that's good enough because we don't need perfect aggregation"~. For the sake of discussion let's pick a point that's 1/30,000th of the _currently_ reachable address space. Note: this is ONLY an example. This is NOT intended as a proposal. Also note that this point is a moving target. Note also that within such an aggregate, what you do is your own damn business. You wanna bridge it all together? Fine by me. You wanna do host routes? No worries, mate. More power to you and can I sell you more DRAM for your 7000/7500? ;-) Inside such an aggregate, if the _local_ policy is to not require mandatory renumbering, that is a _local_ problem. I suspect that you want to do _something_ to allow routing to scale, but how you achieve this is left open. Note that this has the wonderful advantage that the DFZ survives and only these large aggregates suffer internally. Assuming hierarchical aggregation, we can extend this further down, such that each level has flat routing its level, and default pointing up one level. Each local level could be engineered to run the flat portion so that their routers were as "full" as folks cared to run them. Note that this does NOT preclude all cases of mandatory numbering. If you renumber between higher level aggregates, then that's a problem. However, it does provide a local (topological) scope in which changing providers does not require renumbering. I realize that Noel may be the only one who has followed me this far, so let me walk through a not-so-completely-random example. Suppose that we can have a single aggregate for all of Australia. Use the "no-advertise" technique to achieve suitably optimal routing for any glaring exceptions. Now, we establish an Australian backbone which carries default and a bunch of flat routing within this level. How this gets engineered is a local problem. If you have only 30,000 prefixes, then maybe you flat route them. Maybe you get each university to inject only a single prefix and each commercial company to do so and let all of the roaming users be flat routed. Or maybe, you add another layer of hierarchy underneath it. Perhaps the next layer should be geographic as Australia seems to have few cases where change of providers would take you to the next metropolis. Maybe the PTT can dictate metropolitan exchanges because it's the only one that can carry long-distance traffic. I'll fully admit that I don't know how to explain this well enough to the providers and the registries and the end users such that they all make reasonable engineering choices and don't simply cause the Australian backbone to implode in two years. The social engineering of bringing the mass of users up to speed on topologically significant routing is daunting, nay, intractable given the observable social conditions. The point here is that each level in the hierarchy needs sufficient aggregation such that current technology works and the growth rate is sustainable with then-current techniques. Any technique which achieves sufficient aggregation at each level of the hierarchy is acceptable. Moves that change the topological connectivity sufficiently will _still_ require renumbering. The more hierarchy that we can install at the higher layers, the less we need from the lower layers. And the less that happens at the lower layers, the flatter things at the bottom can be, thus allowing less renumbering. Engineering more hierarchy in is a serious problem because address assignment and current allocations aren't set up the right way. So the major problem with this is that I don't see how to get there from here. ;-) I would be interested in more details of this new, milder, approach. In any case, when the net grows, a pure cidr based approach is necessarily going to have to become more and more strict to maintain agregation levels. I still feel we should be developing al alternative approach that can avoid this requirement. I don't think anything is milder about it. In fact, in many cases, it will be MORE draconian: "Hi, I'd like you to renumber Australia. This week, please." I just want to point out that there are other dimensions within CIDR which are other perfectly acceptable means of achieving the same goals. If folks are so distressed at the thought of mandatory renumbering on changes, then perhaps they are willing to put more enginering energy into local aggregation. Tony From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 20:27:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18411; Tue, 29 Aug 1995 20:27:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA18414; Tue, 29 Aug 1995 20:27:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA18395; Tue, 29 Aug 1995 20:13:25 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17738; Tue, 29 Aug 1995 20:13:13 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id GAA11521 for ; Tue, 29 Aug 1995 06:13:12 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id GAA07981 for ; Tue, 29 Aug 1995 06:13:38 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA00520; Tue, 29 Aug 95 06:22:38 EDT Message-Id: <9508291022.AA00520@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 06:11:16 -0400 To: bmanning@ISI.EDU, asp@uunet.uu.net (Andrew Partan) From: Robert Moskowitz Subject: Re: Benefits of Geographic examples Cc: bsimpson@MorningStar.Com, big-internet@munnari.OZ.AU Precedence: bulk At 06:31 AM 8/28/95 -0700, bmanning@ISI.EDU wrote: >> >> > So, they have the usual IP number which is _NOT_ under MCI or Sprint, >> > and has to be advertised worldwide separately. Hopefully, we can all >> > agree that this is bad. >> >> Why? If every multihomed site (customer or provider) in the world got >> a seperate address block, things would work just fine - there are only >> 814 of them today. >> --asp@uunet.uu.net (Andrew Partan) > >Er, thats 814 visable to you... right? >There are over 6000 of them delegated now. :) But bill, how many of them are going to be multihomed. How many are going to be connected to the internet? Remember, we have 4 Bs only one is visible and that will change before this year is out. What about all of the Bs Boeing has, are all visible? GM? ??? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 20:47:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19147; Tue, 29 Aug 1995 20:47:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA18457; Tue, 29 Aug 1995 20:47:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA18451; Tue, 29 Aug 1995 20:46:08 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19030; Tue, 29 Aug 1995 20:46:05 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 29 Aug 1995 03:45:57 -0700 Posted-Date: Tue, 29 Aug 1995 03:43:13 -0700 (PDT) Message-Id: <199508291043.AA20181@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 29 Aug 1995 03:43:13 -0700 Subject: Re: Benefits of Geographic examples To: rgm3@is.chrysler.com (Robert Moskowitz) Date: Tue, 29 Aug 1995 03:43:13 -0700 (PDT) Cc: bmanning@ISI.EDU, asp@uunet.uu.net, bsimpson@MorningStar.Com, big-internet@munnari.OZ.AU In-Reply-To: <9508291022.AA00520@clncrdv1.is.chrysler.com> from "Robert Moskowitz" at Aug 29, 95 06:11:16 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1684 Precedence: bulk > > At 06:31 AM 8/28/95 -0700, bmanning@ISI.EDU wrote: > >> > >> > So, they have the usual IP number which is _NOT_ under MCI or Sprint, > >> > and has to be advertised worldwide separately. Hopefully, we can all > >> > agree that this is bad. > >> > >> Why? If every multihomed site (customer or provider) in the world got > >> a seperate address block, things would work just fine - there are only > >> 814 of them today. > >> --asp@uunet.uu.net (Andrew Partan) > > > >Er, thats 814 visable to you... right? > >There are over 6000 of them delegated now. :) > > But bill, how many of them are going to be multihomed. Depends on who you listen to. Andrew and Sean have indicated a current value of ~8% of their client base is multihomed. Response to D.Crockers query pulled was decidedly in favor of multihomed (at least planning to) for the ISP's that replied. > How many are going to be connected to the internet? Remember, we have 4 Bs > only one is visible and that will change before this year is out. What > about all of the Bs Boeing has, are all visible? GM? ??? That's not really the point. The question is how many AS's are you making visable? The assumption here is that you can aggregate to a single prefix for an AS announcement. If this is really the case, then my query should have a self evident answer.... The public internet -can- handle 814+/- routing entries just fine. Heck, it can even hold 6000+/- entries. ...if we can get to a state where there are no more than 5 prefixes announced per AS... (assuming that there is a slowdown in AS growth :) > > Robert Moskowitz > Chrysler Corporation > (810) 758-8212 > > -- --bill From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 21:27:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20572; Tue, 29 Aug 1995 21:27:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA18565; Tue, 29 Aug 1995 21:27:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18524; Tue, 29 Aug 1995 21:20:24 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20301; Tue, 29 Aug 1995 21:20:08 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id EAA25847; Tue, 29 Aug 1995 04:19:48 -0700 Date: Tue, 29 Aug 1995 04:19:48 -0700 From: Tony Li Message-Id: <199508291119.EAA25847@greatdane.cisco.com> To: bmanning@ISI.EDU Cc: kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <199508291112.AA20232@zed.isi.edu> (bmanning@ISI.EDU) Subject: Re: Discussing encap/mapping proposal Precedence: bulk > I don't think anything is milder about it. In fact, in many cases, it > will be MORE draconian: "Hi, I'd like you to renumber Australia. This > week, please." How about, in the next 25 minutes? Without contacting every network admin. Obviously, some longer term transition period is reasonable. Tony From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 21:30:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB20709; Tue, 29 Aug 1995 21:30:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA18592; Tue, 29 Aug 1995 21:30:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18509; Tue, 29 Aug 1995 21:15:00 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20088; Tue, 29 Aug 1995 21:14:53 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 29 Aug 1995 04:14:43 -0700 Posted-Date: Tue, 29 Aug 1995 04:11:59 -0700 (PDT) Message-Id: <199508291112.AA20232@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 29 Aug 1995 04:12:00 -0700 Subject: Re: Discussing encap/mapping proposal To: tli@cisco.com (Tony Li) Date: Tue, 29 Aug 1995 04:11:59 -0700 (PDT) Cc: kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <199508290912.CAA19606@greatdane.cisco.com> from "Tony Li" at Aug 29, 95 02:12:18 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 803 Precedence: bulk > Note that this does NOT preclude all cases of mandatory numbering. If > you renumber between higher level aggregates, then that's a problem. > However, it does provide a local (topological) scope in which changing > providers does not require renumbering. That's the case that I am worried about... the higher level aggregates that will find that renumbering is needed at those levels. > I realize that Noel may be the only one who has followed me this far, No so. Makes perfect sense. > I don't think anything is milder about it. In fact, in many cases, it > will be MORE draconian: "Hi, I'd like you to renumber Australia. This > week, please." How about, in the next 25 minutes? Without contacting every network admin. > Tony > (I know, I know... back in the cage... :) --bill From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 21:33:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20836; Tue, 29 Aug 1995 21:33:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA18617; Tue, 29 Aug 1995 21:33:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18527; Tue, 29 Aug 1995 21:22:55 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20428; Tue, 29 Aug 1995 21:22:43 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id HAA22315; Tue, 29 Aug 1995 07:22:37 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id HAA08161; Tue, 29 Aug 1995 07:23:05 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA00873; Tue, 29 Aug 95 07:32:00 EDT Message-Id: <9508291132.AA00873@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 07:20:39 -0400 To: "W. Donald Rolph III" , asp@uunet.uu.net (Andrew Partan) From: Robert Moskowitz Subject: Re: renumbering Cc: bmanning@ISI.EDU, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU, pier@ISI.EDU Precedence: bulk At 11:53 AM 8/28/95 -0400, W. Donald Rolph III wrote: > >I guess as the first step, I challenge the assumptions behind continued >doubling. No exponential process grows forever, and we have, as I >understand it, about one doubling left with present technology. Again, I am >not an internals guru, but I believe the assumption of continued doubling >forever needs to be examined. Let me give you a couple of heads ups that will make Internet Access much simpler. First off Win95 with Microsoft Plus! gives you everything you need to connect. Of course this will only produce a further push in the PPP business that is easy to aggregate. But Win95 is Winfw done right. Peer computing is easy. Small business LANs actually work. Now add an NT workstation (you don't need NT Server for this) and you have IP forwarding out through a RAS connection on NT. 10 minutes to configure for me. Mostly the time to read the RAS Internet help panels and follow the instructions exactly. There are two models for connection, open and restricted. Open is the problem one for us, as NT is an IP forwarder and the addresses of the Win95 boxes are accessable to the Internet. The restricted is no problem for us, as only the NT box accesses the Internet and the Win95 boxes access services on it (simple PPP again). So as small businesses learn to hook up easily to the Internet, there could be a rash of new small LAN requests. The smart thing for the ISPs will be to learn to support NT Server's DHCP to simplify the LAN configuration (Win95 supports it, naturally). Of course, this is the acid test. If the ISP does not support the client well, they have given them the setup to easily migrate to another ISP! Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 21:47:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21246; Tue, 29 Aug 1995 21:47:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA18669; Tue, 29 Aug 1995 21:47:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18642; Tue, 29 Aug 1995 21:37:28 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20941; Tue, 29 Aug 1995 21:37:22 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id EAA26118; Tue, 29 Aug 1995 04:37:02 -0700 Date: Tue, 29 Aug 1995 04:37:02 -0700 From: Tony Li Message-Id: <199508291137.EAA26118@greatdane.cisco.com> To: bmanning@ISI.EDU Cc: bmanning@ISI.EDU, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <199508291127.AA20262@zed.isi.edu> (bmanning@ISI.EDU) Subject: Re: Discussing encap/mapping proposal Precedence: bulk Top down, lets say the DHCP lease on the /9 for Australia expires. How long then? Assuming that they still meet the aggregation conditions, why not simply renew it? Tony From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 21:50:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21300; Tue, 29 Aug 1995 21:50:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA18691; Tue, 29 Aug 1995 21:50:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18656; Tue, 29 Aug 1995 21:43:13 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21149; Tue, 29 Aug 1995 21:43:00 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 29 Aug 1995 04:42:58 -0700 Posted-Date: Tue, 29 Aug 1995 04:40:14 -0700 (PDT) Message-Id: <199508291140.AA20289@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 29 Aug 1995 04:40:14 -0700 Subject: Re: Discussing encap/mapping proposal To: tli@cisco.com (Tony Li) Date: Tue, 29 Aug 1995 04:40:14 -0700 (PDT) Cc: bmanning@ISI.EDU, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <199508291137.EAA26118@greatdane.cisco.com> from "Tony Li" at Aug 29, 95 04:37:02 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 327 Precedence: bulk > > > Top down, lets say the DHCP lease on the /9 for Australia > expires. How long then? > > Assuming that they still meet the aggregation conditions, why not > simply renew it? > Because Rupert has moved his new subsidiary MicroSloth, to Perth and now Australia needs a /8. They -need- a new lease. -- --bill From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 21:54:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21488; Tue, 29 Aug 1995 21:54:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA18714; Tue, 29 Aug 1995 21:53:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18663; Tue, 29 Aug 1995 21:46:03 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21220; Tue, 29 Aug 1995 21:45:54 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id EAA26235; Tue, 29 Aug 1995 04:45:50 -0700 Date: Tue, 29 Aug 1995 04:45:50 -0700 From: Tony Li Message-Id: <199508291145.EAA26235@greatdane.cisco.com> To: bmanning@ISI.EDU Cc: bmanning@ISI.EDU, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <199508291140.AA20289@zed.isi.edu> (bmanning@ISI.EDU) Subject: Re: Discussing encap/mapping proposal Precedence: bulk > Top down, lets say the DHCP lease on the /9 for Australia > expires. How long then? > > Assuming that they still meet the aggregation conditions, why not > simply renew it? Because Rupert has moved his new subsidiary MicroSloth, to Perth and now Australia needs a /8. They -need- a new lease. If their percentage of active destinations has significantly increased, then it is entirely reasonable to give them a _second_ prefix, which might well be a /8 or /9. Tony From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 21:57:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21618; Tue, 29 Aug 1995 21:57:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA18767; Tue, 29 Aug 1995 21:57:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18598; Tue, 29 Aug 1995 21:30:56 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20660; Tue, 29 Aug 1995 21:30:29 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 29 Aug 1995 04:30:26 -0700 Posted-Date: Tue, 29 Aug 1995 04:27:43 -0700 (PDT) Message-Id: <199508291127.AA20262@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 29 Aug 1995 04:27:43 -0700 Subject: Re: Discussing encap/mapping proposal To: tli@cisco.com (Tony Li) Date: Tue, 29 Aug 1995 04:27:43 -0700 (PDT) Cc: bmanning@ISI.EDU, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <199508291119.EAA25847@greatdane.cisco.com> from "Tony Li" at Aug 29, 95 04:19:48 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 568 Precedence: bulk > > > > I don't think anything is milder about it. In fact, in many cases, it > > will be MORE draconian: "Hi, I'd like you to renumber Australia. This > > week, please." > > How about, in the next 25 minutes? Without contacting every > network admin. > > Obviously, some longer term transition period is reasonable. > To be sure. It becomes a top down or bottom up question. Bottom up, traditional renumbering by subnet. Takes months/years. Top down, lets say the DHCP lease on the /9 for Australia expires. How long then? -- --bill From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 22:01:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21689; Tue, 29 Aug 1995 22:01:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA18792; Tue, 29 Aug 1995 22:00:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18623; Tue, 29 Aug 1995 21:33:47 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20846; Tue, 29 Aug 1995 21:33:37 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id HAA24427 for ; Tue, 29 Aug 1995 07:33:36 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id HAA08217 for ; Tue, 29 Aug 1995 07:34:04 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA00912; Tue, 29 Aug 95 07:43:14 EDT Message-Id: <9508291143.AA00912@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 07:31:52 -0400 To: Dave Crocker From: Robert Moskowitz Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 01:08 PM 8/28/95 -0700, Dave Crocker wrote: >At 12:05 PM 8/28/95, Robert Moskowitz wrote: >>Hey this raises an interesting point. Would the encap be TCP? how will >>UDP, ICMP, and XYZ be handled and maybe fragmented across this 'core'? > > The original Hinden proposal was called "IP in IP". That name >answers your question. The "interior" IP datagram (inside of which is the >transport protocol) contains the IP address of the final, destination host >interface. The outside one, being used inside the NDZ cloud, contains the >address of the exit border NDZ router. > So IP in IP is another IP protocol. TCP is 6, UDP is 17, IP is ??? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 22:04:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21917; Tue, 29 Aug 1995 22:04:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA18816; Tue, 29 Aug 1995 22:04:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18579; Tue, 29 Aug 1995 21:29:53 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20636; Tue, 29 Aug 1995 21:29:47 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id HAA23374 for ; Tue, 29 Aug 1995 07:29:47 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id HAA08198 for ; Tue, 29 Aug 1995 07:30:15 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA00885; Tue, 29 Aug 95 07:39:25 EDT Message-Id: <9508291139.AA00885@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 07:28:03 -0400 To: Scott W Brim , big-internet@munnari.OZ.AU From: Robert Moskowitz Subject: Re: Discussing encap/mapping proposal Precedence: bulk At 02:05 PM 8/28/95 -0400, Scott W Brim wrote: >A major reason not to mandate provider-based addressing is that >multihoming between providers will have to be seriously discouraged, >and I find this as unacceptable as others. Multi-homing with multiple >providers is critical and fundamental to the health of the Internet. >This isn't for some architectural reason or for economics, or whatever. >The fact is that the way the providers work these days they just don't >satisfy the users' needs for quality connectivity. > Would this still hold true if the only multihoming is at established 'NAP's? In otherwords. Only those providers that can afford to hookup to and peer at NAPs can multihome. All others cannot. This is partly an academic question and partly for an idea I have... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 22:10:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22042; Tue, 29 Aug 1995 22:10:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA18843; Tue, 29 Aug 1995 22:09:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18773; Tue, 29 Aug 1995 21:58:34 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21644; Tue, 29 Aug 1995 21:58:28 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id EAA26482; Tue, 29 Aug 1995 04:58:25 -0700 Date: Tue, 29 Aug 1995 04:58:25 -0700 From: Tony Li Message-Id: <199508291158.EAA26482@greatdane.cisco.com> To: deering@parc.xerox.com (Steve Deering) Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU Subject: Re: Benefits of Geographic examples Precedence: bulk > In other words, pick an addressing hierarchy that you think will match > the eventual physical topology. Suppose you guess wrong? "The best way to predict the future is to invent it." I _think_ Steve just offered to buy all of the links in the Internet. Thanks Steve. OC-48 to my house, please... ;-) Tony rset="us-ascii" Date: Tue, 29 Aug 1995 07:24:33 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU, evanw@sabine.us.dell.com From: Robert Moskowitz Subject: Re: IP Encapsulation Growth Proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk At 01:31 PM 8/28/95 -0400, Noel Chiappa wrote: > From: Evan Wetstone > > Our major problem will be our large legacy systems that have had their IP > addresses hardcoded in client applications. ... I can not renumber those > machines without bringing the entire organization to a halt. And that's > unacceptable. > >Clearly. However, would NAT boxes, SOCKS, etc (all available technology) work >to support those machines? Do they even need to talk to the rest of the >Internet? Has anyone seen a multihomed site running SOCKS or NAT firewalls. These both seem to require default routes in the internal network. Of course, you could have one default route for one campus and another for a second campus. My router support colleagues hate default routes and won't configure them... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 22:28:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22717; Tue, 29 Aug 1995 22:28:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA18954; Tue, 29 Aug 1995 22:28:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA18893; Tue, 29 Aug 1995 22:14:39 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22230; Tue, 29 Aug 1995 22:14:28 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id IAA00973 for ; Tue, 29 Aug 1995 08:14:29 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id IAA08486 for ; Tue, 29 Aug 1995 08:14:58 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA03466; Tue, 29 Aug 95 08:24:13 EDT Message-Id: <9508291224.AA03466@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 08:12:50 -0400 To: big-internet@munnari.OZ.AU From: Robert Moskowitz Subject: Re: Discussing encap/mapping proposal Precedence: bulk I finally got through all of the messages gened here over the weekend. Don't you people have a life? ;-} Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 22:37:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22989; Tue, 29 Aug 1995 22:37:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA18902; Tue, 29 Aug 1995 22:15:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18659; Tue, 29 Aug 1995 21:43:22 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21154; Tue, 29 Aug 1995 21:43:15 +1000 (from kre@munnari.OZ.AU) To: Sean Doran Cc: big-internet@munnari.oz.au Subject: Re: ownership, leasing, renumbering, and that draft In-Reply-To: Your message of "Mon, 28 Aug 1995 19:31:24 -0400." <95Aug28.193129-0400_edt.20697+666@chops.icp.net> Date: Tue, 29 Aug 1995 21:42:50 +1000 Message-Id: <13971.809696570@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Mon, 28 Aug 1995 19:31:24 -0400 From: Sean Doran Message-ID: <95Aug28.193129-0400_edt.20697+666@chops.icp.net> Yup, let's clarify some terms first, according to my usage. :) Perfectly reasonable. backbone box: customer-access box: CPE boxes: All sound like reasonable definitions to me. The divisions are not always pure. Certainly - which I would assume depends on economics, and other issues. Of three types of boxes, the best suited to NAT and other play-with-each-packet technologies is the CPE router, Sure, that would be nice (not that I think anything is suited to NAT in particular, but that is another issue) but you would not want to do this in routers over which you don't have config control - I would agree that to make the mapping scheme near term feasible, the number of parties involved needs to be kept as low as possible - including end users (which includes me) in the config issues would cause too many problems - we need a scheme where only the (large) providers need to agree & share the data. For the mapping scheme you get to choose which of those you do the mapping in, including your edge router variant of backbone boxes. The constraint is that you want to get rid of default free routing, so you have to move away from the interconnects (MAEs etc) far enough that you can work with default (or default plus specific routes) in the rest of the net. Now if you currently ship default free routes to some CPE's, and that's necessary, then those CPE's would need to be where the mapping goes. On the othre hand, if you only need default free in the backbone routers, then the customer-access boxes could do the mapping (whether or not they are currently default free), or some of the backbone boxes could. Or, you could install new boxes between the customer access boxes and the backbone, or between the CPE's and the customer access boxes (I know, financially probably not the best way, but an option anyway). Further, you don't have to be consistent thoughout your net, in some parts you can use CPEs (if you have control), in other parts customer access boxes, and in others, the backbone. There are setups that make no sense - but all that's required is that there is some box between the backbone and the customer that can decapsulate, so the customer gets the original packets and not the encapsulated versions - and that the mapping gets done where you would otherwise start needing to follow some route other than 0/0 (one box could be mapping some packets, and direct routing others that are mapped elsewhere, or of course, not mapped at all). kre From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 22:48:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23409; Tue, 29 Aug 1995 22:48:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA18976; Tue, 29 Aug 1995 22:33:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA18866; Tue, 29 Aug 1995 22:11:12 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22076; Tue, 29 Aug 1995 22:11:04 +1000 (from rgm3@is.chrysler.com) Received: from sg543689.eng.chrysler.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19889 Tue, 29 Aug 1995 22:11:01 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id IAA00023 for ; Tue, 29 Aug 1995 08:08:28 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id IAA08435 for ; Tue, 29 Aug 1995 08:08:57 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA03394; Tue, 29 Aug 95 08:18:06 EDT Message-Id: <9508291218.AA03394@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 08:06:43 -0400 To: "Roger Fajman" From: Robert Moskowitz Subject: Re: firewalls and data integrity Cc: big-internet@munnari.OZ.AU Precedence: bulk At 09:52 PM 8/28/95 EDT, Roger Fajman wrote: >> I should also point out that the business uses are NOT doing the byte pipe, >> but a store and forward at the firewall. Whether it is a HTTP proxy to a >> CGI DB2 access or an smtp forwarder. The end-to-end is commonly between the >> firewalls. > >It seems to be true that a lot of business have firewalls, but that >doesn't mean that everyone does. We are a research institution and not >a business, and require very high speed links and leading edge >applications that seem incompatible with firewalls (and NAT boxes) and >with our decentralized organizational structure. Some businesses need >very high speed links too. We may put firewalls at certain places >within our network, but not at the point of connection to the Internet. Roger, I understand your (and Ran's) orginazational position. I have heard them many times, no offense please. My point is you will soon (if not already) outnumbered. You now become the special case that can be handle as adp pointed out. Notice the comments about connects doubling every 5-9 months. That is not from research and government agencies. And many of these agencies will not be wide open (I sure hope my city takes due dilegence in its connection. I do not want my taxes wasted in recovering from hacker attacks). >Also, not everyone builds firewalls exclusively with proxies. Some use >packet filters on a router and proxies for certain applications. And >isn't it true that firewall implementations today, even with proxies, >generally rely on the address space on the two sides being disjoint? >So isn't it true that if someone behind a firewall today with unique >numbers lost those unique numbers, they would have to renumber into RFC >1597 address space or address space from their provider(s) in order to >avoid collisions of their addresses with other addresses in the >Internet (using the numbers that used to be theirs)? Correct about packet filtering firewalls. Orgs with low risks might use them. Follow the firewalls list about their risks. Orgs that care about risks will tend toward proxy firewalls of one sort or another. Proxies can use a subnet of your internal addressing (check out 152.116.1.69) or a separate network. If your internal address exists elsewhere on the internet (all too common with companies connecting for the first time where they grabbed a set of addresses out of the air), a double proxy firewall is the only solution other than readdressing. Yes 1597 is a workable solution for the internal addresses. Why do you think I worked on it? Unfortunately we got it 3 months too late to stop the reuse of 129.9. We were down to 100 devices on that net, by the time 1597 got approved it was at 4,000..... And no DHCP yet. Hope to change that with the Win95 rollout 96Q1.... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 22:48:29 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23411; Tue, 29 Aug 1995 22:48:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA18908; Tue, 29 Aug 1995 22:16:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18709; Tue, 29 Aug 1995 21:53:25 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21454; Tue, 29 Aug 1995 21:53:04 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id HAA27310 for ; Tue, 29 Aug 1995 07:53:03 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id HAA08311 for ; Tue, 29 Aug 1995 07:53:32 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA03077; Tue, 29 Aug 95 08:02:37 EDT Message-Id: <9508291202.AA03077@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 07:51:15 -0400 To: vjs@mica.denver.sgi.com (Vernon Schryver), Big-Internet@munnari.oz.au From: Robert Moskowitz Subject: Re: firewalls and data integrity Precedence: bulk At 03:35 PM 8/28/95 -0600, Vernon Schryver wrote: >> From: Robert Moskowitz > >> I should also point out that the business uses are NOT doing the byte pipe, >> but a store and forward at the firewall. Whether it is a HTTP proxy to a >> CGI DB2 access or an smtp forwarder. The end-to-end is commonly between the >> firewalls. >> >> This is not being done to address end-to-end transport reliablity, but >> rather to address authentication and other security concerns. >> >> I don't think I'll have a single production FTP through our firewall. >> Rather we will have a FTP drop box system on the firewall. > >Silicon Graphics had a what I understand to be meant by "a FTP drop box >system" for many years. We survived with it only because the company >was fairly small, with fewer than 500 people who used FTP more than >once a year. Even so, we survived only because we imposed draconian >rules on the "drop box." Those rules include not giving permanent and >private accounts on the firewalls; they must share. > Outbound is highly restricted. Communication with suppliers will be handled differently (stay tuned to the AIAG AutoTech presentation on Sept 19th). As to inbound, we are using the Gauntlet firewall from TIS. This is based on their toolkit. Too many people use this to not have seen the problems that lack of end-to-end checking entails. Ergo I suspect that TIS is doing some layer violations in the ftp-gw componenent. I'll ask Marcus... >Even so, things would have become unworkable if we had not started >to shift to SOCKSified FTP and other applications. For example, what >happens the week when 10 people need to send or receive 100 MByte files >over the Internet, say some kind of design file? 10*100MB is only 1GB, >so you can let them do a manual copy to and from the firewall, and you >can probably let their data stay on the firewall for days. What >happens if you have 100 or 1000 people each of whom needs to move 100MB >next week? drop box is for outbound to suppliers and is a business requirement in terms of checkout before delivery, but this will most likely be a web, not ftp dropbox. Inbound I just mentioned. Remember you work for a different sort of business than most people that might connect to the internet... > >By the way, many people think it is draconian to force them to remove >their files from such a system in a matter of two or three weeks, not >to mention days. Draconian measures are a way of life in corporations. Welcome to the real world. Empowerment! Ha! > >> Management is still too insecure as to their risks in this brave new world. >> ... > >Give them time. A T1 is good for about 15 GB/day, enough for >100MB/person for 700 people/week. By the time you really need a T1 or >several T1's, a "drop box" becomes hard to keep going. If anything, things will become 'productionalized'. A culture will be created about protecting corporate assests. I know. I am reviewing a number of external communication policies... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 23:07:50 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24188; Tue, 29 Aug 1995 23:07:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA19039; Tue, 29 Aug 1995 23:07:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA19016; Tue, 29 Aug 1995 22:47:12 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23405; Tue, 29 Aug 1995 22:46:57 +1000 (from rgm3@is.chrysler.com) Received: from sg543689.eng.chrysler.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA21403 Tue, 29 Aug 1995 22:46:54 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id IAA06028 for ; Tue, 29 Aug 1995 08:45:40 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id IAA08697 for ; Tue, 29 Aug 1995 08:46:09 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA03660; Tue, 29 Aug 95 08:55:06 EDT Message-Id: <9508291255.AA03660@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 08:43:44 -0400 To: Tony Li , deering@parc.xerox.com (Steve Deering) From: Robert Moskowitz Subject: Re: Benefits of Geographic examples Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU Precedence: bulk At 04:58 AM 8/29/95 -0700, Tony Li wrote: > > > In other words, pick an addressing hierarchy that you think will match > > the eventual physical topology. Suppose you guess wrong? > > "The best way to predict the future is to invent it." > >I _think_ Steve just offered to buy all of the links in the Internet. >Thanks Steve. OC-48 to my house, please... ;-) Greedy. What will you do with that? An OC-12 should suit all current and future needs :) Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Aug 29 23:27:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24950; Tue, 29 Aug 1995 23:27:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA19091; Tue, 29 Aug 1995 23:27:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA19072; Tue, 29 Aug 1995 23:12:09 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24249; Tue, 29 Aug 1995 23:11:54 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Tue, 29 Aug 1995 03:50:25 -0400." <9508290750.AA29150@ginger.lcs.mit.edu> Date: Tue, 29 Aug 1995 23:11:30 +1000 Message-Id: <13986.809701890@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Tue, 29 Aug 95 03:50:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9508290750.AA29150@ginger.lcs.mit.edu> True, but it turns out the latter formulation is true too. You need not only i) the destinations ready to decapsulate (which will take some time), but also ii) the new style routing more or less up, which means most "core" routers need to be participating in the new-style routing. (Any which aren't you can turn into stubs). Oh yes, I see what you mean, you mean that they have to be advertising routes to the new addresses, so packets that are encapsulated can find their way through. That's true. That's also easy - all it means is adding some number of new routes to the routing tables - at any one point I'd think we'd probably need a couple of hundred to start. That's not great but its not nearly as bad as the kind of growth that could occur naturally. Its also going to produce some rather less than optimal routing for a while, until the existing default free rouutes can be phased out. Given an address allocation plan we can start on that right now, there's no technology delay at all for this, I didn't really consider it a significant point, though I think it was mentioned in the deployment plan. What is not required is for any particular number of routers to be enable to do the mapping and encapsulation, they can be turned on one by one, after the decapsulation is available, and the routing info for the interior addresses is available. This seems to be the more significant consideration, as it is this function that requires notable amounts of new code in routers initially, and probably eventually new hardware. kre From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 00:28:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27840; Wed, 30 Aug 1995 00:28:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA19526; Wed, 30 Aug 1995 00:27:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA19506; Wed, 30 Aug 1995 00:26:35 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27690; Wed, 30 Aug 1995 00:25:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00136; Tue, 29 Aug 95 10:24:34 -0400 Date: Tue, 29 Aug 95 10:24:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508291424.AA00136@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, rgm3@is.chrysler.com Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Moskowitz I finally got through all of the messages gened here over the weekend. Don't you people have a life? ;-} We wish we had time for it. :-( Seriously, I often wonder if the debate here is having any useful effect. If it is, then I suppose I don't begrudge the time and energy (although I wish there were more efficeint way to do this). I wonder, though... Noel From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 00:31:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27988; Wed, 30 Aug 1995 00:31:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA19548; Wed, 30 Aug 1995 00:31:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA19166; Wed, 30 Aug 1995 00:15:05 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27166; Wed, 30 Aug 1995 00:14:51 +1000 (from vjs@mica.denver.sgi.com) Received: from SGI.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23811 Wed, 30 Aug 1995 00:14:46 +1000 (from vjs@mica.denver.sgi.com) Received: from mica.denver.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id HAA26037; Tue, 29 Aug 1995 07:12:11 -0700 Received: by mica.denver.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for Big-Internet@munnari.OZ.AU id IAA27030; Tue, 29 Aug 1995 08:11:43 -0600 Date: Tue, 29 Aug 1995 08:11:43 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199508291411.IAA27030@mica.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal Precedence: bulk > From: Robert Moskowitz > Subject: Re: IP Encapsulation Growth Proposal > > At 01:31 PM 8/28/95 -0400, Noel Chiappa wrote: > > From: Evan Wetstone > > > > Our major problem will be our large legacy systems that have had their IP > > addresses hardcoded in client applications. ... I can not renumber those > > machines without bringing the entire organization to a halt. And that's > > unacceptable. > > > >Clearly. However, would NAT boxes, SOCKS, etc (all available technology) work > >to support those machines? Do they even need to talk to the rest of the > >Internet? > > Has anyone seen a multihomed site running SOCKS or NAT firewalls. Silicon Graphics has two connections to the Internet, both to the main campus in Mountain View, and we use SOCKS. SOCKS traffic from internal users goes out via both providers. The SOCKS gateways are all visible to each other both via internal and external routes. I did not write "multihomed," because the various externally visibly IP networks are not currently advertised via more than one provider, although that has been proposed (and I have argued strongly against it). It would not be a big deal, and I have often argued for someone to spend the time to make the SOCKS application libraries do the obvious thing, obtaining a list of SOCKS servers instead of a single IP address and round-robining to spread the load, falling-back when the first fails, etc. The list of SOCKS server addresses should not be configured into each client, but instead obtained in one of the usual ways (e.g. NIS maps, DNS extensions, fetched from well known server using ftp, rcp, or a new protocol of your own design). If you do that, then your applications are in effect almost multihomed, but you don't worry about BGP or anything else fancy. Your applications are only almost multihomed because they wouldn't be very smart in they way they choose SOCKS gateways. > These > both seem to require default routes in the internal network. Of course, you > could have one default route for one campus and another for a second campus. > My router support colleagues hate default routes and won't configure them... Why do SOCKS servers require default routes? Isn't a SOCKS server or gateway just another application? If you can run /usr/etc/ftpd or the ftp command on a machine with non-default routing, then why can't you run /usr/etc/sockd the same? Running external, default-free routing on a UNIX box might be unusual, but it doesn't sound impossible. As for default routes in the internal network, Silicon Graphics has a few defaults among the ~1000 RIP (local) and IGRP (WAN) routes, but they are only local simplifications (e.g. to reduce RIP traffic over PPP and SLIP links) or mistakes. (I've been fighting for years to get defaults used significantly internally. 1000 RIP and IGRP routes is a bit much.) None of the internal default routes has anything to do with internal access to the SOCKS gateways--Well, system using defaults over PPP links use them for the first hop or two. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 01:08:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29590; Wed, 30 Aug 1995 01:08:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA19605; Wed, 30 Aug 1995 01:07:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA19580; Wed, 30 Aug 1995 00:51:38 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28913; Wed, 30 Aug 1995 00:51:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00352; Tue, 29 Aug 95 10:51:26 -0400 Date: Tue, 29 Aug 95 10:51:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508291451.AA00352@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU, vjs@mica.denver.sgi.com Subject: Re: IP Encapsulation Growth Proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: vjs@mica.denver.sgi.com (Vernon Schryver) The list of SOCKS server addresses should not be configured into each client At least as IPv4 addresses! If you must, use DNS names... :-) Running external, default-free routing on a UNIX box might be unusual, but it doesn't sound impossible. I seem to recall that you and I had a difference of opinion about this, but perhaps I'm wrong. My opinion is that in general, having hosts have routing tables is a bad idea, since it means hosts have to track developments in the routing protocols. Of course, a SOCKS box might be a place where you can legitimately argue that it's OK; it is, after all, more or less a species of gateway. Noel From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 01:30:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00560; Wed, 30 Aug 1995 01:30:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA19653; Wed, 30 Aug 1995 01:27:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA19604; Wed, 30 Aug 1995 01:07:49 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29575; Wed, 30 Aug 1995 01:07:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00454; Tue, 29 Aug 95 11:07:27 -0400 Date: Tue, 29 Aug 95 11:07:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508291507.AA00454@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, rgm3@is.chrysler.com Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker This is IDENTICAL to what is done today on an ethernet. At some level, but the devil is in the details. You take an IP datagram and encapsulate it with an ethernet header, choosing the ethernet address of the next station that should perform decapsulation of the ethernet header. ... With IP Encaps, you put a (second) IP header on ... and store into it the IP address of the next station There's one pretty devilish detail. This process is pretty easy on an Ethernet, where the number of potential exit points is low, and if there are routers attached, an off-the-shelf routing protocol will fully distribute routing info beteween them at reasonable cost. One far larger net, like a giant WAN, this is a much harder proposition, and if you don't believe this, ask the ROLC people. you might also then view this idea as architecturally clean and conceptually familiar. Sigh. One thing I'd have though this whole debate would have taught people is that archiectures which work fine at one order of scale don't always work well when scaled up by several orders of magnitude. The only hard part -- and yes, it IS hard -- is to make sure that the address resolution process is viable. Unless you are using terminology in a non-standard way, this is incorrect. To use the WAN example, it's not translating the next-hop IP address to the WAN MAC address (i.e. address resolution) that's so hard, it's picking the exit point from the WAN (for transit traffic; i.e. routing decisions). I think any member of the ROLC WG would be happy to confirm this... Noel From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 01:47:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01198; Wed, 30 Aug 1995 01:47:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA19695; Wed, 30 Aug 1995 01:47:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA19678; Wed, 30 Aug 1995 01:38:13 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00932; Wed, 30 Aug 1995 01:38:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00610; Tue, 29 Aug 95 11:38:05 -0400 Date: Tue, 29 Aug 95 11:38:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508291538.AA00610@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, tli@cisco.com Subject: Re: Multi-homed sites Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li > the metro-exchange point would have to have the concatentation of all > these exception tables. Which, as Brownian motion continues, ends up looking like a full table, yes? You will excuse me if I let you argue with the real Steve, instead of the poor imitation of him I would provide! :-) Noel From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 01:51:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01407; Wed, 30 Aug 1995 01:51:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA19720; Wed, 30 Aug 1995 01:51:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA19675; Wed, 30 Aug 1995 01:33:43 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00634; Wed, 30 Aug 1995 01:33:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00541; Tue, 29 Aug 95 11:30:58 -0400 Date: Tue, 29 Aug 95 11:30:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508291530.AA00541@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz > we have to be able to decomission the old "routing based on > non-topological-addresses" routing system (at least in the non-default > mode, and [the] part of the network running it in that mode) The point was that it is the borders of this area that need the modified algorithm, not the centre, that keeps working as it does now (but sees smaller routing tables, just the internal stuff). It's certainly true that only the borders need the wrapping/unwrapping stuff. I have to think for a while about whether or not the internal routers in the "core" (i.e. the non-default part of the net) - or actually, the core routers as a whole - need only one kind of routing table, the old, or the new. Hmmm. I'm not sure; there could be some complications. I'm not sure I can say this well, but let me give a first crack at it. The thing I'm worrying about is an intermediate stage when we have both an old partial core, and a new partial core. For the routing to keep working, the new core is going to have to translate back from its wonderful new compressed routing tables to the old uncompressed one, so it can inject its routing data into the old routing (since you need both to create a functional overall core). I don't think we have that backmapping (although we could probably compute it from your forward mapping table). You need to think of all the possible intermediate cases, not just the end-case where the new stuff forms the core, and you have a few unconverted stubs that you handle (effectively) with defaults. For intance, suppose you have a number of large disjoint "islands" of new stuff in the core. Etc, etc. What I think you start to see is there will be a time when you don't have a single "core" of old or new stuff, and have to do a lot of converting routing data back and forth from old representation to neI'm sayign this poorly, but perhaps you get the idea. As far as the traffic goes, you have to have a "unified" core which can route everywhere; the fact that under the sheets you are making a transition has to be hidden. Then you have to ask the question whether it's mechanically easier to run the old and new routing side-by-side, than do this translation. Hmm, maybe not, since until you can turn the remaining bits of old-style core into stubs, you have to be able to inject new-style routing info into the old-style core. On the other hand, I suppose you keep the oldstyle one fully operational, in parallel, until you gotth new one to the point where you can reduce the old one to stubs. Then you just make the switch.. Actually, now that I think about it, maybe some internal routers need the wrapping/unwrapping too. As the border of the new-style-routing area spreads, there will be routers which are temporarily on the border, but later are internal. They may not need the wrapping/unwrapping later on, but they do during the transition. Hmm. I need to think about this some more. No doubt, by the time you reply, I will have! :-) These darn interoperable transition things are usually the hardest part to get right, I find. Oh, for a blank sheet of paper! Noel From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 02:10:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02161; Wed, 30 Aug 1995 02:10:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA19772; Wed, 30 Aug 1995 02:07:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA19701; Wed, 30 Aug 1995 01:49:13 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01353; Wed, 30 Aug 1995 01:49:08 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.54] (dial-cup2-24.iway.aimnet.com [204.118.88.54]) by aimnet.com (8.6.12/8.6.12) with SMTP id IAA21578; Tue, 29 Aug 1995 08:48:03 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 08:49:00 -0700 To: Robert Moskowitz From: Dave Crocker Subject: Re: IP Encapsulation Growth Proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 4:31 AM 8/29/95, Robert Moskowitz wrote: >So IP in IP is another IP protocol. TCP is 6, UDP is 17, IP is ??? Yup. Already assigned, long ago: The value that goes in the ID field is 4. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 02:11:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02195; Wed, 30 Aug 1995 02:11:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA19805; Wed, 30 Aug 1995 02:11:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA19753; Wed, 30 Aug 1995 01:56:05 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01537; Wed, 30 Aug 1995 01:55:59 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzexb22562; Tue, 29 Aug 1995 11:55:42 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Benefits of Geographic examples To: bmanning@ISI.EDU Date: Tue, 29 Aug 1995 11:55:41 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199508291043.AA20181@zed.isi.edu> from "bmanning@ISI.EDU" at Aug 29, 95 03:43:13 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 819 Precedence: bulk > Depends on who you listen to. Andrew and Sean have indicated > a current value of ~8% of their client base is multihomed. Please also remember that if this holds world-wide, then we only have some 10,000 sites connected to the Internet (total number of visible ASs in the Internet is ~800; 800 is 8% of 10K). Thus 8% is high - there are probably more like 50-100K sites connected to the Internet. The number of multihomed sites is thus probably a lot closer to 1% than to 8%. A note on renumbering: people do renumber this phones, even w/o moving. Look at all of the new area codes that the US is adding. [Typically there is a transition period of some 18 months for people completely switch to their new phone number, and both numbers work during that transition period.] --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 02:14:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02274; Wed, 30 Aug 1995 02:14:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA19832; Wed, 30 Aug 1995 02:14:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA19768; Wed, 30 Aug 1995 02:06:06 +1000 Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01977; Wed, 30 Aug 1995 02:05:47 +1000 (from vjs@mica.denver.sgi.com) Received: from mica.denver.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.oz.au> id JAA11546; Tue, 29 Aug 1995 09:05:38 -0700 Received: by mica.denver.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for Big-Internet@munnari.oz.au id KAA27322; Tue, 29 Aug 1995 10:05:32 -0600 Date: Tue, 29 Aug 1995 10:05:32 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199508291605.KAA27322@mica.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal Precedence: bulk > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > The list of SOCKS server addresses should not be configured into each > client > > At least as IPv4 addresses! If you must, use DNS names... :-) Of course. Note that some SOCKS client implementations like to use a static IP address in order to reach a distant and knowledgable DNS server. (I'm not advocating that approach.) > Running external, default-free routing on a UNIX box might be unusual, but > it doesn't sound impossible. > > I seem to recall that you and I had a difference of opinion about this, but > perhaps I'm wrong. My opinion is that in general, having hosts have routing > tables is a bad idea, since it means hosts have to track developments in the > routing protocols. Of course, a SOCKS box might be a place where you can > legitimately argue that it's OK; it is, after all, more or less a species > of gateway. It is often desirable to separate functions onto separate boxes for security or reliability. For example, I've recently argued that the box that Silicon Graphics uses to terminate the telephone line to one of its Internet providers should not be used for email and netnews. I think it would be a bad thing if a major internal SMTP and NNTP relay had to die every time my PPP code crashed, but you might argue that it would not be nice if a sendmail loop killed Internet connectivity. Still, the distinction between routers and hosts is fuzzy. Remember that a large minority, perhaps even a majority, of all of the IPv4 routers in use in the world (not just reachable from the Internet) are also hosts. There is no law of nature that says that your router cannot also have disks and a Fortran compiler, or that your host cannot have many network interfaces and understand all of IGRP, RIP, RIPv2, OSPF, EGP, and BGP. In small networks, using a single box for both routing and computing is often the best idea. If you are doing a purely software implementation of a routing protocol, I bet it's a lot easier to develop and debug on a host, even if the target product is a pure router. I've been doing some private interoperability testing of PPP lately, and have been amused by the hassles of people working on their dedicated routers. It's a lot more work if you don't have the development tools standard on UNIX boxes. Were any of the current major routing protocols not developed first on hosts? Except perhaps IGRP? I think tracking developments in routing protocols is easier on hosts than routers. Routers are developing more writable storage and remote update facilities, but a pile of EEPROM is still not the same as a GB or two of disk and the ability to ftp or rcp all or part of a release. This is irrelevant to the original issue. An installation consisting of a dedicated router and a host running a SOCKS server, with the host forwading through the router vai the Router Discovery protocol can still either use default routes or not, externally or internally. (If the host is your typical UNIX box and its IP stack knows about the router thanks to a default route installed in its kernel tables by the router discovery daemon, I don't think that qualifies as using or not using default routes.) Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 02:28:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02795; Wed, 30 Aug 1995 02:28:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA19881; Wed, 30 Aug 1995 02:27:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA19875; Wed, 30 Aug 1995 02:26:03 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02737; Wed, 30 Aug 1995 02:25:54 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzexd29715; Tue, 29 Aug 1995 12:25:53 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: ownership, leasing, renumbering, and that draft To: kre@munnari.OZ.AU (Robert Elz) Date: Tue, 29 Aug 1995 12:25:53 -0400 (EDT) Cc: smd@chops.icp.net, big-internet@munnari.OZ.AU In-Reply-To: <13971.809696570@munnari.OZ.AU> from "Robert Elz" at Aug 29, 95 09:42:50 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 640 Precedence: bulk With some of the renumbering methods (like NAT), it may make perfect sense for the customer to have control - thus the CPE box is ideal for that. The concern that I have with adding work to my backbone or customer-access boxes is that those boxes are under a fair amount of stress already. Adding additional work to these boxes that adversly effects the performance (mostly the main switching path) of these boxes is not really going to be practical. Note: I have this same concern about all proposals - how efficient can this proposal theoretically be and how efficient is the actual implementation. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 02:30:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02947; Wed, 30 Aug 1995 02:30:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA19901; Wed, 30 Aug 1995 02:30:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA19811; Wed, 30 Aug 1995 02:12:40 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02233; Wed, 30 Aug 1995 02:12:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00859; Tue, 29 Aug 95 12:12:32 -0400 Date: Tue, 29 Aug 95 12:12:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508291612.AA00859@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Non-congruent AAB's Cc: jnc@ginger.lcs.mit.edu Precedence: bulk Oh, one additional piece of complexity about "abstraction action boundaries" I forgot to pass on. My description of them assumed that you aggregate all A.* into A at one point. Of course, with "longest-match" technology, you don't have to do this. You could aggregate N separate routes for A.1 ... A.N into two routes, A.* and A.7, say. I call these "non-congruent AAB's" since the AAB's for all A.* are not identical. Doing this allows you to have your cake and eat it too, in terms of providing an even better balance of optimal routes and low routing overhead. If you are at a place where the best next-hop for all of A.* except A.7 is the same, you can express that in two routing entries, not a full set. Of course, deciding where to set non-conguent AAB's is an even tougher problem than setting congruent AAB's, since there are that many more possible configurations to choose from. Also, of course, use of N-C AAB's requires longest-match routing table lookups, not first-match, but we already have this. Noel From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 02:48:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03720; Wed, 30 Aug 1995 02:48:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA19954; Wed, 30 Aug 1995 02:47:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA19917; Wed, 30 Aug 1995 02:33:19 +1000 Received: from news.ti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03095; Wed, 30 Aug 1995 02:33:12 +1000 (from w-rolph@ds.mc.ti.com) Received: from ganesh.mc.ti.com ([157.87.4.175]) by gate.ti.com (8.6.12/) with SMTP id LAA06219; Tue, 29 Aug 1995 11:32:59 -0500 Received: by ganesh.mc.ti.com; id AA17644; Tue, 29 Aug 1995 12:32:08 -0400 Message-Id: <9508291632.AA17644@ganesh.mc.ti.com> X-Sender: a722756@mail-ad.mc.ti.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 12:32:08 -0400 To: Yakov Rekhter From: "W. Donald Rolph III" Subject: Re: renumbering Cc: big-internet@munnari.OZ.AU Precedence: bulk Sure! At 06:17 AM 8/29/95 PDT, you wrote: >Don, > >> I must admit to a lack of knowledge on IPv6. I can state that any procedure >> which requires continuous reconfiguring of the end users is doomed. You >> cant effectively get 1000 stations coordinated, much less 30 million. > >Would you be willing to reiterate your message wrt "any procedure which requires >continuous reconfigurating of the end users is doomed" on the big-internet mailing list ? > >Yakov. > > Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-236-1263 From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 03:08:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04510; Wed, 30 Aug 1995 03:08:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA20005; Wed, 30 Aug 1995 03:07:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA19980; Wed, 30 Aug 1995 02:51:45 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03842; Wed, 30 Aug 1995 02:51:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01116; Tue, 29 Aug 95 12:51:24 -0400 Date: Tue, 29 Aug 95 12:51:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508291651.AA01116@ginger.lcs.mit.edu> To: smd@chops.icp.net, swb1@cornell.edu Subject: Re: 1. core; 2. conformance Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Sean Doran metro addressing ... also requires complete willingness on the part of all providers to any carry traffic into a metro area they connect to, no matter which provider is the destination. Hmmm. As long as the traffic source is on the provider doing the long-haul work, is this a problem? I'd think the thing you want to prevent is cases like a source on provider C (for cheapskate :-) in metro M1 sending traffic to a destination in another metro M2, and C gives the traffic to provider G (for gullible) to carry there. (Heck, the destination doesn't have to be on a third provider at M2, it could even be on C too! :-) I thought about this for a while, and I thought I saw a way to make it work; G has to refuse to accept any traffic from other providers at M1 that is destined for other metros. Even if the destination customer at M2 is attached to G (which of course you can't know at M1), it has to get there on the carrier of the source. Of course, if the source is on carrier S (for small) which doesn't *go to* M2, then S has to do something. It might go to G and pay it to carry traffic for it to M2. The way to do this would be to have a private link from S to G (if it went through the metro-exchange, other people could jump on, unless you source-checked all the traffic) over which G will accept traffic for a list of metros which S has contracted with G to carry. What am I missing? if you wish to guarantee being charged on a per-packet basis, please encourage this model Of course, we may get a certain amount of usage-sensitive billing anyway, even with another adressing model. Noel From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 03:47:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06104; Wed, 30 Aug 1995 03:47:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA20075; Wed, 30 Aug 1995 03:47:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA20056; Wed, 30 Aug 1995 03:36:53 +1000 Received: from vnet.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05785; Wed, 30 Aug 1995 03:36:50 +1000 (from narten@VNET.IBM.COM) Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7782; Tue, 29 Aug 95 13:36:40 EDT Received: by RTP (XAGENTA 4.0) id 7985; Tue, 29 Aug 1995 13:36:01 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA16255; Tue, 29 Aug 1995 13:35:23 -0400 Message-Id: <9508291735.AA16255@cichlid.raleigh.ibm.com> To: asp@uunet.uu.net (Andrew Partan) Cc: bmanning@ISI.EDU, big-internet@munnari.OZ.AU Subject: Re: Benefits of Geographic examples In-Reply-To: (Your message of Tue, 29 Aug 95 11:55:41 D.) Date: Tue, 29 Aug 95 13:35:21 -0500 From: "Thomas Narten" Precedence: bulk >A note on renumbering: people do renumber this phones, even w/o >moving. Look at all of the new area codes that the US is adding. >[Typically there is a transition period of some 18 months for people >completely switch to their new phone number, and both numbers work >during that transition period.] Ha! See the business section in Monday's NYT. They have a timely article on the pains of renumbering phones that I found most amusing (seriousness notwithstanding). The one thing I note (with trepidation) is that everyone is suing everyone over the issue; folks don't want to lose their old numbers because the new ones don't work right 100% of the time (meaning, my business failed because customers stopped calling). It seems that phone companies haven't always had both the old and new numbers working simultaneously as is supposed to be the case. Another big problem is that area codes used to always have a 0 or 1 as a middle digit. No more. Many "older" PBXs can't dial to the new area codes without hardware/software upgrades. Sound familiar? Thomas From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 04:08:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06790; Wed, 30 Aug 1995 04:08:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA20116; Wed, 30 Aug 1995 04:07:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA20112; Wed, 30 Aug 1995 04:00:37 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06512; Wed, 30 Aug 1995 04:00:34 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.19] ([204.247.5.19]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA11632 for ; Tue, 29 Aug 1995 10:59:35 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 11:00:30 -0700 To: big-internet@munnari.OZ.AU From: Dave Crocker Subject: Re: Discussing encap/mapping proposal Precedence: bulk At 12:34 AM 8/29/95, Noel Chiappa wrote: >Topology-based-addresses can do more or less anything geographic addresses can >do, with more flexibility. (I except metro-addressing, since that contains a >mapping step which gives it even more flexibility.) More flexibility? From a sufficiently constrained technical view, perhaps. More pain and difficulty to the population of Internet users? Definitely! In fact, from THEIR view, provider-dependent addressing results in considerably LESS flexibility. As a matter of operational reality, the provider-dependent scheme doesn't provide flexibility for users or local providers, only for transit providers. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 04:09:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06811; Wed, 30 Aug 1995 04:09:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA20138; Wed, 30 Aug 1995 04:09:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA20109; Wed, 30 Aug 1995 04:00:07 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06498; Wed, 30 Aug 1995 04:00:03 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.19] ([204.247.5.19]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA11578 for ; Tue, 29 Aug 1995 10:59:05 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 11:00:00 -0700 To: big-internet@munnari.OZ.AU From: Dave Crocker Subject: Re: Discussing encap/mapping proposal Precedence: bulk Folks, At 1:23 PM 8/28/95, Noel Chiappa wrote: >I think you've just made my point. To paraphrase, until the recipients are >ready to decapsulate, you have to keep the old default-free table. In other >words, until a large enough proportion of the Internet has transitioned to the >new scheme, you have to keep the old one running. Which is what I said. Again this implies that somehow some magic was being otherwise suggested. It is a truism that transition requires conformance to the new scheme. For any part that does not conform, then use of the old scheme is necessary. As always, the conformance is only required of those wishing to interoperate with the new scheme. So (sigh) yes. When making the transition from the current global scheme with cidr to an alternative global scheme with Encaps, the global tables with cidr compression must continue to be used between any communicating pair that do no use the Encaps scheme. Subtle deduction, isn't it? d/ ps. one might observe that the transition for 'flat' netowrk assignments to the cidr scheme also requires support of flat network addresses until everyone conforms to cidr. But wait! There is also the possibility of having a cutoff scheme so that non-conformist won't be supported after a certain date, or of otherwise coercing sites... -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 04:11:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06858; Wed, 30 Aug 1995 04:11:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA20173; Wed, 30 Aug 1995 04:10:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA20095; Wed, 30 Aug 1995 03:52:19 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06207; Wed, 30 Aug 1995 03:52:15 +1000 (from dcrocker@brandenburg.com) Received: from [204.247.5.19] ([204.247.5.19]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA10544 for ; Tue, 29 Aug 1995 10:51:11 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Aug 1995 10:52:06 -0700 To: big-internet@munnari.OZ.AU From: Dave Crocker Subject: Re: IP Encapsulation Growth Proposal Precedence: bulk Folks, At 8:07 AM 8/29/95, Noel Chiappa wrote: > you might also then view this idea as architecturally clean and >Sigh. One thing I'd have though this whole debate would have taught people is >that archiectures which work fine at one order of scale don't always work well The implication of this response is that I -- or this approach -- somehow was missing such an issue. I (it) wasn't (isn't). One could, as easily, argue that the scale of impact for imposed, large-scale renumbering is a scaling problem vastly worse than in creating and deploying the encapsulation engines. A global scheme always has issues of scaling. Current cidr has much scaling benefit for transit providers and much scaling horror for end-users changing providers and, as always, for local providers who are multi-homed and/or change transit providers. Choose your poison. This is a complex issue and there must be some pain. The question is where to put it. > The only hard part -- and yes, it IS hard -- is to make sure that > the address resolution process is viable. > >Unless you are using terminology in a non-standard way, this is incorrect. To >use the WAN example, it's not translating the next-hop IP address to the WAN >MAC address (i.e. address resolution) that's so hard, it's picking the exit From the standpoint of architectural and algorithmic role, the view that the "lower layer" IP in the Encaps scheme is identical to a subnet or link layer is exactly and formally correct. The border routers of the NDZ are logically the next hop. This is all exactly like doing IP over x.25 rather than IP over IP. The destination x.25 address isn't the next x.25 packet switch, it is the LAST x.25 packet switch. I.e., the exit (border) packet switch. The fact that this particular subnet or link layer has yet-another below it is irrelevant to this discussion, except to the extent that it serves as a distractant. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 04:47:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08198; Wed, 30 Aug 1995 04:47:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA20262; Wed, 30 Aug 1995 04:47:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA20217; Wed, 30 Aug 1995 04:28:42 +1000 Received: from vnet.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07593; Wed, 30 Aug 1995 04:28:36 +1000 (from narten@VNET.IBM.COM) Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8951; Tue, 29 Aug 95 14:28:26 EDT Received: by RTP (XAGENTA 4.0) id 8002; Tue, 29 Aug 1995 14:26:26 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17095; Tue, 29 Aug 1995 14:26:32 -0400 Message-Id: <9508291826.AA17095@cichlid.raleigh.ibm.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: (Your message of Tue, 29 Aug 95 10:24:34 D.) <9508291424.AA00136@ginger.lcs.mit.edu> Date: Tue, 29 Aug 95 14:26:28 -0500 From: "Thomas Narten" Precedence: bulk >Seriously, I often wonder if the debate here is having any useful effect. If >it is, then I suppose I don't begrudge the time and energy (although I wish >there were more efficeint way to do this). I wonder, though... As someone who (naively!) thinks he understands the problem and more or less understands the proposed solutions, I think the vast chunk of this discussion consists of people talking past each other. Kind of like point/counterpoint. Certainly someone trying to figure out the issues is going to have difficulty wading through it all. What I think would be a *lot* more helpful is to put together a single summary of the issues, the possible approaches, and the pros and cons of the various approaches, and finally (and most important!), comparing the relative tradeoffs of the various approaches. There is no ideal solution. It's the relative tradeoffs of various schemes that need to be discussed. That's where the real issues are. That is, get some *facts* down in a single place where everyone can see them and everyone agrees as to what is being talked about. It would also help if common terminology was used. Too much of the discussion seems to result from different interpretations of what terms like "heirarchical addressing", "provider-based addressing", "core" (no you fool! there is no "core"!), etc. mean. Is this a lot of work? Maybe. But some folks are clearly already spending a lot of time posting messages. If that effort could be rechanneled... Case in point. Just *exactly* *what* is the immediate "CIDR problem"? Big routing tables? Just *exactly* what is the problem that "big routing tables" implies? Distributing updates? Recomputing new tables? Installing the new tables in the forwarding engines? Are some more important than others? Ooops, sorry. The *real* problem is that CIDR now (or was it always??) requires renumbering. Hmm. Does this requirement come from *CIDR* or is it *really* a result of the need to limit the number of routing table entries in the DFZ while at the same time keeping routing dynamic (e.g., quickly routing around failed links)? I'll bet if the question were asked, you'd get ten different answers plus a fair amount of head scratching. Without a clear understanding of the problem, it's hard to come up with solutions. Thomas From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 06:28:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12031; Wed, 30 Aug 1995 06:28:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA20814; Wed, 30 Aug 1995 06:27:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20791; Wed, 30 Aug 1995 06:11:09 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11183; Wed, 30 Aug 1995 06:11:06 +1000 (from bmanning@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Tue, 29 Aug 1995 13:10:55 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199508292010.AA14462@zephyr.isi.edu> Subject: Re: IP Encapsulation Growth Proposal To: SEAN@SDG.DRA.COM (Sean Donelan) Date: Tue, 29 Aug 1995 13:10:55 -0700 (PDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <950827015456.cf5@SDG.DRA.COM> from "Sean Donelan" at Aug 27, 95 01:54:56 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 952 Precedence: bulk > > What we really want is something that shows what all these filtering > policies are. Is there a place in the RADB to show you don't route > to prefixes longer than 18, 19, 24, whatever bits? Then when a > provider runs across a customer that doesn't want to renumber, the > provider can run a report against the RADB showing all the places on > the net they won't be able to reach. And a report showing all > the places they would be able to reach if they renumbered. The > customer and the providers can then make their own choices. Maybe > there is nothing on those parts of the net they care about, so they > won't renumber. > Yes, the RADB (and other sites in the IRR have this capability. It's called routing policy and there is a working group in the ietf devoted to the task of enriching the ways in which policy may be defined. (RPS-request@isi.edu) There are even prototypes of the whatif tools you are asking about. -- --bill From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 06:47:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12914; Wed, 30 Aug 1995 06:47:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA20859; Wed, 30 Aug 1995 06:47:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20839; Wed, 30 Aug 1995 06:35:21 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12270; Wed, 30 Aug 1995 06:35:04 +1000 (from bmanning@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Tue, 29 Aug 1995 13:34:52 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199508292034.AA15527@zephyr.isi.edu> Subject: Re: Discussing encap/mapping proposal To: rgm3@is.chrysler.com (Robert Moskowitz) Date: Tue, 29 Aug 1995 13:34:52 -0700 (PDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9508291224.AA03466@clncrdv1.is.chrysler.com> from "Robert Moskowitz" at Aug 29, 95 08:12:50 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 243 Precedence: bulk > > I finally got through all of the messages gened here over the weekend. > > Don't you people have a life? ;-} > From a cherished News Posting: "I'll get a life as soon as anyone shows me its better than what I have now." -- --bill From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 06:48:50 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12947; Wed, 30 Aug 1995 06:48:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA20885; Wed, 30 Aug 1995 06:48:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20855; Wed, 30 Aug 1995 06:41:57 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12587; Wed, 30 Aug 1995 06:41:52 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id NAA14079; Tue, 29 Aug 1995 13:41:48 -0700 Date: Tue, 29 Aug 1995 13:41:48 -0700 From: Tony Li Message-Id: <199508292041.NAA14079@greatdane.cisco.com> To: bmanning@ISI.EDU Cc: bmanning@ISI.EDU, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <199508292032.AA15398@zephyr.isi.edu> (bmanning@ISI.EDU) Subject: Re: Discussing encap/mapping proposal Precedence: bulk > If their percentage of active destinations has significantly > increased, then it is entirely reasonable to give them a _second_ > prefix, which might well be a /8 or /9. This is where I get confused. At this end of the addressing pond, its OK to hand out a second prefix whereas , if we change the values from /8 and /9 to, say /24 and /25, then panic sets in and we hear fussing and fuming wrt injection of additional prefixen. If a prefix covers 1/30,000th of the entire reachable (not allocated!) address space, then the overhead for carrying it is _entirely_ justified. To be brutally fair, we should set standards that apply to everyone, at all levels. If we ask a /25 to renumber (for what ever reason) then we should ask a /9 to do the same, for the same reasons. This IS a consistent standard. It simply says that we want to amortize the overhead of a route over "enough" sites that it makes sense. Tony From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 06:49:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12985; Wed, 30 Aug 1995 06:49:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA20907; Wed, 30 Aug 1995 06:49:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20836; Wed, 30 Aug 1995 06:33:13 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12225; Wed, 30 Aug 1995 06:33:09 +1000 (from bmanning@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Tue, 29 Aug 1995 13:32:56 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199508292032.AA15398@zephyr.isi.edu> Subject: Re: Discussing encap/mapping proposal To: tli@cisco.com (Tony Li) Date: Tue, 29 Aug 1995 13:32:56 -0700 (PDT) Cc: bmanning@ISI.EDU, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <199508291145.EAA26235@greatdane.cisco.com> from "Tony Li" at Aug 29, 95 04:45:50 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1158 Precedence: bulk > > > > Top down, lets say the DHCP lease on the /9 for Australia > > expires. How long then? > > > > Assuming that they still meet the aggregation conditions, why not > > simply renew it? > > Because Rupert has moved his new subsidiary MicroSloth, to Perth and now > Australia needs a /8. They -need- a new lease. > > If their percentage of active destinations has significantly > increased, then it is entirely reasonable to give them a _second_ > prefix, which might well be a /8 or /9. > This is where I get confused. At this end of the addressing pond, its OK to hand out a second prefix whereas , if we change the values from /8 and /9 to, say /24 and /25, then panic sets in and we hear fussing and fuming wrt injection of additional prefixen. To be brutally fair, we should set standards that apply to everyone, at all levels. If we ask a /25 to renumber (for what ever reason) then we should ask a /9 to do the same, for the same reasons. Or are we going to apply the pool rules. No diving in the 3` section, dive in the 12' section. (no renumbering in the /10 or greater, renumber below /14) -- --bill From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 07:09:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13381; Wed, 30 Aug 1995 07:09:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA20968; Wed, 30 Aug 1995 07:07:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20927; Wed, 30 Aug 1995 06:51:52 +1000 From: mulligan@future.incog.com Received: from ns.incog.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13034; Wed, 30 Aug 1995 06:51:46 +1000 (from mulligan@future.incog.com) Received: from coslabs.incog.com by incog.com (SMI-8.6/94082501) id NAA08943; Tue, 29 Aug 1995 13:51:16 -0700 Received: from future.incog.com by coslabs.incog.com (5.x/SMI-SVR4) id AA12255; Tue, 29 Aug 1995 14:51:25 -0600 Received: from future (localhost) by future.incog.com (5.x/SMI-SVR4) id AA04632; Tue, 29 Aug 1995 14:51:23 -0600 Message-Id: <9508292051.AA04632@future.incog.com> To: Robert Moskowitz Cc: "Roger Fajman" , big-internet@munnari.OZ.AU Subject: Re: firewalls and data integrity Reply-To: mulligan@incog.com In-Reply-To: Your message of "Tue, 29 Aug 1995 08:06:43 EDT." <9508291218.AA03394@clncrdv1.is.chrysler.com> Date: Tue, 29 Aug 1995 14:51:23 -0600 Precedence: bulk Robert Moskowitz wrote: > Correct about packet filtering firewalls. Orgs with low risks might use > them. Follow the firewalls list about their risks. Orgs that care about > risks will tend toward proxy firewalls of one sort or another. This certainly isn't true today. Many organizations that require high speed access, ie better than 56k or T1, use smart/dynamic/stateful packet screens rather than proxy relays. These packet screen don't incure the overhead of proxy relays and provide protection against the risks associated with simple packet filters. They also don't violate/break the end to end integrity provided by tcp and the applications aren't put at risk as in Dave's scenario. geoff From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 08:02:09 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15146; Wed, 30 Aug 1995 08:02:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04597 Wed, 30 Aug 1995 07:30:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA21014; Wed, 30 Aug 1995 07:27:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA20999; Wed, 30 Aug 1995 07:12:31 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13454; Wed, 30 Aug 1995 07:12:23 +1000 (from kre@munnari.OZ.AU) To: bmanning@ISI.EDU (Bill Manning), tli@cisco.com (Tony Li) Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Tue, 29 Aug 1995 13:32:56 MST." <199508292032.AA15398@zephyr.isi.edu> Date: Wed, 30 Aug 1995 07:11:42 +1000 Message-Id: <14116.809730702@munnari.OZ.AU> From: Robert Elz Precedence: bulk > > Top down, lets say the DHCP lease on the /9 for Australia > > expires. How long then? While you two are off explaining just how all of Aust can renumber or should, or could, or doesn't have to after all, and how long it will take etc ... Some reality, first Aust isn't an entity as far as networking is concerned, while it was, it is now becomeing as fragmented and disjointed as anywhere else. Comms prices are coming down, and desire for connections is going up, so there is a big opportunity for people to provide service - and what most customers want is to talk to all you nice people in the US (and the rest of the world) and not to other bozo Australians - so connections to the world are what is valued, not connections locally. Now I know that Aust was just used as an example here, my point in refuting it is that people keep assuming things like this mythical vision of a utopian Australia, where all routes aggregate, or could, actually might exist someday - they simply don't, and won't (or not anywhere with relatively free markets - this kind of policy might just save the Internet's routing tables were the PRC (aka China) to decide to connect in a big way). > > Assuming that they still meet the aggregation conditions, why not > > simply renew it? Well, before that, let's ask where the lease came from in the first place. That's kind of important. Assuming we are doing things in the new, supposed to be only, way of the future, then it would have come out of our providers addr block, wouldn't it - so they can aggregate it further (even if aggregating a /9, not that we would ever get that big a slice, even if we were united, isn't really required). Someone has to give out the lease, and people get them from their providers. Now, without mentioning any real names here, what follows is total fiction, no correspondence to anyone, living, dead, or incorporated intended or implied, let's assume Australia (or some part of it), is connected to the big bad network provider, and has our address lease from them. Since it is a lease, it has a time limit on it. Now say we decide to move from the big bad network to the mild and considerate internet, or perhaps sean's private robust internet. Now we don't have to renumber, we assume, to do that, as our aggregate is one of those considered "big enough" that it can be carried wherever we connect, we're a big important country after all (or a small irrelevant one, but a country nevertheless). However our lease comes from the big bad network, and they're now peeved at us for taking our (lucrative) business elsewhere, and they have decided to not renew our lease, or not renew it unless we move the connection back to them. What is our situation when that happens? All leases expire, you can't guarantee they will be renewed, just consider Hong Kong. Leasing is a very poor model when you want some kind of stability unless the term of the lease is longer than anyoen cares about (and perhaps not even then). If IP address leases had terms like that, they wouldn't help with renumbering at all, so they have to either have short terms or be revokable. That means no-one can ever be certain of not needing to renumber tomorrow, even if they don't shift providers. kre From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 08:07:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15401; Wed, 30 Aug 1995 08:07:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA21071; Wed, 30 Aug 1995 08:07:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA21061; Wed, 30 Aug 1995 07:58:00 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14843; Wed, 30 Aug 1995 07:57:57 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04498 Wed, 30 Aug 1995 07:23:07 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id OAA17146; Tue, 29 Aug 1995 14:20:33 -0700 Date: Tue, 29 Aug 1995 14:20:33 -0700 From: Tony Li Message-Id: <199508292120.OAA17146@greatdane.cisco.com> To: rgm3@is.chrysler.com (Robert Moskowitz) Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU Subject: Re: IP Encapsulation Growth Proposal Precedence: bulk Has anyone seen a multihomed site running SOCKS or NAT firewalls. Yes. It's trivial if you're able to build your own DMZ, multihome that DMZ and then touch your internal network in only one place. Tony From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 08:10:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15530; Wed, 30 Aug 1995 08:10:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA21098; Wed, 30 Aug 1995 08:09:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA21064; Wed, 30 Aug 1995 07:58:38 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14880; Wed, 30 Aug 1995 07:58:31 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05530 Wed, 30 Aug 1995 07:33:05 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id OAA17601; Tue, 29 Aug 1995 14:26:49 -0700 Date: Tue, 29 Aug 1995 14:26:49 -0700 From: Tony Li Message-Id: <199508292126.OAA17601@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: bmanning@ISI.EDU, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <14116.809730702@munnari.OZ.AU> (message from Robert Elz on Wed, 30 Aug 1995 07:11:42 +1000) Subject: Re: Discussing encap/mapping proposal Precedence: bulk Assuming we are doing things in the new, supposed to be only, way of the future, then it would have come out of our providers addr block, wouldn't it - so they can aggregate it further (even if aggregating a /9, not that we would ever get that big a slice, even if we were united, isn't really required). Someone has to give out the lease, and people get them from their providers. If we are to read and believe the draft, any significantly large amount of address space which will generate a single aggregate could get such a prefix from a registry. I would suspect that in this case, APnic would be appropriate. We might even point out that a /9 is larger than 1/30,000th of the ENTIRE IPv4 address space, so that such a prefix is effectively permanent. Tony From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 08:30:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16654; Wed, 30 Aug 1995 08:30:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA21170; Wed, 30 Aug 1995 08:30:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA21149; Wed, 30 Aug 1995 08:16:31 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB15881; Wed, 30 Aug 1995 08:16:16 +1000 (from kre@munnari.OZ.AU) Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06399 Wed, 30 Aug 1995 08:14:05 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: bmanning@ISI.EDU, big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Tue, 29 Aug 1995 14:26:49 MST." <199508292126.OAA17601@greatdane.cisco.com> Date: Wed, 30 Aug 1995 08:12:27 +1000 Message-Id: <14156.809734347@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Tue, 29 Aug 1995 14:26:49 -0700 From: Tony Li Message-ID: <199508292126.OAA17601@greatdane.cisco.com> If we are to read and believe the draft, any significantly large amount of address space which will generate a single aggregate could get such a prefix from a registry. I would suspect that in this case, APnic would be appropriate. You're back assuming that Australia is a unit. It's not, there are a whole bunch of independant groups, each of which would be getting their own address spaces, from somewhere. The chances that more than one or two of them would ever be 1/30000 of the IPv4 address space are not all that great. If they get prefixes from each other, they are not necessarily topologically relevant, in any case, this gives the current big providers a big market weapon "our numbers are secure, so yours are if you stay with us, but if you connect via them, they can't guarantee that their number lease will remain stable for more than a relatively short period, so you may have to renumber even without switching providers". That is going to go down real well amongst the people attempting to break into the market - especially once they determine that the policy that set this up was basically decided by a group comprised largely of the bigger providers. kre From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 11:54:29 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25112; Wed, 30 Aug 1995 11:54:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA21364; Wed, 30 Aug 1995 11:47:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA21358; Wed, 30 Aug 1995 11:44:11 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24772; Wed, 30 Aug 1995 11:42:43 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id SAA03487; Tue, 29 Aug 1995 18:41:57 -0700 Date: Tue, 29 Aug 1995 18:41:57 -0700 From: Tony Li Message-Id: <199508300141.SAA03487@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: bmanning@ISI.EDU, big-internet@munnari.OZ.AU In-Reply-To: <14156.809734347@munnari.OZ.AU> (message from Robert Elz on Wed, 30 Aug 1995 08:12:27 +1000) Subject: Re: Discussing encap/mapping proposal Precedence: bulk You're back assuming that Australia is a unit. It's not, there are a whole bunch of independant groups, each of which would be getting their own address spaces, from somewhere. The point is that all of them cooperate and get addresses as a unit and coordinate the aggregation they, as a delegating registry can control that prefix. This does obligate them to advertise the aggregate and (obviously) to have an interconnect somewhere. How and where is completely open. They may end up providing transit for each other.... Tony From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 16:32:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07367; Wed, 30 Aug 1995 16:32:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA21654; Wed, 30 Aug 1995 16:27:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA21637; Wed, 30 Aug 1995 16:11:14 +1000 Received: from cu.nih.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06351; Wed, 30 Aug 1995 16:10:48 +1000 (from RAF@CU.NIH.GOV) Message-Id: <9508300610.6351@munnari.oz.au> To: big-internet@munnari.OZ.AU From: "Roger Fajman" Date: Wed, 30 Aug 1995 02:09:01 EDT Subject: Re: ownership, leasing, renumbering, and that draft Precedence: bulk > With some of the renumbering methods (like NAT), it may make perfect > sense for the customer to have control - thus the CPE box is ideal for > that. > > The concern that I have with adding work to my backbone or > customer-access boxes is that those boxes are under a fair amount of > stress already. Adding additional work to these boxes that adversly > effects the performance (mostly the main switching path) of these boxes > is not really going to be practical. > > Note: I have this same concern about all proposals - how efficient can > this proposal theoretically be and how efficient is the actual > implementation. > --asp@uunet.uu.net (Andrew Partan) Are you saying that your customer-access routers could not be upgraded or divided? Yes, the customer would pay for this in the form of higher rates, but the customers who have to renumber also pay for that. From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 21:31:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19002; Wed, 30 Aug 1995 21:31:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA21939; Wed, 30 Aug 1995 21:27:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA21922; Wed, 30 Aug 1995 21:23:44 +1000 Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18734; Wed, 30 Aug 1995 21:23:25 +1000 (from hcb@clark.net) Received: (hcb@localhost) by clark.net (8.6.12/8.6.5) id HAA21857; Wed, 30 Aug 1995 07:23:11 -0400 From: Howard Berkowitz Message-Id: <199508301123.HAA21857@clark.net> Subject: (User) Environmental Impact of Renumbering To: big-internet@munnari.OZ.AU Date: Wed, 30 Aug 1995 07:23:10 -0400 (EDT) Cc: hcb@clark.net (Howard Berkowitz) X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 15243 Precedence: bulk We have been having a lively discussion of the implications of various addressing and routing schemes. The list discussion, however, is appropriate for experts in routing and addressing. Many of the details are relevant to the [political incorrectness warning] "core," "DFZ," or other area essential to the proper organization of the global Internet, but of little concern to user organizations that connect to it. A large and growing number of Internet users, however, have simple connectivity. They may simply have registered addresses and no active Internet connectivity, or a simple single-homed static route to a local ISP. These users rarely have routng experts, but they need to plan for the future. Their procurement and deployment resources often are less than even a small ISP, so they need to be thinking now about changes they will need to make in the near and moderate term. I have tried, in this note, to identify a strategy that helps small users put the infrastructure in place to deal reasonably with address changes, even though we cannot now describe the exact scope of the changes. We do know, however, that at least some change will be needed. I encourage comment, but please remember that this note is intended to help the simple user case, not the small or large provider. I hope that it will provide reality testing for minimizing the impact of renumbering proposals. I suggest, therefore, that a document is needed for user planning. Perhaps this is a BCP; perhaps there needs to be a new class of practice Informational RFC for those not conerned with the details of Internet architecture. I have not written a formal I-D before, and welcome guidance on the best way to get this proposed document into the formal stream of information. Howard ------------- Network Working Group H. Berkowitz PSC International Best Planning Practices: Impact of Evolution in Internet Addressing STATUS OF THIS MEMO This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 2. OVERVIEW This note offers planning guidance to user organizations that may need to use Internet Protocol (IP) addreses, and wish to minimize the impact of ongoing developments in the internal addressing and routing architecture of the global Internet. It is intended for publication as a Best Current Practices official IETF document. Recent technical design documents are concerned with evolution in the use of Internet addresses in the overall Internet architecture. Controversial technical issues are involved, but a common theme is that "public" addresses may be subject to change as the operational environment changes. Various schemes, such as "metro-based" or "provider- based" addressing are being discussed, with the primary emphasis of these discussions being the detailed "core" router changes needed to make them real. Much less attention has been paid to the specific changes that "edge" users will need to make to support ANY means of renumbering. Customer efforts will vary depending on the connection strategy used by their provider. Some providers completely control the router at the customer site that connect that site to the Internet, while others give significant operational responsibility to the user. This document emphasizes the changes that renumbering will incur primarily on the customer boxes "beyond" the provider gateway. It deals to a lesser extent with configuration changes in that gateway. Again, this document deals with planning for the user with simple connectivity needs. Such users numerically are a large portion of Internet Protocol users, even though they may not offer the greatest technical challenge. Such users have attributes including: --- Single point of attachment to the Internet (i.e., not multihomed) --- Do not exchange BGP with ISP --- Do not provide Internet transit services (i.e., true user organizations, not small ISP's). The key to minimize the user impact of potential changes in Internet addressing methods is to minimize the number of places in the user network where "hard-coded" addresses are stored. There are a few principal places where hard-coded addresses are used in common practice: 1. Workstations learning their own addresses 2. Workstations learning the address of servers 3. Servers learning their own address These are not the only requirements for addresses, but solving these requirements will handle the bulk of work. Other potential places where changes are needed include: 4. Router interfaces 5. Network management Sections below deal with techniques for each of these categories of need. An important distinction is whether the user applications need a "public" or a "private" address. RFC1597 introduces the idea of public vs. private. Public addresses are part of the global IP routing system, and may change as routing technology and operations change. Prudent users should plan for such change. The key to minimizing user impact is for user organizations to understand their requirements for "public" addresses in the global addressing system. If public addresses are needed, then Best Current Practice suggests that user network managers take immediate steps to mimimize the effects of likely address changes on their organizations. Requirements for renumbering are controversial among Internet architects. Nevertheless, it is sufficiently likely that user network design should proactively provide mechanisms for mimimizing the effects of renumbering. Users need to identify the impact of renumbering on their environments. It is a practical reality that some users will have thousands of hosts with "hard-coded" IP addresses. Not all of these hosts, however, need to be renumbered if external numbering conventions change. 3. REQUIREMENTS ANALYSIS Two documents define various functional requirements for Internet connectivity. RFC1597 discusses classes of applications that can use "private" address space. RFC1775 discusses user-oriented perspectives as to what it means to be "on" the Internet. The first RFC emphasizes address requirements, while the second is consciously at a higher level of abstraction, dealing with applications rather than addressing. 1597 focuses on hosts that need IP addresses that are not connected to the Internet, while RFC1775 deals in part with determining if an IP address is needed at all. Another working document, draft-ietf-idr-autosys-guide- 03.txt, deals with the question of when a user needs to participates in the complexities of Internet exterior routing. Private addresses can be "hard-wired" into workstations, routers, and servers. This is "real-world" but not desirable. Building on the RFC1775 and RFC1597 categories, we have a set of IP usage categories that might be used for an user inventory: Class IP Address Address "On the Typical Internet Needed Source Category Usage 1 Public Local or Full Public LAN server server 2 Temp.public Local or Client Client LAN server for public applications (LAN based) 3 Temp.public Local or Client Client Dial server for public applications (Telecommuter) 4 Private Firewall Client IP appl. via firewall 5 No --- Mediated Non-IP terminal 6 No --- Messaging Non-IP terminal 7 Private Lccal Not on Private LAN fixed or IP client temporary 8 Private Local Not on Private dial fixed or IP client temporary 9 Private Local fixed Not on Embedded system 10 Private Local Not on Private router 4. ADDRESS SOURCES Several sources of addressing are available to these need categories. Applicable sources differ on whether an IP host needs its own address or needs some other host's address. 4.1 OWN ADDRESS Hosts in Classes 1 and 2 should obtain IP addresses from BOOTP/DHCP hosts with a block of public addresses. Typically, Class 1 hosts will obtain a fixed address at initialization time, or obtain an address from a pool only if the Class 1 host can register the acquired address in DNS. Users will find that Class 1 hosts are likely to have locally configured IP addresses. Class 3 hosts will be similar to Class 2, although the source of the address is more likely to be PPP negotiation than Class 2. Many current accesses of this type use a fixed address defined by their provider. This may be fairly transparent if the provider registers the provider-furnished addresses in a provider-operated DNS data base that is publically available. 4.2 SERVER ADDRESSES Legacy clients may have hard-coded server addresses, which is undesirable if renumbering is a possibiity. The preferred approach is to have clients request the current addresss of a server from an appropriate directory service, typically DNS. For some high-performance transaction processing, the directory may be the portmapper service. Special user routing considerations may apply if the directory service is not on the same medium as the client. Arbitrary DNS queries often are sent as UDP/IP broadcasts, which do not propagate beyond the local router interface. On initialization, servers should obtain addresses from appropriate servers, much as do Class 1 and 2 user hosts. 4.3 END HOST-ROUTER INTERACTIONS There are two main ways in which end hosts interact with routers. In the first, the "default gateway" method, end hosts are hard-coded with the address of a specific router IP address. This address is assumed to be on the same medium as the end host. The second major method is "proxy ARP," in which the end host broadcasts a MAC-level request for a MAC address for the destination. If the desired host is on the same medium as the requesting host, the destination answers directly. Otherwise, a router containing a route to the destination host's subnet will answer as if it is the desired host. Hard-coded default router addresses should be avoided. End hosts should issue ARP requests when attempting to determine the medum address associated with an arbitrary destination. In general, routers should have proxy ARP enabled. Exceptions may exist for extensions that provided fault tolerance with a "virtual address." 4.4 ADDRESSES IN ROUTERS Current technology generally will require manual reconfiguration of router addresses when addresses change. If router configurations are stored as text files, appropriate substitution tools can change prefixes. Routers will need addresses for external public connectivity, and for connectivity to internal machines with public addresses. If the enterprise uses both public and private addresses, it is desirable that the router filter private addresses both from and to the external Internet. Routers will need to be configured with the IP addresses of DNS, BOOTP/DHCP, and other servers that clients may address with broadcasts. It may be appropriate to define these services by name in the DNS. If the router can act as a DNS clent and route to a name, router-specific renumbering is reuced. Otherwise, it may be possible to write configuration scripts using names, which are run through a preprocessor that looks up names in the DNS database. 4.5 BASTIONS AND NETWORK ADDRESS TRANSLATORS Bastion host components of firewalls may map between public and private addresses, or between public "protected" and public "unprotected" addresses. In general, if the user has deployed a component that has address mapping capability, use of private address space within the protected environment should be encouraged. For configurations to remain in the range of simplicity covered by this document, the address translating devices should be at the single point of attachment from the user to the Internet. 5. NETWORK MANAGEMENT 5.1 BASIC CONNECTIVITY TOOLS Basic connectivity tools such as ping and traceroute have specific IP address arguents. It will be necessary to learn assigned addresses to use them. Since these tend to be used for ad hoc troubleshooting by trained networking personnel, persistent IDs are probably not needed. People that use these tools should be able to understand the process of address assignment, and should be able to manually discover assigned addresses. 5.2 SNMP MANAGEMENT Use of SNMP tools in an environment in which addresses change is more complex than using simple connectivity tools. In principle, instances of MIB object can be identified by systemID strings rather than IP addresses. In practice, managed objcts are accessed by IP address, and long-term statistics are frequently indexed by IP address. Alternative mapping mechanisms will be needed for meaningful long-term statistical tracking. It may be appropriate to log renumbering events and correlate them to the times that SNMP samples are taken. 6. SECURITY CONSIDERATIONS This document does not explicitly address security considerations. Incorrectly implemented renumbering can cause parts of a network to be unreachable, resulting in denial of service. Other renumbering areas can lead to inappropriate exposure of data to disclosure or alteration. 7. AUTHOR'S ADDRESS Howard C. Berkowitz PSC International PO Box 6897 Arlington VA 22206 Voice (703)998-5819 Fax (703)998-5058 hcb@clark.net From owner-Big-Internet@munnari.OZ.AU Wed Aug 30 22:31:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21246; Wed, 30 Aug 1995 22:31:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA22039; Wed, 30 Aug 1995 22:27:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA21990; Wed, 30 Aug 1995 22:08:52 +1000 Received: from panix3.panix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20466; Wed, 30 Aug 1995 22:08:44 +1000 (from hal9001@panix.com) Received: (from hal9001@localhost) by panix3.panix.com (8.6.12/8.6.12+PanixU1.1) id IAA28753; Wed, 30 Aug 1995 08:08:35 -0400 X-Sender: hal9001@popserver.panix.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Mac Eudora Pro 2.1.3 Date: Wed, 30 Aug 1995 08:08:33 -0400 To: Tony Li From: "Robert A. Rosenberg" Subject: Re: Discussing encap/mapping proposal Cc: kre@munnari.OZ.AU, bmanning@ISI.EDU, tli@cisco.com, big-internet@munnari.OZ.AU Precedence: bulk At 14:26 8/29/95, Tony Li wrote: >We might even point out that a /9 is larger than 1/30,000th of the >ENTIRE IPv4 address space, so that such a prefix is effectively >permanent. Unless my figures are off, a /9 (Sub-Mask 255.128.0.0) is 1/512 of the ENTIRE IPv4 address space. From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 03:51:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04259; Thu, 31 Aug 1995 03:51:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA22512; Thu, 31 Aug 1995 03:47:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA22497; Thu, 31 Aug 1995 03:38:23 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03832; Thu, 31 Aug 1995 03:37:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04077; Wed, 30 Aug 95 13:32:40 -0400 Date: Wed, 30 Aug 95 13:32:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508301732.AA04077@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: "Provider-based addresses" is bad terminology Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Draw a picture, of a few dozen nodes connected by arcs. Draw a circle around a small group of nodes; that's .. your test aggregate. ... go through all the nodes, marking all the ones where the first hop to all the nodes in the aggregate is the same ... If you draw a line which encloses all the unmarked nodes, you have drawn an AAB which results in hierarchical routing producing *exactly* the same routes as flat routing. BTW, to show yourself that addressing hierarchies *are* isomorphic to topologies, try deleting a link near (or inside, if it won't partition it) the aggregate. Redo the exercise. Probably the optimal AAB has changed shape... Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 04:30:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06865; Thu, 31 Aug 1995 04:30:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA22586; Thu, 31 Aug 1995 04:27:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA22552; Thu, 31 Aug 1995 04:09:51 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05452; Thu, 31 Aug 1995 04:09:46 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04455; Wed, 30 Aug 95 14:08:53 -0400 Date: Wed, 30 Aug 95 14:08:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508301808.AA04455@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: Benefits of Geographic examples Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Steve Deering "The best way to predict the future is to invent it." Ah. Ever hear of "The Law of Unintended Consequences"? I first ran across this, at least stated in explicit form, in that wonderful book, "In Search of History", by T.H. White. Basically, the future is never what you strive for it to be, and often goes in exactly the opposite direction. The thing that brought it home to him was the decay of his boyhood neighbourhood in Boston, despite the masive efforts of social planners to halt and reverse the decay. Examples are legion: I imagine the Serbs from Croatia could tell you about it too. Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 04:33:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06999; Thu, 31 Aug 1995 04:33:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA22610; Thu, 31 Aug 1995 04:30:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA22571; Thu, 31 Aug 1995 04:19:30 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05984; Thu, 31 Aug 1995 04:17:59 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.49] (dial-cup2-28.iway.aimnet.com [204.118.88.58]) by aimnet.com (8.6.12/8.6.12) with SMTP id LAA21339; Wed, 30 Aug 1995 11:15:26 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Aug 1995 11:16:22 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: "Provider-based addresses" is bad terminology Cc: big-internet@munnari.OZ.AU Precedence: bulk At 10:55 PM 8/28/95, Noel Chiappa wrote: > Noel, yes, I mean something along the line of Steve's metro-addressing. > >Ah, well, as far as I'm concerned the salient points of Steve's scheme were a >three part organization, with the middle field >mapped (with a scope local to a given metro) to a provider, via a mapping >table. If yours is different, you need only point out the differences. FWIW, I believe that my use of the term "geographic" and Steve's term "metr"o are the same models and probably the same details. (As in, he HAS details and I wasn't formulating any yet.) I believe his details match the original work our group did, lo these 2 years ago or so. As to your reference to a "mapping" table, this is probably both formally correct and functionally distracting. A router has a concept of stuff within its immediate sphere and stuff that is distant. Aggregation pertains to distant stuff. Fully-elaborated detail is required for local. If the actual geographic bits have a hierarchy to them -- as they will for IPv6 -- then the rules of their use look the same as for any other assignment scheme to be used in a CIDR mechanism. The more remote the reference, the fewer of the initial bits are needed to accomplish aggregation (and, presumably, the greater the aggregation.) In any event, eventually one gets down to the referenced geographic region. The next level of reference is site, or organization, or whetever other term you want to use. There is no semantic information to distinguish one site id from another; it's just a serial assignment. All provider routers within a region will need to list all of the sites within that region, independent of provider. All of them. Each of these entries will then have the usual sort of routing information needed to get from that router to the last one before the user. I believe there is no particular benefit or requirement for the 'mapping table' to be distinct from the usual local routing detail or even to know that there is an issue in crossing provider boundaries. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 05:29:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10586; Thu, 31 Aug 1995 05:29:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA22699; Thu, 31 Aug 1995 05:27:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22680; Thu, 31 Aug 1995 05:11:01 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09224; Thu, 31 Aug 1995 05:08:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04778; Wed, 30 Aug 95 15:06:40 -0400 Date: Wed, 30 Aug 95 15:06:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508301906.AA04778@ginger.lcs.mit.edu> To: kre@munnari.OZ.AU, tli@cisco.com Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li [Warning: this too seems to be long. More coffee.] Actually, now that I think about it, neither coffee nor amphetamines are really what's indicated here. I've been considering if cyanide is it.. :-) anyone who aggregates a sufficient amount of IP address space .. need not aggregate further ... within such an aggregate, what you do is your own damn business. Umm, Tony already know this, but to make it clear to everyone, to the extent that routes to pieces of that aggregate are seen outside the aggregate, what goes on inside may be of some concern outside. Of course, if the scope of that internal info is samll, yes, the rest of us outside that scope don't care. Assuming hierarchical aggregation, we can extend this further down, such that each level has flat routing its level, and default pointing up one level. I.e. what some people call "strict" hierarchical routing. (Extra credit discussion: Some people define strict hierarchical routing so that all nodes have to have info on the best route to a minimal subset of higher level entities as well. I.e. router A.P.X which is not a border router of A.P would have to have routing table entries for * and A.* as well as A.P.*. If this is not done, the higher level routers have to form a contiguous backbone; i.e. no transit traffic, i.e. sending traffic from A.Q to A.R across the A.P area...) Note that this does NOT preclude all cases of mandatory numbering. If you renumber between higher level aggregates, then that's a problem. I think what you meant to say there was that if you *move* between higher level aggregates, you have to renumber. However, it does provide a local (topological) scope in which changing providers does not require renumbering. For a concrete example of this, for those who couldn't penetrate the jargon, if you're attached to provider P1, who has addresses of the form A.X.P1, and your address is of the form A.X.c, then you can switch to provider P2, who happens to have addresses of the form A.X.P2, without changing addresses; but *not* to provider P3, who has addresses of the form A.Y.P3. At least, not in a system using strictly hierarchical routing. If you allowed routes to A.X.c to flood throughout region A, you could allow A.X.c to connect up to A.Y.P3, although everyone else in region A would pay the price in extra routign overhead. Note, however, that this is still less costly than if you switched to provider P4, who had addresses of the form B.P4; if you do that, a route to A.X.c is going to have to be flooded pretty much globally. I realize that Noel may be the only one who has followed me this far, :-) Thanks for the vote of confidence, but I would be interested to know what % of the Big-I readers do follow this. I assume it's more than 1%, and less than 100%.... I'll fully admit that I don't know how to explain this well enough to the providers and the registries and the end users such that they all make reasonable engineering choices and don't simply cause the Australian backbone to implode in two years. I see one of the big challenges, down the road, for the Internet, is to get smarter about i) designing actual connection topology, and ii) designing addressing hierarchies to provide "reasonably good" routing with reasonably low routing overhead. The social engineering of bringing the mass of users up to speed on topologically significant routing is daunting, nay, intractable given the observable social conditions. WARNING: all the discussion up till now has been in what are called "mono- metric" systems; i.e. we're only looking at one thing, such as hop count. When we get to multi-metric routing (QOS, complex transit policies, etc, etc), the current stuff is trivial (in the strict mathematic sense, and I'm not kidding). The more hierarchy that we can install at the higher layers, the less we need from the lower layers. And the less that happens at the lower layers, the flatter things at the bottom can be, thus allowing less renumbering. Hmm. I have to think for a while, but I wonder if more more heirarchy at the top levels isn't a problem, in the sense that the top then becomes more sensitive to topolgoy changes. The bug there, of course, is that changes in the address structure at the higher layers will have wider impact. Engineering more hierarchy in is a serious problem because address assignment and current allocations aren't set up the right way. Right, the registries (and I'm *not* trying to beat up on them) aren't (and never have) looked at maps of the network topology before giving out numbers. So the major problem with this is that I don't see how to get there from here. ;-) Does the expression "massive pain" mean anything to you? :-) Seriously (before people start quoting me), I think the solution is to slowly renumber older sites over time, perhaps as they switch providers, etc, into a more rational numbering plan. What this plan would look like is hard to say. One thing I think is true is that in a mono-metric system (thank goodness for small favours :-) it doesn't much matter where you put the boundaries, as long as they do not produce partitioned areas. (I.e. you don't have to put boundaries around parts of the net that are richly connected within the area, and poorly connected across the area boundary.) So, perhaps the CIDR blocks given to Europe, etc, will actually work as very-high-level agggregates, if we assume that the networks numbered out of those blocks do not form partitions in the topology. We'll see... In fact, in many cases, it will be MORE draconian I think that as the network grows, the need for reasonable abstraction boundaries will grow. Above the subnet level, we just don't have very much of that right now. there are other dimensions within CIDR which are other perfectly acceptable means of achieving the same goals. If folks are so distressed at the thought of mandatory renumbering on changes, then perhaps they are willing to put more enginering energy into local aggregation. Hmm. I'm not sure I'd put it quite that way. The overall goal is to minimize the routing overhead, both in terms of mechanical (space, time, etc) as well as human (configuration). Continued use of non-aggregatable addresses, especially small blocks (which are bad only in that there are potentially many more of them), will raise the overhead. Whether this comes from use of old network numbers that don't aggregate, people moving, whatever, it's all the same. One thing that probably would help is some attention to topology engineering, so that e.g. larger organizations can move within a limited scope without renumbering. Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 12:28:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29059; Thu, 31 Aug 1995 12:28:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA23118; Thu, 31 Aug 1995 12:27:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23101; Thu, 31 Aug 1995 12:18:03 +1000 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB28392; Thu, 31 Aug 1995 12:17:57 +1000 (from swb1@cornell.edu) Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id WAA14268 for ; Wed, 30 Aug 1995 22:17:09 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Aug 1995 22:17:31 -0400 To: big-internet@munnari.OZ.AU From: Scott W Brim Subject: Re: Discussing encap/mapping proposal Precedence: bulk At 07:28 08/29/95, Robert Moskowitz wrote: >Would this still hold true if the only multihoming is at established 'NAP's? >In otherwords. Only those providers that can afford to hookup to and peer >at NAPs can multihome. All others cannot. The only reason multihoming is an issue is because customers apparently do not feel that they can depend on a single provider to be reliable enough for them. Your idea would severely limit the amount of multihoming, since customers wouldn't be able to afford it, but allowing customers to make cost-effective use of the Internet would seem to be an important goal. Multihoming is the appearance of a single (probably aggregated) entity at two different points in the address space -- let's call it multiple "appearances". In a hierarchical routing scheme the distance that two appearances need to be propagated separately by routing will depend on (1) how much of a prefix the two appearances have in common, and (2) whether you want to promote or suppress separate paths to the different appearances for other reasons. As Noel says, multihoming can be supported in a provider-based scheme -- but at the cost of extra routing overhead, and the whole point is to reduce the amount of routing information being propagated. Therefore we have a goal of not propagating multihoming information very much or very far. The concepts of (1) basing hierarchical addresses on providers, (2) supporting multihoming between providers, and (3) limiting propagation of multihoming information between providers -- are in direct conflict. Provider boundaries would be address space boundaries. If your multihoming is between topologically "local" providers which all hang off the same larger provider then the extra information need not propagate very far -- it can be merged at the larger provider. However, that's not what customers want to do. They want redundant independent connectivity over large areas. That means having "appearances" in larger providers' chunks of the address space, which makes the prefix shared between the multihoming appearances shorter, and in general leads to further propagation of the information if it is to be useful in meeting the customer's need. OK, so you just tell the customers they can't have the multihoming they want? That would be nice, BUT the Internet is now commercially important, and the level of Internet reliability which customers require has gone up faster than the level of reliability which the providers are giving them, such that now many (an increasing number of) customers seem to think they must have the redundancy that multihoming between providers gives them. That is, because of the way the Internet is run, multihoming is now a business necessity. An alternative possibility is that, at least within the areas which impact "core" routers, you put multihoming and the address space along different dimensions. I didn't phrase that well, but forget it, this is turning into a Noelgram. Specifically, within the "core" you could route NOT by provider but by geography. Thus, within the "core" whether you are multihomed to different providers or not, you would be included in one address prefix, a geographic one, reachable by multiple providers. This does not cover the case where an organization wants to be multihomed in widely separated geographic locations. I assert there are a lot fewer of those than there are organizations which want to be multihomed on independent providers. Geographic addressing has problems and advantages which have been/are/will be discussed and dealt with elsewhere. My main -- in fact, only -- concern is that we must not mandate an architecture which puts the providers' capabilities in direct conflict with the users needs, and operationally it appears that the users must have multihoming between independent providers in order to get the Internet to do what they want and deserve. The provider-based hierarchical addressing plan feels unsupportable for that reason, regardless of whether a (optionally hybrid) geographic scheme will work or not. This mail is not a claim that a geographic scheme is the answer. It IS a claim that provider-based addressing may have looked good once, but the Internet and its users have changed, and now its problems outweigh its benefits. ...Scott From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 15:08:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07145; Thu, 31 Aug 1995 15:08:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA23271; Thu, 31 Aug 1995 15:07:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA23252; Thu, 31 Aug 1995 14:47:40 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06155; Thu, 31 Aug 1995 14:47:26 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA24190 Thu, 31 Aug 1995 14:28:48 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.14] (dial-cup2-29.iway.aimnet.com [204.118.88.59]) by aimnet.com (8.6.12/8.6.12) with SMTP id VAA18311; Wed, 30 Aug 1995 21:25:17 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Aug 1995 21:26:14 -0700 To: Scott W Brim From: Dave Crocker Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 7:17 PM 8/30/95, Scott W Brim wrote: >mail is not a claim that a geographic scheme is the answer. It IS a >claim that provider-based addressing may have looked good once, but the >Internet and its users have changed, and now its problems outweigh its >benefits. Scott, I think your comments were quite well formulated and stated. I suggest, however, that they seem to be on the wrong list. Given that your note pertains to the use of cidr, I would think that it should be discussed within the working group responsible for considering cidr deployment. It doesn't make sense to get better at deploying something that simply shouldn't be deployed. Now it's clear that there are participants in that wg who think that any negative comments should be moved to another list. I'm sure, however, that when the cidrd wg chair started the thread on this list, he did not intend to ALSO move discussions that were pointedly relevant to cidr deployment. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 15:30:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08183; Thu, 31 Aug 1995 15:30:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA23321; Thu, 31 Aug 1995 15:27:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA23313; Thu, 31 Aug 1995 15:26:55 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07977; Thu, 31 Aug 1995 15:26:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27156 Thu, 31 Aug 1995 15:25:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06165; Thu, 31 Aug 95 01:22:37 -0400 Date: Thu, 31 Aug 95 01:22:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508310522.AA06165@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, tli@cisco.com Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > anyone who aggregates a sufficient amount of IP address space .. need not > aggregate further ... within such an aggregate, what you do is your own > damn business ... each level has flat routing its level to the extent that routes to pieces of that aggregate are seen outside the aggregate, what goes on inside may be of some concern outside. ... perhaps the CIDR blocks given to Europe, etc, will actually work as very-high-level agggregates, if we assume that the networks numbered out of those blocks do not form partitions in the topology. We'll see... It suddently struck me (in line with your Australia example, and the comments above) that there *is* a darn good reason for not doing flat routing inside such a chunk of the topology. To put it in (concise but abstract) technical terms, flat allocation of addresses inside a large-scale abstraction will make it more expensive to extend the "abstraction action boundary" of that abstraction to gain more optimal routes by better entry-point selection for traffic inbound to that abstraction (for a given degree of improvement in optimality, of course). To put it in terms which the average human can understand, let's go back to the Europe example above. You're at a US router, and you have traffic for someplace in Europe. You have your choice of several transatlantic links, which wind up connected fairly widely apart in Europe. If you want to pick the link which will drop the packet off closest to its eventual destination, you have to know something about how close each one is to the place in Europe where your packet wants to go. If addresses inside Europe are allocated in fairly random (i.e. flat) fashion, the only way for you to know this is to have information (i.e. arouting table entry) for each one of those pieces individually. This will be more expensive than the alternative, which is to assign the addresses in Europe into larger topological aggregates, so that you can get some information about how close things are to the exit of each trans-Atlantic link with a lot fewer routing entries. So, there is a price to pay for doing whatever you want in terms of address allocation inside a large piece of the topology. Don't. (Not even trained professionals... :-) In fact, now that I think about it, anytime you allocate addresses in a way which isn't maximally correlated to topology (i.e. anytime you assign A.1 and A.2 to things which aren't next to one another), you are making the routing more expensive, in return for....... nothing at all. Zip. Nada. To paraphrase that fine old movie, "Reefer Madness" (not to mention Dave Moon): "Address portability madness: A moment of convenience, a lifetime of non-optimal routes." Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 15:50:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08982; Thu, 31 Aug 1995 15:50:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA23356; Thu, 31 Aug 1995 15:47:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA23341; Thu, 31 Aug 1995 15:36:06 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08406; Thu, 31 Aug 1995 15:35:26 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA15487; Wed, 30 Aug 1995 22:34:55 -0700 Date: Wed, 30 Aug 1995 22:34:55 -0700 From: Tony Li Message-Id: <199508310534.WAA15487@greatdane.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU, tli@cisco.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9508310522.AA06165@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: Discussing encap/mapping proposal Precedence: bulk So, there is a price to pay for doing whatever you want in terms of address allocation inside a large piece of the topology. Don't. (Not even trained professionals... :-) But we should also point out that extending the abstraction action boundary is of finite, and perhaps affordable cost. I will certainly agree that hierarchy within the large aggregate will also reduce this cost. We also know that flat routing within a large aggregate will eventually cause scaling problems within the aggregate itself. Tony From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 16:10:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09864; Thu, 31 Aug 1995 16:10:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA23395; Thu, 31 Aug 1995 16:07:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA23391; Thu, 31 Aug 1995 16:03:16 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09512; Thu, 31 Aug 1995 16:01:49 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA16269; Wed, 30 Aug 1995 23:01:29 -0700 Date: Wed, 30 Aug 1995 23:01:29 -0700 From: Tony Li Message-Id: <199508310601.XAA16269@greatdane.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: kre@munnari.OZ.AU, tli@cisco.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9508301906.AA04778@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: Discussing encap/mapping proposal Precedence: bulk Note that this does NOT preclude all cases of mandatory numbering. If you renumber between higher level aggregates, then that's a problem. I think what you meant to say there was that if you *move* between higher level aggregates, you have to renumber. Yes, exactly. Thank you. I see one of the big challenges, down the road, for the Internet, is to get smarter about i) designing actual connection topology, and ii) designing addressing hierarchies to provide "reasonably good" routing with reasonably low routing overhead. Especially given that "reasonably low" is a moving target, and that the budget is not "extremely low". When we get to multi-metric routing (QOS, complex transit policies, etc, etc), the current stuff is trivial (in the strict mathematic sense, and I'm not kidding). One argument for why it will never happen. No one will be able to maintain it. No one will be able to sell it to the boss so that they can get money for it. Hmm. I have to think for a while, but I wonder if more more hierarchy at the top levels isn't a problem, in the sense that the top then becomes more sensitive to topolgoy changes. Topology changes at the top are pretty rare. Further, if we have sufficient aggregation by the lower levels, it's not a real big deal. Remember, the top layer has to always be flat. Those topology changes are always tolerable. The bug there, of course, is that changes in the address structure at the higher layers will have wider impact. Agreed. Again, make use of the budget to absorb the impact. For example, if someone with a /8 needs more address space, well, give them a second /8. If it doen't aggregate, well, it's one prefix for a whole lotta hosts. Actually, now that I think about it, neither coffee nor amphetamines are really what's indicated here. I've been considering if cyanide is it.. :-) Does the expression "massive pain" mean anything to you? :-) Is it better or worse than a CIDRD flame war? ;-) I think that as the network grows, the need for reasonable abstraction boundaries will grow. Above the subnet level, we just don't have very much of that right now. Two tautologies. ;-) Hmm. I'm not sure I'd put it quite that way. The overall goal is to minimize the routing overhead, both in terms of mechanical (space, time, etc) as well as human (configuration). Here I have to disagree loudly. The goal is NOT to minimize the overhead. The goal is to simply keep it under budget over time. 3 routes or 3000 in the default free routers is NOT an issue. I bet you meant this, but just in case folks are taking detailed notes. One thing that probably would help is some attention to topology engineering, so that e.g. larger organizations can move within a limited scope without renumbering. This (IMHO) is a fine topic for CIDRD. Tony From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 17:11:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12891; Thu, 31 Aug 1995 17:11:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA23473; Thu, 31 Aug 1995 17:07:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA23467; Thu, 31 Aug 1995 17:03:40 +1000 Received: from chops.icp.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12538; Thu, 31 Aug 1995 17:03:13 +1000 (from smd@icp.net) Received: by chops.icp.net with SMTP id <20696>; Thu, 31 Aug 1995 03:02:58 -0400 To: Scott W Brim Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Wed, 30 Aug 1995 22:17:31 EDT." Date: Thu, 31 Aug 1995 03:02:53 -0400 From: Sean Doran Message-Id: <95Aug31.030258-0400_edt.20696+700@chops.icp.net> Precedence: bulk In message , Scott W Brim writes: | the level of Internet reliability which customers require | has gone up faster than the level of reliability which the | providers are giving them, such that now many (an increasing | number of) customers seem to think they must have the | redundancy that multihoming between providers gives them. | That is, because of the way the Internet | is run, multihoming is now a business necessity. I am wondering if this is a case of ex pede Herculem, because frankly, some of our fairly detailed market research as well as chats with friendly ISP types I know personally has generally indicated three key issues. (I would note that this is gleaned from people who have gone from being single homed to other providers to being multihomed to them and to Sprint and people who have gone from being singlehomed on Sprint to being multihomed with another provider, or appearing at a NAP or MAE, as well as people who are actively considering multihoming between multiple providers. I note moreover that the set of providers above is principally North American and European, however not exclusively so.) -- people are using multiple circuits because there is no affordable and highly reliable monolithic service that is widely available that lies between T1 and T3; -- when multihoming, people go shopping for the cheapest working solution, which often means a hungrier or smaller provider than the provider supplying the first T1, i.e., someone else is often willing to cut a better deal; -- the experiences indicate that the level of reliability is not qualitatively much higher when multihoming between two providers, often because of configuration errors on one side or the other, or by the customer himself or herself, and often because many failures are shared across multiple providers, or on the LEC level. OTOH, there are scattered but clear cases where one demonstrably has avoided some disconnection by being multihomed to more than one provider vs being multihomed to a single provider in a single location. On the other foot, there are many cases where if one was multihomed to different parts of a single provider, one would have avoided the bulk of those disconnections. Finally, however, there are large categories of connectivity difficulties that are not solvable by multihoming. I would note that we see a lack of technology available to make a very reliable single higher-speed connection affordable in the first case, a possible pricing flaw in the second case, and a general technical observation in the third. The fixes for these, imho, are in order: -- everybody keeps working on something that allows for something between T1 and T3 that is cheap and reliable. Many providers are guineapigging customers with inverse-multiplexing, fast-packet (ATM, SMDS, Frame Relay) and other technologies, all of which have interesting flaws when it comes to heavy Internet traffic. The latter set of technologies are also generally expensive as a T3 facility has to be constructed anyway. Another obvious fix for this is working on getting cheap fractional DS3 tariffed by LECs of all sorts; -- providers should recognize that while it's nice to take a second circuit away from a competitor, there are real costs associated with it that may bite in the future. Moreover, providers should also recognize (hi Sprint people) that while offering a cheaper rate on a second T1 reduces direct revenue, it also puts a hold on serious future costs in terms of scaling the routing system. That is, providers should make it reasonably affordable for people who _want_ to multihome to one provider, and possibly more expensive for people who actually multihome to more than one provider (or more expensive for providers who accept multihoming customers, even though it is *already* expensive to do so), although personally I prefer the first approach and think it would be sufficient; -- the Internet is not reliable, and the assumption that being multihomed to multiple providers eliminates the truth of that is unrealistic right now. There are ways to make the Internet somewhat more reliable in terms of yanking down MTBFs and MTTRs (with particular emphasis on the latter) which all providers are working on as a business necessity. Finally, all providers must avoid making overly optimistic claims about the reliability of the Internet, and would be wise to avoid falling into the trap of "we are more reliable than provider X" because, as far too many of us providers can attest, that can change all too rapidly... I summarize this by suggesting that the principal reason why people multihome to multiple providers is generally not reliability (which generally results in leaving a provider altogether), but economics. Using addressing policies to tilt the economics of multihoming is a fool's game, and one would be foolish to believe that addressing policies could seriously slow the migration of customers from providers who do not offer sufficient cost-effective services to those who do, nor to slow down the rate at which people multihome for the very strong reason of dollar-cost-of-service. Sean. From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 17:30:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13615; Thu, 31 Aug 1995 17:30:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA23527; Thu, 31 Aug 1995 17:27:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA23507; Thu, 31 Aug 1995 17:16:59 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13049; Thu, 31 Aug 1995 17:16:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06863; Thu, 31 Aug 95 03:16:05 -0400 Date: Thu, 31 Aug 95 03:16:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508310716.AA06863@ginger.lcs.mit.edu> To: bmanning@isi.edu, tli@cisco.com Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: bmanning@isi.edu > Obviously, some longer term transition period is reasonable. It becomes a top down or bottom up question. Bottom up, traditional renumbering by subnet. Takes months/years. Top down .. How long then? Let me point out the obvious by saying that top-down would be the way to go if we had automatic tools to do it, which we don't. Now that I think about it, this may tie in to a previous comment, about how "continuous reconfiguring of the end users machine" is not an option, at least if is manual. One suggested solution was use of "local" addresses, so that any attempt to go offsite could be mapped into some rationalized address. (Think of it as architected NAT.) You could view those "local" addresses, which are presumably configured, as just the *low-order* parts of a global address, the high-order parts of which is supplied by the net, hence transparent to the end user. (I guess this is sort of what IPv6 does...) That would provide our automatic renumbering nicely... Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 17:33:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13817; Thu, 31 Aug 1995 17:33:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA23555; Thu, 31 Aug 1995 17:31:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA23494; Thu, 31 Aug 1995 17:11:13 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12878; Thu, 31 Aug 1995 17:10:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06844; Thu, 31 Aug 95 03:09:37 -0400 Date: Thu, 31 Aug 95 03:09:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508310709.AA06844@ginger.lcs.mit.edu> To: bmanning@isi.edu, tli@cisco.com Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li > Because Rupert has moved his new subsidiary MicroSloth, to Perth and now > Australia needs a /8. If their percentage of active destinations has significantly increased, then it is entirely reasonable to give them a _second_ prefix, which might well be a /8 or /9. Ahem. This may not be a painless panacea. What you've just described is close (since IP routing is more flexible, we aren't quite as screwed) to how they fix an area code which has too many subscribers, which is to add another one, and, Guess What, Mr Wizard... some large share of the subscribers get a new area code. Similarly, making use of that extra prefix doesn't mean you can just scatter it like hayseed across the part of the network topology that's run out. What you do depends on what you've got there already, of course. Technically, what's best is if you allocate it to a whole new chunk of topology, but that's probably not possible. (It *is* what the phone companies do, of course...) What's next best is to break it up into pieces of about the same size as the largest pieces of the number you've already got, and scatter those pieces as contiguous entities through your topology. Then, you can draw a boundary around the whole thing and treat it as a single area. I.e. if you had A, and it was split up into A.[1-99], and you got B as well, you could scatter B.[1-99] through the area which holds A.* and not impact the routing much, either inside or outside. Internal tables which used to hold A.* and some other stuff now hold A.* and B.* and etc; big deal. Of course, if you were flat routing inside A with lots of teensy-weensy pieces, or something equally ill-advised, you're in deep birdlime, but that fate awaits anyone who does that kind of thing (and from a myriad of failure modes, too...) I won't even bother to talk about how easy this is to deal with if you have variable-length addresses... :-> (Evil smirk!) Noel From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 17:39:42 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13944; Thu, 31 Aug 1995 17:39:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05779 Thu, 31 Aug 1995 17:38:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA23578; Thu, 31 Aug 1995 17:33:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA23523; Thu, 31 Aug 1995 17:25:56 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13428; Thu, 31 Aug 1995 17:25:33 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by shark.mel.dit.csiro.au with SMTP id AA01632 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 31 Aug 1995 17:24:36 +1000 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id AAA24442; Thu, 31 Aug 1995 00:21:13 -0700 Date: Thu, 31 Aug 1995 00:21:13 -0700 From: Tony Li Message-Id: <199508310721.AAA24442@greatdane.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: bmanning@isi.edu, tli@cisco.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9508310709.AA06844@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: Discussing encap/mapping proposal Precedence: bulk If their percentage of active destinations has significantly increased, then it is entirely reasonable to give them a _second_ prefix, which might well be a /8 or /9. Ahem. This may not be a painless panacea. What you've just described is close (since IP routing is more flexible, we aren't quite as screwed) to how they fix an area code which has too many subscribers, which is to add another one, and, Guess What, Mr Wizard... some large share of the subscribers get a new area code. Of course. The extra prefix only provides more address space for the migration. If you intend to have aggregation within that abstraction naming boundary, you need topological coherence. But this can be achieved over time, just as the phone company does. Longer if routing within the ANB is not stressed. Technically, what's best is if you allocate it to a whole new chunk of topology, but that's probably not possible. (It *is* what the phone companies do, of course...) Not exactly, tho. They're subdividing existing topology. With _our_ growth rates, this is not necessary. Simply "sistering" some subdivision (put in parallel) and then letting growth and brownian motion populate the prefix is likely to populate it nicely. Note that this needs to be done with sufficient time that the remaining address space within the ANB isn't depleted, fragmented or becomes so flat that routing explodes. What's next best is to break it up into pieces of about the same size as the largest pieces of the number you've already got, and scatter those pieces as contiguous entities through your topology. Then, you can draw a boundary around the whole thing and treat it as a single area. I.e. if you had A, and it was split up into A.[1-99], and you got B as well, you could scatter B.[1-99] through the area which holds A.* and not impact the routing much, either inside or outside. Internal tables which used to hold A.* and some other stuff now hold A.* and B.* and etc; big deal. Exactly. A factor of two increase, over hopefully a long time. I won't even bother to talk about how easy this is to deal with if you have variable-length addresses... :-> (Evil smirk!) Been there, done that, seen the movie, read the book, got the T shirt. And still lost. Tony From owner-Big-Internet@munnari.OZ.AU Thu Aug 31 19:30:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18663; Thu, 31 Aug 1995 19:30:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA23703; Thu, 31 Aug 1995 19:27:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA23677; Thu, 31 Aug 1995 19:07:39 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17874; Thu, 31 Aug 1995 19:07:30 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id CAA26469; Thu, 31 Aug 1995 02:07:21 -0700 Date: Thu, 31 Aug 1995 02:07:21 -0700 From: Tony Li Message-Id: <199508310907.CAA26469@greatdane.cisco.com> To: swb1@cornell.edu (Scott W Brim) Cc: big-internet@munnari.OZ.AU Subject: Multihoming Precedence: bulk Provider boundaries would be address space boundaries. If your multihoming is between topologically "local" providers which all hang off the same larger provider then the extra information need not propagate very far -- it can be merged at the larger provider. Exactly. However, that's not what customers want to do. They want redundant independent connectivity over large areas. I've seen no data to support this claim. In fact, given the economics and security aspects of the situation, most are likely to want highly localized redundancy. Recall that a single point of contact is highly preferable to contain the security exposure. Maintaining lots of different firewalls is painful and expensive. Further it's likely that geographically distant second links simply cost a lot more than the benefit that they provide. You are correct that users will want provider diversity, but that is orthogonal to geographic diversity. The question then becomes when can we recapture the noise injected by a multihomed net. As you point out, it's absorbed at the next abstraction boundary, again suggesting that we need more abstraction at the higher levels. Also, please note that this discussion has assumed that multihoming is a significant problem, which is yet to be shown. As of the original CIDR draft, we were seeing approximately 10% of the sites as multihomed. As the user community changes, this appears to be dropping, which is only reasonable as more and more sites are individual users. Recall that the leaves of a tree are always the bulk of its population. The interior is the exception. An alternative possibility is that, at least within the areas which impact "core" routers, you put multihoming and the address space along different dimensions. I didn't phrase that well, but forget it, this is turning into a Noelgram. Specifically, within the "core" you could route NOT by provider but by geography. Thus, within the "core" whether you are multihomed to different providers or not, you would be included in one address prefix, a geographic one, reachable by multiple providers. I think that what you're asking for is another abstraction soley to contain this noise. I suspect that tarrifing may play more of a part in its definition than geography. In any case, I think this simply falls out of the higher levels of aggregation if we do them. This does not cover the case where an organization wants to be multihomed in widely separated geographic locations. I assert there are a lot fewer of those than there are organizations which want to be multihomed on independent providers. Good. I agree, but now I'm confused with respect to what you've written above. It IS a claim that provider-based addressing may have looked good once, but the Internet and its users have changed, and now its problems outweigh its benefits. I would be very interested in knowing what you think has changed. These are the exact same points and issues that we've been discussing (and discussing, and discussing, and discussing) for the last three years. Tony