January 1996 - lir-wg - mailman.ripe.net

Re: Policy Statement on Address Space Allocations
by jnc＠ginger.lcs.mit.edu 15 Feb '96

15 Feb '96

From: Geoff Huston <G.Huston(a)aarnet.edu.au> it will be economically infeasible IF we continue with this strange system of zero dollar interconnections we use as a peering model. ... In the same way that giving away IP addresses and giving away IP routing can only be described as a very bad case of irrational behaviour, especially when the underlying resource is under stress ... then I'd also note that giving away transit is similarly a case completely irrational behaviour! All this points to a desperate need for a more realistic economic structure to be used within a number of key aspects of Internet infrastructure. Geoff, while I sort of agree with you, please note that the current "free" models in all these areas do have one real advantage, which is that they are simple. Perhaps we will need "more realistic economic structure[s]", but I can more or less guarantee you that those will be more complex as well. Also, that complexity has a cost, which also has to be figured in. (The classic example is long-distance telephone service, where the cost of creting the bill is said to be far larger than the cost of the underlying service.) Finally, given past history, I suspect that the 'Net community, and particularly the 'Net technical community, is going to have a painful transition, on the emotional level and others, to this brave new world of more commercial structures, and the inevitable technical impacts that causes. That has certainly been the case in every such step in the past... Noel

14 23

Re: Policy Statement on Address Space Allocations
by Sean Doran 05 Feb '96

05 Feb '96

> The same ISP has said publicly that they will route /19 prefixes in our > address space: 193/8 and 194/8. The discussion is still going over > future /8s. But read the last paragraph of the policy statement! Sure, there is no filtering in 193/8 and 194/8, and as a result we have VERY poor aggregation. Consider this random cut-and-paste from 194/8. * 194.19.36.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.37.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.40.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.54.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.55.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.60.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i * 194.19.192.0 144.228.101.1 1 90 0 1239 701 3300 3301 5427 i * 194.20.0.0/15 144.228.101.1 1 90 0 1239 701 3302 ? * 194.20.8.0/21 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.16.0 144.228.101.1 1 90 0 1239 701 3300 ? * 194.20.19.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.20.0/22 144.228.101.1 1 90 0 1239 701 3397 ? *>i194.20.32.0/22 144.228.121.118 10 100 0 3345 i * 194.20.36.0/22 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.40.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.42.0 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.44.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.49.0 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.50.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.52.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.56.0/23 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.60.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.64.0/19 144.228.101.1 1 90 0 1239 701 3302 1267 i * 194.20.96.0/21 144.228.101.1 1 90 0 1239 701 3269 5394 i * 194.20.104.0/22 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.108.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.112.0/22 144.228.101.1 1 90 0 1239 701 3302 3313 i * 194.20.120.0/21 144.228.101.1 1 90 0 1239 701 3302 3313 ? * 194.20.136.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.137.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.138.0 144.228.101.1 1 90 0 1239 701 3300 5392 i * 194.20.139.0 144.228.101.1 1 90 0 1239 701 3300 5392 i Putting in a filter on 195.0.0.0/8 that will permit ONLY /18s and shorter prefixes is the only means I can see at this time that will make this kind of b.s. impossible. Indeed, if I put inbound filters on these announcements (and many other similar examples in 194/8) today, I would bet that within two days, everything that can be aggregated above, in Europe and by AlterNet, would be aggregated. If you have some technical means by which you can guarantee that no future allocations will result in rafts of unaggregated addresses like the random chunk cut and pasted above, then I would like to know about it. > I wonder where that rumour comes from. It is certainly not the RIPE NCC > allocation policy. this is a good time to set the record straight on this > and related things. This is *not* an attack on Tony who, I am sure, was > quoting some rumour in good faith. Yah, yah, Daniel, it's a giant conspiracy against you and Tim Bass. > 1) The initial allocation for a newly established local registry (ISP) > *always* is a /19. There will be no discussion about this. > This is fixed, cast in stone, immutable, ... you get the idea. Ah, so Mr "we need to find compromises" of the last message when referring to me not being willing to abandon the goal of an absolute maximum of 1024 prefixes only (and hopefully far fewer) in every /8 remaining in the old-style class C space is not so flexible as he wants me to be? Not that I care; I'm not prone to compromise myself, frankly. I just find the change in your tone from one message to the next awfully amusing. > Note that we make /19 allocations even though one particular ISP is > telling the world that /18 is the minimum you ought to have these days. Yup. And when you make the /19 allocations, you should tell them that in 195/8, if they are announcing a /19, a /20, a /21, a /22, a /23 or a /24, that will not work if they want to talk to SprintLink via a non-customer path. If not, well, I have this neat archive of plenty of warnings I've posted on several lists, and I work with a team of good people in program management, marketing, media relations and legal who went through this in a rather more controversial atmosphere when the filters on 206/8+ went in place, cutting off people who previously had gotten accidental connectivity using long prefixes. Filters on ranges of addresses that have not yet been allocated from is much simpler to defend on all fronts. > Our experience suggests that /18 is too much to assign to any newly > established local registry. It is too wasteful. On the other hand we > cannot live without policy #1. So we decided to stick to /19s. Well, you're the registry. I can only tell you the consequences, and that I won't lift a finger to make exceptions when people start whining, "but RIPE didn't TELL me it wouldn't work!". > It should be noted that we have started allocating hierarchically from > 193/8 when the InterNIC was still using 192/8. So we feel that we have > quite a good track record concerning routing aggregation and address > space conservation too. We consider our policy a good compromise > between aggregation and conservation and our community backs this > policy. I don't disagree that historically RIPE's allocation policy has been *excellent*. However, there are two problems: firstly, it is insufficient in and of itself to prevent things like the stuff above, and secondly there is a disconnect between allocations and announcements. So, let's kill two birds at once: first, an enforcement mechanism to push people into announcing only one prefix per allocation, and second, increase the size of the initial allocation, which will tend to push people away from RIPE as the registry of first choice. I'm sorry if that hurts your income, RIPE. Sean.

11 27

Re: Policy Statement on Address Space Allocations
by Sean Doran 01 Feb '96

01 Feb '96

| 1) Provider X can announce the aggregate outside of the area & thus | give free transit to the whole area; or | | 2) Provider X can announce just provider X's customers outside of the | area, thus defeating the gain from aggregation; or | | 3) Provider X can be paid by everyone else in the area to provide | transit to the entire area to where ever else Provider X connects to. Just to be vicious, I think I should mention option #4: Provider X can announce the aggregate outside of the area and drop packets bound for people in the area who do not pay Provider X for transiting packets to them. I think you will find that if a system were set up such that there were many touchdowns of this nature (announcing a single prefix), people would be screaming that they were at the mercies of the decisions about to whom in each local aggregate each long-distance carrier would be willing to deliver traffic. One could also view this as a way to push the problems of CIDRization out to the edges -- it would then be the end sites which would have to learn and be able to route towards the exceptions in the local aggregates, rather than the long-haul carriers. Sean.

2 1

Re: Policy Statement on Address Space Allocations
by huitema＠pax.inria.fr 31 Jan '96

31 Jan '96

At 2:41 PM 30/1/96, Andrew Partan wrote: >> The proper solution is for all these companies to form a consortium. The >> consortium would run the NAP and contract with multiple NSP's for >> service. In that case, the NSP's are not providing transit to >> non-customers because the consortium is the customer and every ISP who >> joins the consortium gets multihoming reliability outside the region. > >Ah - we may have something that works - we have someone (the >consortium) being paid (by these companies) to provide (or further >purchase) transit. My initial message may have been terse, but I was certainly not expecting the "deviant CIX" or "specialized NAP" or "Agregating CIDR Internet Detour" (ACID, (tm)) to provide world wide reachability for free. In fact, it is providing a service at a cost. The service is to provide reachability to smallish 192/27 single home or multihomed networks. It does so by aggregating several such networks into a larger, CIDR routable, 192/8 (or /10, or /15). The cost is indeed that the transit traffic goes through the ACID, consume bandwidth and other resources, and that these resources have to be payed for. In short, networks owners pay for not having to renumber; how much they are ready to pay depends on how expensive their renumbering will be. Paying can be done in many way, from the "consortium" which you suggest to some fees to a service company that operates the ACID. In fact, the major roadblock here is the intrisic monopoly -- at first sight, there can only be one ACID for a given aggregate. This may trigger all sorts of regulatory questions. Sharing of resource between consortium members or service customers may be done either the usual way (i.e. FIFO and random luck) or in a more organized way, e.g. using class based queuing. Christian Huitema

3 2

Re: Policy Statement on Address Space Allocations
by marthag＠MIT.EDU 31 Jan '96

31 Jan '96

> > In message <199601291642.QAA09648(a)diamond.xara.net>, "Alex.Bligh" writes: > > Iljitsch van Beijnum <iljitsch(a)unix1.bart.nl> wrote: > > > > > No they don't. You can ask the RIPE NCC for special PI space to assign to > > > this customer. It seems they have a "chemical waste dump" to satisfy > > > this kind of requests from. > > > > Ah. That will be the "chemical waste dump" that Daniel K said > > he didn't care about whether it got routed or not (no offence > > Daniel - neither do I), and is all but unaggregatable so presumably > > Sprintlink et al. won't want to waste their CPUs routing it as well. > > What hope for a customer with those IP numbers? > > > > Alex Bligh > > Xara Networks > > > Alex, > > Here's my suggestion. > > If you put that multi-homed customer in a larger aggregate (have them > pick one of the providers and allocate from their address space) all > of the providers must then announce the more specific. Some providers > will block the longer prefix. The longer prefix will be preferred and > traffic will avoid going through those providers that block it. This > might cause longer or suboptimal routing for the longer prefix. > Providers everywhere will have either the shorter prefix or both, so > full connectivity would exist. > > If the multi-homing is sufficiently localized within the topology (for > example, multiple providers in the same region or country) there might > be a chance to draw an aggregation boundary around the whole thing and > block the longer prefix outside of that locality and avoid the > possibility of suboptimal routing due to long prefix filtering. > > Curtis > Except that if the shorter prefixed route goes down, half the world will not be able to see any route to site, which sort of defeats the purpose of being multi-homed. Martha Greenberg marthag(a)mit.edu

2 1

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 31 Jan '96

31 Jan '96

At 5:48 1/30/96, Alex.Bligh wrote: >Thankyou for the first constructive workable suggestion had so far. However, >this has two problems. You're welcome. > >a) RIPE fidn't give me the first /19 in a shorted prefix block > ( its x.x.160.x and .192.x is used), but no matter, I'll renumber > if necessary :-( or persuade them to give me a /18 as well so I > can do the above (hopefully). My convert the /19 to an /18 was a way to get minimal extra announcements. Getting a new /19 and keeping the first 3 /21s for your own use and giving them the 4th, still adds only one EXTRA announcement (over the need to announce the [new] /19 itself). >b) The /21 advert may be inbound filtered by a.n.other, which will be > fine if it has an AS-Path through me (as the less specific route > will work the same way) but won't when that path goes through the > other provider with whom they are multi-homed, as the /21 will disappear > entirely (3rd parties, i.e. a.n.other's customers will see neither), > the /19 will be the only thing that is visible, and I'll just black > hole their packets. As a Multi-Home (as opposed to a Private) /21 it should (theoretically) be entitled to being added to the filter lists as valid - Getting this done is a political problem. You should not be black holing the packets since your receipt of them is VALID (since they are Multi-Homed as opposed to having walked with the block).

1 0

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 31 Jan '96

31 Jan '96

At 11:39 1/30/96, Iljitsch van Beijnum wrote: >> At 6:09 1/29/96, Alex.Bligh wrote: > >> > Currently I have 2 choices as >> >far as I can make out, give them a bit of my /19, break up my >> >nice aggregate and ensure loads of extra announcements (and that >> >probably none of them get routed by anyone applying prefix based >> >filtering), or give them a new /19 all of their own (you've > >Suppose you have a customer that needs a /22 and they want to go >multi-homed. Suppose you give them that /22 out of your /19 or /16 you >got from the RIPE NCC. So they announce their /22 to you and to their >other provider. But you keep announcing your /19 or /16. So if anybody >were to filter the /22 announcement, your customer only suffers partial >loss of connectivity, since you are still announcing an aggregate of >their announcemnt (your original /19 or /16). > >Problem fixed. Anything else? ;-) Unless you announce both the /16 (or 19) AND the /22, they are not multi-homed but only single routed (with some fallback for those who see the /22 announcement). Anyone who gets the unfiltered /22 announcement will used the other provider (so long as that provider is up) while you get used only by those who get a filter routing (and as fallback when the other provider goes down).

1 0

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 31 Jan '96

31 Jan '96

At 6:09 1/29/96, Alex.Bligh wrote: > Currently I have 2 choices as >far as I can make out, give them a bit of my /19, break up my >nice aggregate and ensure loads of extra announcements (and that >probably none of them get routed by anyone applying prefix based >filtering), or give them a new /19 all of their own (you've >said it, that's the minimum size allocation) which actually >solves their problem and mine, but this isn't an option >currently available because currently it's one window per local-IR. >So they have to go and become a local IR. If the high /21 of your /19 is not Allocated, you just assign it to them and add ONE announcement of the /21 to supersede with the current /19. If it is not free but is sparsely populated you can move the stuff out to free it up or go to RIPE to get your /19 turned into an /18 (ie: get the /19 right after your current /19 [RIPE did give you the first /19 in a shorter prefix block didn't they?]) in exchange for returning the /21 worth of space [giving you 3 extra /21s worth of space], and divide that 2nd /19 into a /20, and 2 /21s giving them the 2nd /21 (still doing the same 2 announcements as you would if allocated out of your current /19).

4 3

Re: Policy Statement on Address Space Allocations
by asp＠uunet.uu.net 31 Jan '96

31 Jan '96

> I think that we solved that problem by providing full information for > all of the routes to routers within the area, and none outside. > If you wish to correct me, feel free. So everyone w/in the area can get to all of these sites (& since they have to carry full routes, they don't save any routing table space), and everyone outside of this area has no routes to any part of the area and thus can't get to any of these sites at all? Humm; if I understand you corretly, this seems to be a loose all around. --asp(a)uunet.uu.net (Andrew Partan)

5 10

Re: Policy Statement on Address Space Allocations
by huitema＠pax.inria.fr 30 Jan '96

30 Jan '96

At 11:22 AM 26/1/96, Sean Doran wrote: >| > We just have some differences of philosophy -- you think >| > that RIPE really can persuade people into having only >| > 1024 announements (preferably far fewer) in 195/8, and >| > I don't. That's all. >| >| OK. I call this a challenge but you won't let me try ;-). > >You and Randy Bush seem to be reading each other's minds. > >He has proposed this in a way that is very interesting, >and which I will think about. > >There is a bad failure mode to consider that even a badge >afterwards won't make any more attractive. > >Mostly it's "what on earth do we do if we cross the >threshold of 1024 prefixes in 195/8?" to which I see no easy >answer that doesn't involve inflict enormous pain on people >with old, established long prefixes in 195/8. There is at least one very simple response. Set up some deviant CIX, say IX195-8, let everyone with a shortish 195/8 prefix connect to it either directly through their own provider, or indirectly through some tunnel, and have IX195-8 announce reachability of 195/8. That is, in short, altern topology to meet addresses when the converse is too hard. KRE detailed that for the general case, but it would be even simpler in the case of RIPE, since all the allocated network numbers are in the same geographical area. Christian Huitema

6 6

Re: Policy Statement on Address Space Allocations
by jnc＠ginger.lcs.mit.edu 30 Jan '96

30 Jan '96

From: "Joel M Snyder, writing fool" <Joel_M_Snyder(a)opus1.com> The company wishes to have more than one connection to the Internet through more than one of the major providers From: lodge(a)houston.omnes.net (Mathew Lodge) its upstream provider ... They also want to be multi-homed from day one. They currently offer all sorts of fully redundant data services, and understandably they can't see why they should have a single point of failure in their global Internet access. Oh, good, the multi-homing discussion again. (The loud "bang" you just heard was Noel blowing out his brains in sheer desperation and frustration.) Here's a repeat of a previous post to a different list: For those who aren't up on the technical background to multihoming, you should consider consulting the Big-Internet archives from the end of September '95 for a long discussion of it. (In particular, see the thread "Discussing encap/mapping proposal", especially the messages of Thu Aug 31 23:33:12 1995 from me, Fri, 01 Sep 1995 11:13:39 -0500 from Scott M. Ballew, and Fri Sep 1 13:25:59 1995 and Sun Sep 3 01:23:59 1995 from me, which discuss the theoretical background in some detail. The thread "Multihoming", especially the messages Fri Sep 1 11:20:25 1995 and Mon Sep 4 14:26:06 1995 also contains some valuable material.) For those who don't wish to paw through all that, here are the salient points, quickly: 1. Multihoming for robustness adds new capability to the system, and that new capability does not come without cost, the cost being greater routing overhead. The amount of routing overhead will vary depending on many factors. 2. Connectivity-based addressing (i.e. the thing that "provider-based" is a subset of) provides routes at least as good, and at as least as small a cost in routing overhead, as any other addressing scheme. (Connectivity-based addresses for multi-homed sites allow us to use less than global scopes for the advertisement of routing information about such sites. Non-connectivity-based addresses do not have this characteristic; they require advertisment through the entire network.) 3. The cost in routing overhead (at least in conventional hop-by-hop routing systems such as the current Internet) is dependent on how far apart, in the connectivity topology, the multiple connections are. (More widely separated connections can increase the routing overhead with little payback in increased reliability.) 4. The cost further depends (again, in the same kind of systems) on how optimal you want routes to be if both links are up, how optimal you want them to be if one is down (and it will vary depending on whether it's a primary or secondary). I hope everyone will keep these 4 main points in mind in any discussion on multi-homing. Now, a few extra comments appropriate to this case: There is *no way*, in the current overall routing architecture (which uses exchange of routing tables) to add multihoming for fault tolerance without a cost in routing overhead. Providing this fault-tolerance is not zero-cost in *any* scheme I can conceive (TANSTAAFL, surprise, surprise), but some are better than others. Since redesigning the entire architecture is not something we can do this week, I'll leave the pleasant contemplation of such alternatives to academic, ivory-tower, environs. We can *easily* limit the amount of routing overhead caused by multi-homing among different providers if we provide some structure in the addressing hierarchy *above* providers. (To be technical, this will allow less than global advertisement scopes of such multi-homed entities.) Since this could necessitate renumbering most of the 'Net, I don't expect it to happen anytime soon. We can also limit the amount of routing overhead by providing configured AAB boundaries for a given multihomed site which enclose a path between the primary and secondary providers. Since this will in some cases require cooperation among multiple providers, as well as either i) massive amounts of manual mechanical configuration bookkeeping, or ii) automated tools we don't have yet, don't hold you breath for that one either. Noel PS: If you didn't understand that last paragraph, read the references before you speak.

3 2

Re: Chiappa blows his brains out (was Re: Policy Statement)
by jnc＠ginger.lcs.mit.edu 30 Jan '96

30 Jan '96

<There's an interesting point in the middle of this, about how multihoming presents technically rooted problems no matter *how* we do the addressing, even if we solve the conflict he mentions, and that these problems have an impact on what policies it is useful to discuss...> From: "Joel M Snyder, writing fool" <Joel_M_Snyder(a)opus1.com> GIVEN that I have sufficient knowledge about routing as is necessary to fully understand every technical issue involved Sorry, I guess I just assumed the wrong interpretation of what your question was about. (Also, to be honest, if we've got to the point that most everyone understands these issues, I guess it's time for the champagne... :-) GIVEN that I have a rudimentary and imperfect understanding of the political and economic issues regarding IP numbering and the propagation of routes thereunto I'm not sure anyone has a truly "global" view of this, although if one listens on this and other lists hard, one can start to get a view which integrates the large and small ISP's, equipment suppliers, etc, etc... GIVEN that there exists some set of organizations who want to purchase multiple T1s from multiple independent suppliers ... HOW do I resolve the conflict between justifiable corporate service requirements and the expressed statements ... that anyone who does not consume at least a /18 worth of address space is not worthy of being globally routed? To start with, this is another case where setting the size-based filter for routing updates is having deleritous effects. Again, all we're doing is creating a demand for address space, and as long as there is no well-modulated back-pressure on address space (such as charging for it), I'm not sure I see any easy way of dealing with it. Second, whether it's a /18 or a /24 is of no interest to the routing. Let's assuming we can separate the addressing issues out, to focus just on the routing cost, which is going to be the same *regardless* of how you resolve the address space issues. This is important: *** No matter how you do the addresses, you *still* have the problem that if *** a significant percentage of customers want to be multihomed, and we still *** don't have any mechanism or tools for reducing the scopes of those *** advertisements from global (such as I mentioned in my original message on *** this thread), we will find it technically impossible to provide this *** multihoming capability to a large number of users: we will be rerunning the *** very routing table growth (tracking local sites individually) that caused *** us to go to CIDR in the first place. I don't know about you, but I could do without a re-run of that particular learning experience! :-) Ideally, in solving this, I would take a monetary approach, which is to say "what are the true costs of this multihoming, and given that, is it important enough to the client for them to pay for it", but of course we don't have a charging mechanism for routes that would help to answer this, and maybe never will. So, I can't use that copout. Maybe a better question is to ask "what goal are they really after with multi-homing", because if the answer is "reliability", then perhaps they get more bang for their <insert-local-currency> with things like multiple access lines, etc. I am asking, I suspect, not for a technical answer (there being none other than Chiappa's "it's gonna cost"), but the most politically correct answer to give the organization I understand that you have a very "bottom-line" concern, which is "what do we tell the customer", but I hope that this time I have made clear to everyone that there is no solution to the technical question of "can we provide multihoming on a large scale", *at least in the system as it stands today*. (I.e. if this is an important goal we need to get cracking on technical solutions...) Any policy discussion must take place in an environment which is aware of this technical constraint. Thus, your question about the policy conflict you pointed out is interesting and true, but ultimately not a critical one... Noel

1 0

Re: Chiappa blows his brains out (was Re: Policy Statement)
by jnc＠ginger.lcs.mit.edu 30 Jan '96

30 Jan '96

From: Scott Huddle <huddle(a)mci.net> Probably the best thing that be currently supported is getting two diverse connections to a single provider that can globally aggregate your network. The connections should go to different POPs and should follow seperate physical paths. This should provide you the desired reliability and load sharing. This solution has been pointed out before. Also, Dorian Kim sent in a good message to the Big-Internet list talking about reliability (the stated goal of most multi-homing), and the 7 places you could do redundancy, and what was really important in achieving reliability, which contained a lot of good insight. Here's his message (appended). Noel -------- Date: Fri, 1 Sep 1995 03:57:16 -0400 (EDT) From: Dorian Rysling Kim <dorian(a)cic.net> To: ... big-internet(a)munnari.oz.au Subject: Re: Multihoming .... There are many places where redundancy can be achieved with multiple connections. 0) Equipment spares on site 1) Diverse local access of the two links 2) Diverse routing of the physical links into COs 3) Diverse routing to different local providers 4) Diverse routing to different regional providers 5) Diverse routing to different large transit providers (MCI, Sprint, ANS, Alternet, Eunet etc) 6) #5 + connection to the NAPs. All of the above give you redundancy at various single points of failures. In my experince, #0 - #2 should be considered as important in providing true redundancy as 4-6. In fact, in most cases, the most common case of outtages come from equipment failures, and circuits themselves, and sites who are looking for multihoming for the reason of redundancy should look at the cost of having 0-2, and think long and hard about whether multihoming is what they really need. -dorian

1 0

Re: Chiappa blows his brains out (was Re: Policy Statement)
by Scott Huddle 30 Jan '96

30 Jan '96

Joel_M_Snyder(a)Opus1.COM writes > GIVEN that there exists some set of organizations who want to purchase > multiple T1s from multiple independent suppliers for purposes of > reliability and load sharing yet have need for less than 255 unique IP > addresses, and GIVEN that certain extremely popular software products (such > as Netscape Navigator) which are important to these organizations were > developed by programmers who seem to have no knowledge of either efficiency > or the way that the Internet works, and GIVEN that I have sufficient > knowledge about routing as is necessary to fully understand every technical > issue involved, and GIVEN that I have a rudimentary and imperfect > understanding of the political and economic issues regarding IP numbering > and the propagation of routes thereunto, HOW do I resolve the conflict > between justifiable corporate service requirements and the expressed > statements on these mailing lists the past few weeks which seem to imply > that anyone who does not consume at least a /18 worth of address space is > not worthy of being globally routed? > > I am asking, I suspect, not for a technical answer (there being none other > than Chiappa's "it's gonna cost"), but the most politically correct answer > to give the organization (which is not Netscape). You present a hard edge case that isn't particularly well met by the current infrastructure and it can't necessarily be done well or even done at all. (Sean's tricky chocolate-consulting hack excluded). Probably the best thing that be currently supported is getting two diverse connections to a single provider that can globally aggregate your network. The connections should go to different POPs and should follow seperate physical paths. This should provide you the desired reliability and load sharing. -scott

2 1

RE: Chiappa blows his brains out (was Re: Policy Statement)
by lodge＠houston.omnes.net 30 Jan '96

30 Jan '96

Scott, >You present a hard edge case that isn't particularly well met by the current >infrastructure and it can't necessarily be done well or even done at all. >(Sean's tricky chocolate-consulting hack excluded). Probably the best >thing that be currently supported is getting two diverse connections to >a single provider that can globally aggregate your network. The connections >should go to different POPs and should follow seperate physical paths. >This should provide you the desired reliability and load sharing. Thank you, thank you, thank you. This is exactly the kind of pragmatic advice I was looking for. Saying "don't do it" or "multihoming costs" is not helpful -- this sort of answer is. Regards, Mathew

1 0

Hmmmmmm...
by Sean Doran 29 Jan '96

29 Jan '96

>From the latest Cook Report: | InterNIC now dealing with IP address requests from 50 new ISP start ups | every week. By sending them to their upstream providers InterNIC has | gone from handing out 800 CIDR blocks in the /24s to /21s ranges to about | 30 /24s - /21s per month. Sean.

3 2

Re: Policy Statement on Address Space Allocations
by Hank Nussbacher 29 Jan '96

29 Jan '96

On Fri, 26 Jan 1996 13:59:32 +0000 (GMT) you said: >Just to spend a few minutes thinking about it, what do the phone >companies do ? They are the nearest thing with a large installed base >that the Internet even begins to map onto. There are however some >fundemental differences - primarily the fragmentation of Europe (which >is not the case in the US). > >We have a 2Mb line from London to Amsterdam which costs us very much >the same as a T1 from London to Washington. As I understand it, this >"milk them for all they are worth" pricing of the telcos applies to >cross-border land lines in Europe also. > >All this impacts very severely on the commercial decisions taken as to >the routeing of traffic. I would much rather buy more lines to the US >and let the traffics flow back to Europe then to just buy lines to >Europe. Luckily, commercial concerns are not the only contraints >within which we have to work. What this has to do with RIPE allocation policies is beyond me. Everyone in the European realm suffers from extremely high tariffs. So what? >To wash some dirty laundry here, we as a provider have been trying to >get new address space for our dial up customers from RIPE NCC for almost 6 >months now. We allocate *each* dialup customer *1* IP address from a >block and dynamically route them based on where they log in to the >service (including RSN Amsterdam). The RIPE NCC has >effectively< refused >us space because they believe that we should change the product we >sell and use dynamic IP for dialups. > >We are the largest dialup ISP in Europe. We are not the largest provider >in Europe because we follow the rest of the ISPs like sheep, buying Ciscos >and installing off the shelf terminal servers. We provide a product which >our customers understand gives them *more* for their money. We do something >different, and the customers like it. Tough fact of business life that. You and hundreds of other companies approach RIPE with the same story of how big they are, how large their investors are, how their network is gonna take the world of the Internet by storm, and therefore they deserve a /16 or even a /15. If RIPE followed your logic, there would be no more address space left. Use dynamic IP like the rest of us. We all realize the drain of IP addresses and try our best to maximize the addresses. Why should you be different? >But this is all I have seen you do, therefore, how can I but believe >that this is the case. Every private mail that has been sent to us as >a company involves you acting as God and us as the grovelling peasants >praying for a benidication of address space. I have all these mails >in my various folders, as do you. It all depends on your ego. You could just look at them as an organization assigned the tough role of making sure there are IP addresses available in 1999. You see it as God. A viewpoint based on your world view. >Why not. We are not a communist society are we ? Each individual member >of RIPE have their own unique requirements in a commercial and >academically challenging world. We have a USP (Unique Selling Point) of >giving our paying customers there own IP address (OK - it is not >unique, but close enough). We have built propretary technology that >allows our users to use *any* of our dial in points and get the same >service, with the same IP number etc etc, and as one of our primary USPs >we cannot allow the RIPE NCC to try to change that. IBM has 460 POPs in over 40 countries and uses dynamic IP addresses. I can be in London or NYC or Tel Aviv and still use my SLIP connection to read my mail wherever I am. Why should you have static IP addresses for something others can do the dynamic way and thereby conserve IP address space? >Peter Galbavy peter(a)demon.net Hank Nussbacher Israel

2 1

Re: Policy Statement on Address Space Allocations
by huitema＠pax.inria.fr 29 Jan '96

29 Jan '96

At 8:04 PM 27/1/96, Hank Nussbacher wrote: >What this has to do with RIPE allocation policies is beyond >me. Everyone in the European realm suffers from extremely high >tariffs. So what? Because tariff distort topologies. In the short term, if you drew a map that used tariffs as the metric of your topology, the Atlantic would hardly be larger than the Rhine. This in itself is at cross purpose with the local implementation of CIDR, i.e. allocation of addresses to European networks from a European block by the RIPE NCC. If you look at the medium term, the perspective is even more interesting. Deregulation will gradually take place in the next three years. It will most probably result in lower tariffs for some lines, but not all, and definitely not at the same time. Take the map which I mentioned above. Imagine it printed on a fin sheet of elastic rubber, not paper. The effect of deregulation is that for the next three years the rubber will be constantly deformed, shrinking here and inflating there, and you are very lucky if you can predict where and when. To believe that this would not have some influence on addressing and internetworking is at least shortsighted. Christian Huitema

2 1

Re: Policy Statement on Address Space Allocations
by Geoff Campbell 29 Jan '96

29 Jan '96

> From: Ronald Khoo <ronald(a)office.demon.net> > That's too simplistic. A /19 in the Netherlands may well make sense. > In the UK it would be far too small, for ANY of our registries. That may well be the case with Demon Internet, who allocate a fixed IP address per customer, but for ISPs like ourselves at Global who use dynamic addressing, a /19 is fine - I've just renumbered my network to handle the next 37,500 dialup customers using one half of our /19, the only reason I shall need more in the next couple of years is if we sell lots of large leased line setups, that all need their own IP space. Regards, Geoff Campbell Technical Director Global Internet Ltd.

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 29 Jan '96

29 Jan '96

| PS: Here's Sprint's sister company's current announcement of routes | *originating* in its AS as I see them - I do hope Sprint takes the honest | path if it does refuse to carry short announcements and not route all bar | 4 of these nets, as well as a similar long list from AS1239 :-) I'm | not convinced Sprint has the moral highground here.... Moral high ground does not interest me. Working networks interest me. I have to carry the ^1239_ routes internally anyway to get my customers able to talk to each other. I don't need to carry your routes at all, unless one of my customers wants to talk to you. It's a simple thing, elegantly described by Jeff Young earlier today. It was also elegantly described by Yakov Rekhter in his CIDRD presentation of the concepts of Push and Pull. Ordinarily I would answer "filter away; we've been prepared for this kind of filter being applied against us since day #1 (although admittedly it's not going to be too pretty if someone wants to talk to you and suddenly can't. been there, done that)". As a mechanism for motivating our customers to aggregate better than they could, an important provider doing a similar sort of inbound filtering likely would be much more widely effective than the occasional Seanogram to various customers warning of doom and the possibilities of being filtered, which sometimes seem to be completely ignored. This filtering is analagous to how ANS is able to get people to register their prefixes in the RADB or run into inbound announcement filters that will stop you from talking with AOL and other ANS customers. As you note, AS 4000 is run by a different company, and you shouldn't punish them just because I'm an arrogant asshole, as I have no control over or involvement with their routing strategies. (I'm not even sure that I'm entirely popular over there. ;-) ) However, yes, they are not aggregating as well as they could be, and are announcing more-specific-routes that are completely subsumed by aggregates. Some of those folks are here and should feel free to speak for themselves. Hi guys! :) Sean. | Network Next Hop Metric LocPrf Weight Path | *> 160.214.0.0 194.68.130.50 0 4000 ? | *> 163.164.0.0 194.68.130.50 0 4000 ? | *> 194.41.63.0 194.68.130.50 0 4000 ? | *> 194.106.0.0/19 194.68.130.50 0 4000 ? | *> 194.106.32.0 194.68.130.50 0 4000 ? | *> 194.106.33.0 194.68.130.50 0 4000 ? | *> 194.106.34.0 194.68.130.50 0 4000 ? | *> 194.126.64.0/19 194.68.130.50 0 4000 ? | *> 194.133.0.0/19 194.68.130.50 0 4000 i | *> 194.133.4.0/23 194.68.130.50 0 4000 ? | *> 194.133.6.0 194.68.130.50 0 4000 ? | *> 194.133.7.0 194.68.130.50 0 4000 ? | *> 194.133.8.0 194.68.130.50 0 4000 ? | *> 194.133.15.0 194.68.130.50 0 4000 ? | *> 194.133.24.0 194.68.130.50 0 4000 ? | *> 194.133.28.0 194.68.130.50 0 4000 ? | *> 194.140.128.0/19 194.68.130.50 0 4000 ? | *> 194.140.224.0/21 194.68.130.50 0 4000 ? | *> 194.149.192.0/18 194.68.130.50 0 4000 ? | *> 194.158.0.0/20 194.68.130.50 0 4000 ? | *> 194.176.96.0/19 194.68.130.50 0 4000 ? | *> 194.204.96.0/23 194.68.130.50 0 4000 ? | *> 196.27.0.0 194.68.130.50 0 4000 ? | *> 196.27.1.0 194.68.130.50 0 4000 ? | *> 198.169.26.0 194.68.130.50 0 4000 ? | *> 204.59.0.0/16 194.68.130.50 0 4000 i | *> 204.83.37.0 194.68.130.50 0 4000 ? | *> 204.83.237.0 194.68.130.50 0 4000 ? | *> 204.83.254.0 194.68.130.50 0 4000 ? | *> 206.49.64.0/18 194.68.130.50 0 4000 i | *> 206.49.65.0 194.68.130.50 0 4000 ?

2 1

Re: Policy Statement on Address Space Allocations
by Sean Doran 27 Jan '96

27 Jan '96

This is a very interesting question involving economics of the Internet, which are still very fuzzy. I think it would make an interesting experiment. Certainly there has been lots of talk about putting something big like wuarchive.wustl.edu or ftp.uu.net into something obscure to see what breaks. There are existence proofs of sorts that popular sites can have an effect: ftp.uu.net's insistence on IN-ADDR.ARPA mappings is the one that pops into my mind immediately. Some experiments, like exp39, involved moving root nameservers into a subnet of 39/8. However, nobody has yet said, "I am Playbeing, I have content people want to get to, I can leak a /32 if I want to, and everyone will have to carry it or explain to their users why they can't get their sex-on-demand". Perhaps that's because people are afraid that there is so much other interesting content out there that disconnectivity of any sort from their customer-base would be fatal, in that users would find alternatives fairly quickly. "Click here." <click> (time passes) "Error." This happens so frequently and for so many reasons that friends of mine who are somewhat more typical dialup users would simply ignore the link or site and move on to something else.[*] There certainly is alot of competition on the content front these days. Can a big web site afford to have people thinking, "stoopid Netscape, their server is down"? Or would they be crafty and say, "all our information has now moved to _a new site_; if you get a time-out error then you should _send email to your Internet Service Provider_ telling them so"? Interesting stuff. Sean. [*] I'm different. I want to know why it doesn't work. I gather that doing traceroutes and looking at routers is atypical behaviour.

1 0

Re: Policy Statement on Address Space Allocations
by Hank Nussbacher 27 Jan '96

27 Jan '96

On Fri, 26 Jan 1996 14:03:19 -0000 you said: >But still, sorry that it wasn't as smooth as it could >have been if there hadn't been a flaw in the filtering >that crept in in about April, long before anyone was >even really thinking of allocating from 206.0.0.0/8. > >However, as I think everyone remembers, after a short while, >in an effort to assist in getting aggregation of the >then-announced bits of 206.0.0.0/8 working OK and giving >people some time to get used to the filtering, I did relax >the filtering on 206.0.0.0/8 to permit /19s. > >As you note, this was to the benefit of other peoples' customers. > >| the real message is if you have a 206+ address, make sure that your >| provider can put it into an aggregation block for you (or go to sprint). > >Right, and we have been warning our customer base for >some time that if they announce a 206+ address that is >not aggregatable into something reasonably big (like a /18), >they run the risk of losing connectivity to other providers >if they ever were to impose similar filters for business >or technical reasons. Lets take a real world example between Sean's and Daniel's arguments. I am the registry of Last Resort for Israel and I assign CIDR blocks to ISPs here in Israel. I follow the slow start model of RIPE and give initially a /22 and then a /21 and then a /20, etc. One new ISP in Israel wanted more address space and found that Net99 (all ISPs have to connect to an ISP in the USA due to Israeli gov't regulations) would give it a /21 from 206.161.0.0 and later Agis gave it a /19 from 206.249.0.0. So we have now an ISP that circumvented the allocation policies and went to the USA to get cheap, large blocks at possibly an expense of them not being portable and/or not routable even if it is portable in the future. The smaller, new ISPs that don't know even what questions to ask will get stuck more and more by this type of situation. We can't do anything about that. But we do need a better GLOBAL policy for IP address allocation that everyone adheres to (perhaps I am asking for utopia). > Sean. Hank Nussbacher

1 0

Re: Policy Statement on Address Space Allocations
by Havard.Eidnes＠runit.sintef.no 27 Jan '96

27 Jan '96

Hi, I see Daniel hasn't answered this one (weekend for some, I guess ;-) > > The point is that we will guarantee that our allocation policy > > will create no more than 1024 allocations per /8 and therefore > > not necessitate by itself more routes than that. Currently our > > allocation sizes are /19 - /16. If you think about it a little > > you will see that it is easy to achieve. > > > > And just in case: Yes the minimum allocation is /19 irrespective > > of the number of hosts covered. Note: allocation != assignment. > > OK, so just to make it clear, if a customer would come to the RIPE > NCC and the customer has just 1 host you would still allocated him > /19 block. Correct? This may be obvious to some familiar to the european networking scene already, but anyway... The RIPE NCC itself does in general not deal directly with end customers, only with local registries. To be allocated address space directly from the RIPE NCC you have to first establish yourself as a local registry, pay the startup fee and contribute to the financing of the running costs of the RIPE NCC. Remember, there is noone else than the organizations running the local registries who are picking up the tab for running the RIPE NCC. The typical local registry is also an ISP. Also note the distinction between allocation and assignment made by Daniel which could be lost on some. In this specific case allocation means "address space allocated for a local registry for subsequent assignment to customers". I've seen people critizising the RIPE NCC for their inflexible policies and the practicing of these policies. One important aspect of the RIPE NCC policies when allocating address space to registries is simplicity and uniformity of policy, because one of the worst things that could happen for the RIPE NCC would be for them to rightfully be accused of giving unfair preferential treatment to some registries (=~ ISPs) over others. The chance of this happening (or the RIPE NCC being accused of it) increases with the fuzziness of policies and the amount of evaluation and judgement the RIPE NCC has to apply to individual cases. I think this is fairly accurate, but since this is not coming from the authoritative source I may have made minor mistakes in formulating the above. Regards, - Havard

2 1

Re: Policy Statement on Address Space Allocations
by William Allen Simpson 27 Jan '96

27 Jan '96

I trimmed the CC list even further. And you are forwarned that this is a flame, with combined technical and political content: > From: Peter Galbavy <peter(a)demon.net> > Just to spend a few minutes thinking about it, what do the phone > companies do ? They are the nearest thing with a large installed base > that the Internet even begins to map onto. There are however some > fundemental differences - primarily the fragmentation of Europe (which > is not the case in the US). > It should not surprise you that we've heard this before, and rejected it before. > We have a 2Mb line from London to Amsterdam which costs us very much > the same as a T1 from London to Washington. As I understand it, this > "milk them for all they are worth" pricing of the telcos applies to > cross-border land lines in Europe also. > So, lay your own lines if it is cost effective. Heck, spread spectrum radio comes to mind.... if not microwave towers on the oil rigs in the north sea.... > All this impacts very severely on the commercial decisions taken as to > the routeing of traffic. I would much rather buy more lines to the US > and let the traffics flow back to Europe then to just buy lines to > Europe. > Is this why the US-UK links are soooooo overcrowded? Destroying connectivity for the rest of us? > We allocate *each* dialup customer *1* IP address from a > block and dynamically route them based on where they log in to the > service (including RSN Amsterdam). The RIPE NCC has >effectively< refused > us space because they believe that we should change the product we > sell and use dynamic IP for dialups. > Hell yes! Damn right! Three cheers for RIPE!!! Anyone who still allocates more than 1 address per actual dial-up link should be taken out and shot! We spent rather a lot of volunteer-years getting this to work (PPP). > We provide a product which > our customers understand gives them *more* for their money. We do something > different, and the customers like it. Tough fact of business life that. > Are you sure you told your customers about the alternatives? Like dynamic addressing? Like having connectivity to the entire Internet? This isn't new, this is old hat static addresses! How is it different? What gives _more_ here? I don't see anything worthwhile! > The RIPE NCC believes it can dicate the business model we use, which > has been established for > 3.5 years. This is unlikely to happen. > There is this misconception on your part that you have a _right_ to succeed in business, at the expense of the rest of us. > Please read the policies again. You policy uses words like "strongly > discouraged" for static IP allocation, not "disallowed". You have > attempted to strongly discourage us, we have not been so discouraged, > and now give up and give us the address space we are *entitled* to. > You have another misconception that there is an _entitlement_ to Internet access, at the expense of the rest of us. > > What we do *not* do is consider *individual* interests of some over > > the ones of others. If we would do that we would eliminate our > > "raison d'etre". > > Why not. We are not a communist society are we ? I dunno about _your_ society, but the Internet Community requires cooperation. Call it communistic or socialistic as you like. The net won't work without it. Your "priveleges" end when you affect someone else. And you are affecting me, buddy, and I don't like it one bit! Perhaps you should go build your own internet, like MicroSoft.... Again, I applaud RIPE!!! Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

Re: Policy Statement on Address Space Allocations
by alague＠hq.si.net 27 Jan '96

27 Jan '96

> >| PS: Here's Sprint's sister company's current announcement of routes >| *originating* in its AS as I see them - I do hope Sprint takes the honest >| path if it does refuse to carry short announcements and not route all bar >| 4 of these nets, as well as a similar long list from AS1239 :-) I'm >| not convinced Sprint has the moral highground here.... The routes in the below table do not violate SprintLink's (non)routing policy, except for one of the specifics which SprintLink would drop. Their policy, if I remember it correctly, is to filter announcements with: *Prefixes longer than 24 bits *Prefixes longer than 19 bits in the range of 206.0.0.0/8 *Prefixes longer than 18 bits in the range of 207.0.0.0/8 through 239.0.0.0/8 *Prefixes longer than 16 bits in the range of 128.0.0.0/8 through 191.0.0.0/8 *Prefixes longer than 8 bits in the range of 1.0.0.0/8 through 126.0.0.0/8 except for 39.0.0.0/8 which will allow prefixes up to 24 bits and 9.20.0.0/18 and 9.2.0.0/16. > >(I'm not even sure that I'm entirely popular over there. ;-) ) > Don't confuse lack of popularity with a tendency to disagree due to having different sets of problems before us. >However, yes, they are not aggregating as well as they could >be, and are announcing more-specific-routes that are >completely subsumed by aggregates. > Global SprintLink and SprintLink are run by two separate groups. Global SprintLink (AS4000) is run by a group at Sprint International. It would not be correct to hold Sean responsible for anything happening on AS4000. Yes, we have some prefixes that could and should be aggregated and some specifics that are subsets of aggregates. Thanks for pointing this out. It will be fixed right away. Regards Andy Lague > >| Network Next Hop Metric LocPrf Weight Path >| *> 160.214.0.0 194.68.130.50 0 4000 ? >| *> 163.164.0.0 194.68.130.50 0 4000 ? >| *> 194.41.63.0 194.68.130.50 0 4000 ? >| *> 194.106.0.0/19 194.68.130.50 0 4000 ? >| *> 194.106.32.0 194.68.130.50 0 4000 ? >| *> 194.106.33.0 194.68.130.50 0 4000 ? >| *> 194.106.34.0 194.68.130.50 0 4000 ? >| *> 194.126.64.0/19 194.68.130.50 0 4000 ? >| *> 194.133.0.0/19 194.68.130.50 0 4000 i >| *> 194.133.4.0/23 194.68.130.50 0 4000 ? >| *> 194.133.6.0 194.68.130.50 0 4000 ? >| *> 194.133.7.0 194.68.130.50 0 4000 ? >| *> 194.133.8.0 194.68.130.50 0 4000 ? >| *> 194.133.15.0 194.68.130.50 0 4000 ? >| *> 194.133.24.0 194.68.130.50 0 4000 ? >| *> 194.133.28.0 194.68.130.50 0 4000 ? >| *> 194.140.128.0/19 194.68.130.50 0 4000 ? >| *> 194.140.224.0/21 194.68.130.50 0 4000 ? >| *> 194.149.192.0/18 194.68.130.50 0 4000 ? >| *> 194.158.0.0/20 194.68.130.50 0 4000 ? >| *> 194.176.96.0/19 194.68.130.50 0 4000 ? >| *> 194.204.96.0/23 194.68.130.50 0 4000 ? >| *> 196.27.0.0 194.68.130.50 0 4000 ? >| *> 196.27.1.0 194.68.130.50 0 4000 ? >| *> 198.169.26.0 194.68.130.50 0 4000 ? >| *> 204.59.0.0/16 194.68.130.50 0 4000 i >| *> 204.83.37.0 194.68.130.50 0 4000 ? >| *> 204.83.237.0 194.68.130.50 0 4000 ? >| *> 204.83.254.0 194.68.130.50 0 4000 ? >| *> 206.49.64.0/18 194.68.130.50 0 4000 i >| *> 206.49.65.0 194.68.130.50 0 4000 ? >

1 0