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