January 1996 - Test - lists.nanog.org

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

27 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.

6 10

Re: Policy Statement on Address Space Allocations
by matthew＠scruz.net 27 Jan '96

27 Jan '96

Original message <96Jan27.012415-0000_est.20615+371(a)chops.icp.net> From: Sean Doran <smd(a)icp.net> Date: Jan 27, 1:24 Subject: Re: Policy Statement on Address Space Allocations ... > > The encouragement, IMHO, should be in the form of the work > PIER is addressing (sorry about the pun), some possible > future renumbering tools, NATs, or any other technology > which results in making a change of addresses painless and > quick, so that people have little or no reason to object to > using provider-supplied addresses. Right. Exactly. But UNTIL such time as easy renumbering for everyone is a reality, watching a world where the policy of one of the big service providers collides directly with the policy of the address assignment agencies makes me wonder what whose goals really are, and really REALLY glad that the company I founded is as big as it is already. And that's because if I was starting that company TODAY, and I knew that in less than two years down the road I'd be in a position where I'd be multihomed and/or at an interchange point, I'd be stuck... because there's no way I could get an initial address block for assignment to my customers that was also big enough to pass Sprint's routing filters. I don't even understand how I'd effectively use such an address... If I get an address from my provider, I'm doomed to renumbering in the event that provider can't provide me with all the service I need, and I can't subject my customers to that. But the first "portable" block of addresses I could get (speaking hypothetically as a new ISP) wouldn't work to get everywhere, because Sprint (and no doubt others in the future) would ignore the announcement. Since those addresses would be worthless, there's no way I could ever use them, and thus no way I could ever satisfy the Internic that I'd effectively used my first block of addresses and was ready for a bigger one. I forsee a large number of new /19's filled with fictitious entities, followed immediately by the application for an additional, larger, block... and if we're concerned about the efficient use of address space (and not just routing table size) that's a serious waste. Why can't we just all agree, at least for a little while, on the SAME address efficiency vs. routing table size tradeoff? RIPE, et al has decided that initial assignments of /19 are the right tradeoff. Sprint has decided that /18 (or maybe /17 now) is the right tradeoff. Similar, but not the same, choice. If it was the same, this argument would be over and new providers could continue to spring up without having to wonder how they're going to get their first addresses routed and NSP engineers would know that routing table size, while perhaps a bit larger than they'd wanted, would still be seriously limited in growth compared to the alternatives. I really don't care whether Sprint changes their filter to be at /19, or if RIPE, IANA, et al decide that Sprint really is smarter than they are and that /17 is the correct tradeoff point, but its just 2 bits! Stop claiming technical superiority and just make it work right for everyone simultaneously! We (scruz-net) advertise more addresses than I'd like, but the Internic forced us into that corner. We asked for a big block over a year ago. 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. But I'm not going to go tell a hundred or more customers (a good number of those 204.* addresses are subnetted into /29 for "small LAN" customers) that, without the benefit of any renumbering tools, they get to change everything around and sit on the phone all day with our tech support staff until it works correctly again. -mattthew kaufman matthew(a)scruz.net

2 1

Re: Policy Statement on Address Space Allocations
by Vadim Antonov 27 Jan '96

27 Jan '96

Forrest W. Christian <forrestc(a)imach.com> wrote: >Is there some other method which would be as effective to destroy a >specific net's connectivity to the majority of the net? A few come to >mind right now: > 1) ip route <luser's address & mask> null0 Deliberate injection of bogus routes is the reason sufficient to disconnect from the provider who's doing that completely. *No* serious ISP will ever want to unleash the routing wars. > 2) ip filtering: > - Probably uses more CPU than #1, but doesn't screw > with the routing tables. You may want to ask Sean to send you a copy of SL-MAE-E's configuration. There already are *huge* filter lists, just to maintain sanity of routing. >I doubt you're going to need to add many filters :) Heh. Never underestimate the laziness (overworkiness, underpaidness, or just plain cluelessness) of netadmins. Seriously, there are people which still believe that CIDR is a conspiracy. >As far as who will run the programs to check for this, I'm sure that a >suitable home for the tools necessary could be found. It is not the tools, it is the politics. Getting rid of nukes completely is a nice goal. Does anybody seriously think it can be done today? Not until we see the last of Kings and Presidents (not mentioning Senators and other Servants of the people). A net.politzai is a very unrewarding role, potentially leading to real lawsuits. Passive filtering with well-announced policy at least gives no food for lawyers. Sprint's policies are a result of extensive consultations between engineering, marketing and legal people (and activist customers), and is a way for Sprint to protect its own network from the routing collapse. --vadim Not speaking for Sprint.

2 1

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

26 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: The World Responds to a Non Announcement
by Sean Doran 26 Jan '96

26 Jan '96

Alan says: | Tell your upstream that outages based on routing table issues are not | acceptable. If they don't get their act together, please pull out your | service contract... You'll find a clause in your contract for 'unacceptable | service'. Exercise it. | | We've got one in each of our contracts, as do our downstreams. We're | this close to exercising one of these options on our upstream, and it's | rather ironic that they've voices who most agree w/ me, although they | blame all their problems on the other bad people who don't aggregate. | | More /19 business, Sean, only go deeper. Make the lazy hurt. Wow, real, live, honest-to-goodness customer feedback. Noted and circulated. Sean.

1 0

Re: Policy Statement on Address Space Allocations
by Vincent J. Bono 26 Jan '96

26 Jan '96

> On Fri, 26 Jan 1996, Yakov Rekhter wrote: > > > Forrest, > > > > > The only problem this leaves is how to decide who gets an /18... > > > > That is a *very good question*. Different answers to this question > > have *quite different* implications on the address space utilization. > > My personal opinion is that you err on the side of giving someone an /18 > that doesn't need one, However you DO need to be careful about assigning the > space. The general qualifications I would imagine are: > > 1) ISP's assigning (non-portable?) address space to non-dialup customers, > on a fairly regular basis. > > 2) Large-ish companies which of themselves would need the /18. > > 3) Anyone who is multi-homed on a "permanent" basis. (Probably > mostly covered by 1&2) > > -forrest How about trying to prevent the static assignment of addresses to dial-in customers? This chews IP space like there was no tomorrow...

1 0

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

26 Jan '96

| Did you find a four leaf clover after the snow melted, or find a lucky | horse-shoe in the fields today? ^^^^^^^^ No, but you got the first seven letters right. | What did those in the Dark Middle Ages do when branded | a heretic by the religious zealots ? | Answer: | Most of them were put to the flame and ridiculed. Ahh, the good old days. Nowadays people who think that they deserve the label religious heretic have to go all out to invite ridicule upon themselves. Sad, really. There must be easier ways for people to get abuse, contempt, and other forms of negative attention, than spending so much effort trying to make people who are well-intentioned and generally well-respected look like bad guys or ignoramuses, while telling us about what books you happen to be reading, or where you're flying off to next week, or what your second cousin twice removed had for lunch yesterday, as if people here are such snobs that they will think more highly of you if you are reading something by Vidal or whoever, or are making large amounts of money as a consultant, or have a diary detailing the history of network XYZ, or live near Dulles Airport. Well, maybe some do. Who knows? But anyway, although I don't think very much of you and your postings, almost exclusively because of your apparent need to trump up your own talents by disparaging others', don't count on me to suggest removing you from any open mailing lists, publically or privately. Maybe it's my sense of humour, or a sadistic streak a kilometre wide, but I *enjoy* seeing people make absolute fools of themselves in public. And you, you're practically Monty Python's Flying Internet. Sean.

1 0

Re: Policy Statement on Address Space Allocations
by Eric Kozowski 26 Jan '96

26 Jan '96

>If you convince the registries to allocate no longer prefix than an /18 >or a mix of lengths up to say /19 or /20 (such that no more than 1000ish >are allocated) to ISP's or multihomed companies, and then require that >the announcement must match the allocated block, you can guarantee that >the routing table will not exceed the 1024 per /8. > >Then, some of you will ask how to enforce this. Once every so often, you >dump the BGP routing tables from strategic routers. If you see any >non-matching prefixes, you send an email to the network coordinator for >the allocated block giving them a set amount of time to clean it up. Any >routes which are not cleaned up by the deadline are added to a filter >list which could be carried on routers. > >This method would have (at least) the following advantages (or >disadvantages, from your particular viewpoint): > > 1) You could reasonably assure that the number of prefixes in an > /8 would match what was allocated. > > 2) Because of 1, if you get the registries to set their > allocation policies such that no more than 1024 (or the target number) > blocks are allocated per /8, you can guarantee that the number of > routes in an /8 is not too far out of wack with the target. > > 3) You can give those people moving providers a grace period to renumber, > say 30 days. Essentially, the time given to clean up the routing > tables. This would be a side effect of the "you have 30 days to fix > the routing tables or else". > > 4) You eliminate the wasted space of addresses with prefixes longer than > /18 being allocated. An excellent, well thought out proposal. I like it. Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1

1 0

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

26 Jan '96

| The registries (although I shouldn't speak for all of them) would be | more than happy to allocate address space in whatever way the ISPs | agree is the "right way". The problem is, you can't agree on what's | the "right way" of doing it. It's like herding cats without the benefit of a laser pointer. | They do not want to be tied to their upstream ISP. Understandable. Hence, the people who actually develop technology to renumber ISPs and things downstream from them, whether that be with NATs (hi cisco) or things emanating out of PIER, will be heros. (Hopefully rich too). | But consider the hundreds of ISPs that don't. What's NANOG? Sigh. Sean.

1 0

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

26 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