- lir-wg - mailman.ripe.net

Re: Policy Statement on Address Space Allocations
by Vince Fuller 05 Feb '96

05 Feb '96

In message <199602021946.AA16364(a)mail.crl.com>, George Herbert writes: > > >> How do Pipex and Dante get global routes right now? > > > >Oh.. from a whole bunch of different places. > > > > ANS customer routes from ANS > > MCI customer routes from MCI > > SprintLink customer routes from Sprint > > Alternet customer routes from Alternet > > AUNET routes from EUNET > > ... > > > >You get the idea. > > How do they get to Barrnet? SURAnet? Etc? Suranet is at MeaEast. Barrnet is presently an MCI transit customer. Actually, the situation is a bit more complicated than this (in case anyone really wants to know). It is the case that each of the BBN Planet regions are MCI transit customers, but BBN Planet also has presence at MAE-East, FIX-East, MAE-West, and the Pennsauken NAP. We are in the process of finalizing the peering policy for BBN Planet as an integrated whole. In the near future, we will send a notice to the provider community that describes our policy and invites others to establish bi-lateral peering agreements with us. Vince Fuller, BBN Planet Network Engineering

1 0

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 David Miller 04 Feb '96

04 Feb '96

On Sun, 4 Feb 1996, Hank Nussbacher wrote: > On Fri, 2 Feb 1996 14:29:09 -0500 (EST) you said: > > > >I would also be curious how the 60% missing is counted. > > > >If an organization places 99% of their addresses behind a firewall do all > >those not count? > > If you have a class B and use a firewall, then a /27 should be more > than is needed on the global Internet and they should use an address > from RFC1597 internally and return the /16. While that certainly sounds nice from the current context, there are other reasons for wanting unique address space. Things like mergers come to mind, as well as the expectation of better security in ipv6. --- David Miller ---------------------------------------------------------------------------- It's *amazing* what one can accomplish when one doesn't know what one can't do!

1 0

Re: Policy Statement on Address Space Allocations
by Hank Nussbacher 04 Feb '96

04 Feb '96

On Fri, 2 Feb 1996 14:29:09 -0500 (EST) you said: >On Fri, 2 Feb 1996, Howard Berkowitz wrote: > >> > > We are working on the 192.x.x.x swamp right now. >> > > Rough estimates (with much more accurate data @ NANOG) >> > > >> > > 60% - invalid or missing contact information >> > >> > This is interesting. How about a policy that says if nobody can contact >you >> > and none of your addresses are reachable, then after some period, your >> > addresses get recycled. >> > >> > >> By addresses not being reachable, are you effectively saying that any >> enterprise that does not want to connect to the Internet must use >> RFC1597 address space? >> >> Anyone have an idea how much of the address space is used for >> registered addresses of organizations that do not connect to the Internet? > >I would also be curious how the 60% missing is counted. > >If an organization places 99% of their addresses behind a firewall do all >those not count? If you have a class B and use a firewall, then a /27 should be more than is needed on the global Internet and they should use an address from RFC1597 internally and return the /16. > >Unfortunately, I don't think we can base much policy on whether or what % >of addresses are reachable from the internet. > >--- David Miller >---------------------------------------------------------------------------- > It's *amazing* what one can accomplish when > one doesn't know what one can't do! > Hank

1 0

Re: Policy Statement on Address Space Allocations
by Scott Huddle 03 Feb '96

03 Feb '96

> Scott Huddle writes: > >> Name a backbone which doesn't come into the San Francisco Bay Area. > > > >Um, all of the rest of the world's providers. > > Backbone, Scott. Backbone. You, Sprint, PSI, Alternet, > Net-99, etc. All the rest of the world's providers are getting > transit from some backbone. If all the transit backbones are in the > area the problem is merely political. They aren't... ICM, Pipex, and Dante to name three. Sprintlink may play nice and handle ICM, what do you plan to do to address the others? And for the next trick, how do you scale your solution to the next site? Does your solution require sites of all the backbone providers to be at each metropolitan exchange? Doesn't this put a limit in the number of providers that can do this? -scott

4 7

Re: Policy Statement on Address Space Allocations
by Paul Ferguson 03 Feb '96

03 Feb '96

At 02:16 PM 2/2/96 +1100, Geoff Huston wrote: >> >> > We are working on the 192.x.x.x swamp right now. >> > Rough estimates (with much more accurate data @ NANOG) >> > >> > 60% - invalid or missing contact information >> >> This is interesting. How about a policy that says if nobody can contact you >> and none of your addresses are reachable, then after some period, your >> addresses get recycled. > >How about a policy which says that if you fail to pay an annual amount >by a due date then a process is commenced with an outcome such that >your registration details expire and the associated number space is no >longer registered to you. > >Geoff > Would this process, perhaps, be associated with a route announcement charging scheme? - paul

2 1

a question
by Jarmo.Oksanen＠tele.fi 02 Feb '96

02 Feb '96

Hello, During the last RIPE-23 there were discussions about renumbering the 192 C- classes assigned in Europe. Is the renumbering just 'under' discussion or is it really going on? We have several 192 blocks, like 192.58.41 - 192.58.89 192.83.0 - 192.83.100 192.89.0 - 192.89.255 192.130.0 - 192.130.255 192.194.0 - 192.194.255 I think the blocks 192.58 and 192.83 should renumber, but the rest of the blocks are /16 routes. Is there really needs to renumber these blocks? Could somebody 'update' me about this renumbering? Thank you! Japi -- Jarmo Oksanen Telecom Finland Ltd Telephone: +358 2040 72419 Mobile phone: +358 400 737 684 Fax: +358 2040 72669

1 0

Action point 22.13: Inic & handles
by Geert Jan de Groot 02 Feb '96

02 Feb '96

I forgot to bring up the following action point during the meeting: * 22.13 Geert-Jan de Groot To try to follow up with the InterNIC about accepting person objects with RIPE-Handles. I received the following message from the Internic, which indicates that this problem is solved. Many thanks to Mark and the rest of the Inic bunch for fixing it. My apologies for not formally bringing it up during the meeting; too many things going on at once I guess. On the other requests (such as in-addr glue record authentication) I can report that they're working on it, and we are discussing some details which have to be resolved. Stay tuned. Geert Jan ------- Forwarded Message Date: Wed, 24 Jan 1996 12:55:11 -0500 From: Mark Kosters <markk(a)internic.net> To: geertjan.degroot(a)ripe.net Subject: ripe handles Geert Jan We now will accept ripe handles for domains as well. We just finished testing and have deployed the new software. [....]

1 0

Re: Policy Statement on Address Space Allocations
by Hank Nussbacher 02 Feb '96

02 Feb '96

On Fri, 2 Feb 1996 14:16:18 +1100 (EST) you said: >> >> > We are working on the 192.x.x.x swamp right now. >> > Rough estimates (with much more accurate data @ NANOG) >> > >> > 60% - invalid or missing contact information >> >> This is interesting. How about a policy that says if nobody can contact you >> and none of your addresses are reachable, then after some period, your >> addresses get recycled. > >How about a policy which says that if you fail to pay an annual amount >by a due date then a process is commenced with an outcome such that >your registration details expire and the associated number space is no >longer registered to you. and how about a waive of the fee if you return smaller aggregates for a larger one (I started doing something similiar in Israel 3 months ago). > >Geoff > Hank

1 0

Re: Policy Statement on Address Space Allocations
by Nick Vermeulen 02 Feb '96

02 Feb '96

Hi, imho, most multi-homed sites can do with a partial routing table; organisations who want or need to have full routing tables should put extra RAM in their backbonerouters to meet demand. When 64 MByte isn't enough anymore...buy a cisco 7500 series which can hold 128 MByte RAM. you can minimize the number of your full-routingtable routers with ebgp multihop features (for multi-homed customers) in the mean time...monitoring routing tables and notifying net-admins that advertise less efficient aggregates will help. i don't think renumbering the networks of ISP customers is a real-world solution (they will really hate you for that). ip-ip tunnels have lot's of problems and overhead too. in short: optimize aggregation within current assignments, hope that it helpes, and lobby for budgets if it doesn't. that sounds real-world to me... cheers, Nick Vermeulen Wirehub! Internet eMail : nick(a)wirehub.net Oudedijk 196 tel : +31 (10) 4110403 3061 AS Rotterdam fax : +31 (10) 4113556

3 2