- Test - lists.nanog.org

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

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

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

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

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

27 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

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 Yakov Rekhter 26 Jan '96

26 Jan '96

Daniel, > If you insist on prefix-length filtering I have proposed a soloution > for future address space allocated via the RIPE NCC several times: > > - set your inbound prefix length filter to /19. > > - The RIPE NCC will *guarantee* that we will not make more than > 1024 non-aggregateable allocations from each /8. Would the RIPE NCC provide such non-aggregatable allocations irrespective of how many hosts would be covered by such an allocation ? Yakov.

2 2