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

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

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

27 Jan '96

| Don't confuse lack of popularity with a tendency to disagree due to having | different sets of problems before us. Very true. | 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. There. Andy's cool, and if he says he's going to fix it, it'll get fixed. If only it were so easy with everyone. Hi Marty! Sean.

1 0

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

26 Jan '96

| Now can we try to make things work rather than point fingers! Yes, indeed; that is the ultimate goal we share. 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. The compromise we could find would involve a practicable method by which we don't have to put a prefix-length-floor in place, but at the same time don't have to spend enormous amounts of (unavailable) CPU time filtering based on what's in the RIPE database. Avoiding large amounts of (largely unavailable) staff time at Sprint and RIPE to chase down offenders and try to figure out how to stop them from ignoring their contribution to melting routers is also something I'd like to avoid. I don't love my solution either, but it does have the advantages of being CPU inexpensive, does a reasonable job of guaranteeing an absolute maximum number of prefixes in 195/8 (the sum of the /18s, /17s, /16s ... /7s and the /8 itself) even in the worst case, and provides what has already proven in practice to be a tractable enforcement mechanism. I regret the renumberings which have happened as a result, but unfortunately people are still being hooked up to the network with freshly-allocated PI /23s and /21s, and only after they actually try to use them does it click that they really won't work. Moreover, when these people try to find out why things aren't working, (and sometimes after trying various so-far unsuccessful means to have an exception made), they often understand what's happening in core routers and from then on have tended to do a good job of not introducing new prefixes into the core. I am aware of various disclaimers and warnings the registries issue and I'm grateful for them, actually. They've been helpful. Some folks at a couple of our peers/competitors have also been good at protecting their customers by telling them a great deal about CIDR and PI vs PA space. The large failing of CIDRD and the CIDR effort is one of being unable to communicate things to precisely these people receiving new allocations, which in large part is due to the inability to get any documents published. So, as a consequence of some parties being religiously opposed to issuing documents emanating from a part of the IETF that describe what really is happening now -- in order to save newcomers and folks who haven't followed CIDRD a great deal of confusion and effort -- on the grounds that any such publication would look like the IETF "endorsing" some evil greedy bastards who are out to rape and screw small providers, people in small countries, small animals, or whatever the cause celebre of this type of zealot happens to be today. The people being screwed are those who have no information about how busy routers are and how untenable lots of addresses of any nature are, and how important aggregation is, and therefore how good PA addresses are to them *until* they run right smack into my filters. The campaign of "keep them ignorant to force providers to abandon this silly notion that currently available routers are too busy to deal with as many unaggregated addresses as people want to present to them" only succeeds in *hurting* small providers and startup providers. And those small providers are who pay my salary, and you better believe that my colleagues and I are very keen on keeping them in business and seeing their customer base and income grow substantially, so that they end up buying more and bigger circuits -- both Internet connections and raw private lines and international private lines -- and keep being able to pay for them for a very very very long time. Sean.

3 2

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

26 Jan '96

| > 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. If you could help more there, then yes, you can think of it as a big challenge. The rest of your message is a good start, and has me thinking, as I've just told Randy in private email. The only other detail is that the consequences of making an exception in one piece of unallocated-from address-space because of the involvement of a single particular organization may have some side-effects beyond engineering that will have to be pondered by some other of my colleagues. This is also something you could help think about, as we will need an answer for "well, you gave *RIPE* a break, why not us?". Sean.

1 0

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

26 Jan '96

Dennis said: >>[192 et al] look like swamps that are ripe for the picking. Bill said: >Already underway as part of PIER Yay. I'm looking forward to the updates. I'm even more looking forward to technology that makes renumbering tractable, because that will end this entire line of discussion pretty much forever. Sean.

1 0

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

26 Jan '96

On Thu, 25 Jan 1996 16:49:48 -0800 you said: >We've got a basic conflict between "smaller" and "better", whose resolution >will require (in the absense of really good renumbering technology) >constraining our insistance on efficient address utilization by measuring >the effect this has on routing tables. We need to get some quantitative >goals assigned to this so we can measure what is "good" and "bad". I'd >(again) suggest the following: A /19 in Amsterdam makes sense as a maximum allocation. A /19 in Uganda doesn't. I think due to different geographics we need to realize that allocation policy has to be different depending on where you are. Hank

3 5