- Test - lists.nanog.org

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 ?

3 2

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

29 Jan '96

At 23:45 1/26/96, Matthew Kaufman wrote: >They >gave us a /21. We used it right up and asked for a big block again. They >gave us a /20. We argued with them about it, and they refused to budge, so >we went ahead and used it up to. Then we asked for a big block again. THAT >time they believed us. We got a /16. Had they given us the /16 the first >time, we'd have 2 fewer announcements in 204.*, and still not be quite done >using it up. InterNIC's error was not in doing what they did to you but in not aligning the 1st (or at least the 2nd) of those blocks on a RATIONAL boundary (such as /16) and giving you your CIDR Block from the front end of the range [reserving the rest for your expansion needs for a designated period of time (or until they needed to recycle the unused part of the /16 block for other users)]. Since the InterNIC assigned blocks are not going to be able to be aggregated anyway, why not just allocate them on large boundaries and leave room for expansion that will NOT introduce a new announcement when the ISP comes back for another Block. They can do Garbage Collection when they run out of the larger CIDR blocks and need to reclaim the "wasted" space (there is no downside to this method that is worse then the current system of supplying non-contiguous CIDR blocks to the same ISP [as in your case]). If you ask for a /16 to hold you for 1 or 2 years, then they should give it to you but only allow you to use the first /21 until it is full and you can justify expanding it with a /20 or to a /19 (ie: Give you a /19.5 in lieu of the /20 they gave you). If after the 1 or 2 year period is over and you are only using the first /19, then they can leave the 2nd /19 as an expansion area and reissue the other 6 /19s for other ISPs.

2 1

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

29 Jan '96

>" The InterNIC allocates addresses to ISPs based on the slow start > procedure as detailed in the ISP guidelines. Please utilize the /19, > once you have reassigned the /19 and SWIPped them you may request > additional address space and if the InterNIC feels you are assigning > them efficiently you may request additional address space." Because of this policy ISP's should start getting allocations from the InterNIC as soon as possible. If you get allocations from another provider, you don't gain any history with the InterNIC. All of that history goes to the provider's allocations, not yours. When you outgrow a provider (and the provider's provider), and later go to the InterNIC, you start over again with 'slow start.' I made this mistake, and it has cost me dearly over the years. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

6 6

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

28 Jan '96

At 0:16 1/27/96, Alan Hannan wrote: > Noone in the world complained that Windows 95 couldn't read apple IIe > diskettes. Can it read MS-DOS 5.25 Disks? If not, the Apple II problem is subsumed under the media support one <g>. Windows is very self-centered. It can't read Macintosh Disks (you have to create your Windows disks on the Mac to transfer the data since the Mac has no problems reading/writing Windows Media).

1 0

Re: Creative routing (was Re: Policy Statement ...)
by Sean Donelan 28 Jan '96

28 Jan '96

>Well, there's an alternate tactic for a tiny tiny company. I was thinking of a slightly simplier example. Nevertheless, Mr. Doran's example confirms NSP engineers are capable of all sorts of routing hacks when it is in their self-interest to do so. Even if it means introducing a /32 into their network. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

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

Creative routing (was Re: Policy Statement ...)
by Sean Donelan 27 Jan '96

27 Jan '96

If such a company exists, and had such an incredibly popular web site, I wouldn't worry too much. I suspect the major NSP's would engage in several creative routing configurations (short-circuits, backdoors, etc). If only in an attempt at self-preservation to keep the NSP's backbone interconnects (and customer service phone lines) from melting down. Much like a radio station with a single telephone contest line can bring down an entire city's telephone system. I'd bet even Mr. Doran (or Mr. Doran's managers) would make an exception given the right economic incentives. BTW, my definition of a "very, very, very popular web site" requires multiple DS-3's (or whatever the backbone du jure is using) to support the bandwidth needs. A site at the end of a 56K line isn't going to be very, very, very popular for very, very, very long. >Consider a company, perhaps a very, very, small company, which happens to >have a very, very, very popular web site. For the sake of argument, let's >call this company "Netscape," (although this company isn't Netscape, but >this will create the appropriate picture in your mind). > >This company needs only a microscopic amount of address space, something on >the order of a /28. > >The company wishes to have more than one connection to the Internet through >more than one of the major providers, for bandwidth & reliability reasons. > >It sounds to me, based on the discussions which have been occurring, that >this company can't do what they want---unless they lie and somehow gobble >up a /18 worth of address space. > >Is this true? > >jms > >PS: Double-numbering hosts won't work; because of monumentally poor >programming practices on the part of WWW developers, WWW clients do not >discern multiple A records for a given host name. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

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 Hank Nussbacher 27 Jan '96

27 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

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