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

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

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

26 Jan '96

On Fri, 26 Jan 1996 11:17:43 +0000 (GMT) you said: >I cannot accept that we have to >beg< RIPE like a good little provider >for address space that should be allocated to us from the USA anyway. >I will be interested to see how the RIPE actually works (and not just >listening to Daniel dictate policy by e-mail) when I go to my first RIPE >meeting next week. So far it seems like a bureaucracy that is entirely >self perpetuating and self interested without consider what the people >who pay for its very existance want. sigh. Just like an unelected >government in fact. ILAN pays RIPE and I do think that RIPE listens. If you compare RIPE to Internic, I think they are way ahead in the way of user representation. Your comments are more appropriate for Internic, IMHO. I have followed RIPE's development for the past 5 years and I will honestly say that I am glad that RIPE is what it is and that we are not in the sphere of Internic. >Peter Galbavy peter(a)demon.net Hank Nussbacher

1 0

Re: Policy Statement on Address Space Allocations
by miguel.sanz＠rediris.es 26 Jan '96

26 Jan '96

On Jan 25, 14:46, Yakov Rekhter wrote: > Subject: Re: Policy Statement on Address Space Allocations ... > > It's the other way round: SPRINT should tell his customers he can't > > guarantee 100% global Internet connectivity because he disagrees with > > the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC. > > Would you assume that anyone whose address allocation follow > "the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC" > is guaranteed 100% global Internet connectivity ? > No one can assume anything in this fast moving world, but at least I assume the last A of 'IANA' means 'Authority' and not 'Anarchy'. If the aim is global connectivity there must be some common rules everybody should follow. If someone has problems with them he can try to convince the authority/community to change them, but in a civilized way, without trying to impose anything to the rest of the world. Miguel __________________ __ ______________________ /_/ Miguel A. Sanz __ __ Email: miguel.sanz(a)rediris.es RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5855152 Serrano 142 __ Fax: + 34 1 5855146 E-28006 Madrid /_/ SPAIN NETWORK MANAGER ____________ Spanish Academic & Research Network ___________________________

3 2

Re: Policy Statement on Address Space Allocations
by miguel.sanz＠rediris.es 26 Jan '96

26 Jan '96

On Jan 25, 8:20, Sean Doran wrote: > Subject: Re: Policy Statement on Address Space Allocations > ... > > 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. > It's the other way round: SPRINT should tell his customers he can't guarantee 100% global Internet connectivity because he disagrees with the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC. They might want to look for a different transit provider... Regards, Miguel __________________ __ ______________________ /_/ Miguel A. Sanz __ __ Email: miguel.sanz(a)rediris.es RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5855152 Serrano 142 __ Fax: + 34 1 5855146 E-28006 Madrid /_/ SPAIN NETWORK MANAGER ____________ Spanish Academic & Research Network ___________________________

8 8

Re: Policy Statement on Address Space Allocations
by Scott Bradner 26 Jan '96

26 Jan '96

> I think the hierarchical routeing is one step *worse* than the above. > The address *defines* the route the packets take ? What about the real, > live multi-interconnect, multi-homed Internet we use ? Maybe I have > misunderstood the way IPv6 addressing works. HR sure does sound real bad, just for grins what is your plan to keep the routing table size within the constraints of the routers without it? Scott

1 0

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

26 Jan '96

Jeff Young wrote: | say what you will about this policy, but someone (sean?) thought | long and hard about it's implications. i didn't like the abrupt | manner in which it was implemented, but it does take guts and it | is pretty elegant: Thanks, Jeff. Once again I shall repeat my apologies -- the original intent was to make sure the filters would break things on day one, rather than retroactively apply to the number of people whose route announcements had been leaked in by mistake. Despite the immediate retrospective thought that it was a cute way to avoid accusations of collusion among big providers, I did very much regret the work you folks and others had to do when this got dropped into place. OTOH, well, there had been several months' warning about the details... 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. Meanwhile, yes, it's a slight competitive advantage. :-) (Frankly though, that was a at first side-effect of not having the ability to do the outbound filtering immediately, but it rapidly seemed like a smart thing to do to make other people think about similar filtering. An interesting thing to wonder about is how different the early days of CIDR deployment would have been if rather than aggregating at the source, people were to have set up some sort of inbound filtering at places like MAE-EAST.) | nobody said it would be boring. :-) Yup. Sean.

1 0

Re: Policy Statement on Address Space Allocations
by John Curran 26 Jan '96

26 Jan '96

Daniel, Interesting message (limit of 1024 aggregated routes per /8); I seemed to have missed this approach in past email. It still has the side effect of encouraging downstream providers to remain with their current provider, _if_ their prefix happens to be from a block of the address space which has become fragmented and is being filtering by allocation. The only real problem I see with this approach is that there is a no peer group based on allocations, and therefore no mechanism which lets folks in the same block coerce each other into good aggregation... (Imagine email saying "Please, my fellow 206'ers, let's squeeze out another 600 routes before XXXnet's filtering deadline!", "207/8 -- Love it or leave it", and my personal favorite, the eventual 192/8 T-shirt which says "192/8 - Beyond Hope and Filters" ) /John === >Sean, > >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. > > - The RIPE NCC will continue to work with the providers to > maximise aggregation. Our goal is a maximum of 1024 routes > per /8 visible at major exchange points. Incidentally this > is the same goal that you seem to have. > > - Should we fall to short of the goal in your opinion, you can > start to filter on the list of allocations which is available > from our whois database (whois -h whois.ripe.net -m 19x/8). > Note that we guarantee that these will be no more than 1024. > >Now given the current performance of everyone I personally believe >that we deserve a little relief from the 1024 goal but I am willing >to discuss on the basis above. > >Can we please enter into a discussion why this is a bad idea and/or >why it is not acceptable to you personally or your employer. > >Daniel >...

1 0

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

26 Jan '96

Paul - Thank you for your kind words. Sprint's filtering policies have led directly to a more survivable SprintLink and ICM, which is to the benefit of Sprint's Internet customers. The trade-off is the inability to reach people who have just hooked up to other parts of the Internet for the first time and who are using addresses that are in conflict with what we feel our routers can support. So far the two (yes, two) customer-originated complaints involving reachability affected by our filtering have been resolved by straightforward renumbering of the non-SprintLink entity. There have, by comparison, been several hundred rather angry messages from non-customers who hook up and find that they can't use their freshly-acquired addresses to talk to SprintLink/ICM, and who claim never to have been warned that this was a virtual certainty. Two troubles in several months are rather obviously dwarfed by the thousands of customer-originated complaints about routing problems after major exchange points or other major routing transitions happen (we have observed major peers having serious difficulties with their routing system scaling recently), not to mention the most recent serious connectivity problem which involved working very closely with our vendor on getting new technology out the door that will let us scale with increasing traffic and hopefully better deal with the scaling of the increase of globally-announced routing informaiton. Customer feedback I have gotten about our CIDR and other routing policies tends to be very positive. Indeed, a number of our customers are active participants in CIDRD, NANOG, EOF and other forums where these policies sometimes are discussed at length, and none of them seem very shy about putting forward their own points-of-view, all of which is remembered and thought about frequently. We are, after all, very keen as a corporation to develop and maintain long-lasting relationships with our customers. It is possible that a number of unhappy customers have not made themselves heard, or that a number have simply voted with their feet on this precise issue, however there certainly has not been enough of the latter to justify any sort of re-think on this particular policy. Whenever I see "Sprint sucks" in newsgroups and mailing-lists, it's almost always because of reliability problems. One of our most serious backbone reliability problems involves routing convergence times and long-term stability, and this particular routing policy in combination with BGP dampening and other tools and techniques we've developed here, goes directly to the heart of those problems. I am always interested in proposals that will help provide a more robust and stable level of connectivity and performance to our entire customer base, and if you have any ideas that would make it reasonable to withdraw our prefix-length filters and _improve_ our routing stability, I would be very glad if you could detail them. Sean.

1 0

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

26 Jan '96

At 11:47 1/25/96, Daniel Karrenberg wrote: >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. In >particular it will not be influenced by marketing predictions, amount of >capital available or the shoe size of the lawyers visiting our offices. >(NB: The value of /19 might change at some point, but the fact that >every newly established registry gets *the same size* initial allocation >will not.) When you allocate this /19, do you do so at such a boundary that it can be converted to a shorter (/18-/17-/16-etc) prefix at a later date thus avoiding the need to assign another block or forced renumbering (ie: "We will give you a new /18 block and you have x months to return your old /19 [ie: They are given a 2nd /19 worth of numbers and they most move their old /19 into the other half of the new /18]). If done correctly, you can reclaim the over allocation of "reserved for expansion" blocks after reaching the top of the original CIDR block and then doing the 2nd pass of NEW assignments by halving the space between "phase 1" allocations (in those segments where there has been no expansion of the /19 allocation into a /18-etc).

4 3

Re: Policy Statement on Address Space Allocations
by iljitsch＠daisy.bART.nl 26 Jan '96

26 Jan '96

Hi Randy, > > Yes. And of course you don't care about a small side-effect: it will > > drive small ISP's out of business. The only way to avoid that is to do > > business with large ISP's such as Sprint. > It will force folk who need only long prefixes to get their IP allocation > from their upstream provider. But that's not possible in the case of a multi-homed network, however small. > > So in stead of picking on people smaller than you, go after the types > > that accounce 50+ routes per AS. That's the _real_ problem! > Probably not the best metric either. What if they are all /16s? That would mean they connect more than a million hosts to the Internet. There can't all that many networks that are in this position... Let's look at a few examples. For instance, AS 1890. They announce: 15 B, 12 C, 1 /15, 4 /16, 2 /19, 2 /22. Total: 36 routes. If they get rid of the individual class C's and aggregate two of the /16's (they are consecutive) that would save 13 routes, more than a third. And AS 1103, they announce: 26 B, 12 C, 1 /9, 1 /10, 1 /11, 3 /16, 1 /17, 1 /18, 1 /19, 2 /21, 2 /22, 4 /23. Total: 55. If they renumber the class C's and the /23's and announce 145.0.0.0/8 in stead of 145.0.0.0/9, 145.128.0.0/10 and 145.192.0.0/11, that would save 16 routes, more than a quarter. Then there is AS 5390: Network Next Hop Metric LocPrf Weight Path *> 193.67.112.0/23 194.72.4.137 100 2856 2855 5390 i *> 194.134.0.0/22 194.72.4.137 100 2856 2855 5390 i *> 194.134.0.0/19 194.72.4.137 100 2856 2855 5390 i *> 194.134.4.0/23 194.72.4.137 100 2856 2855 5390 i *> 194.134.6.0 194.72.4.137 100 2856 2855 5390 i Without even renumbering they can save 3 out of 5 routes. Now I hope the good people of AS 1890, AS 1103 and AS 5390 forgive me for using their AS'es as an example, I'm sure the results will be the same for the majority of AS'es. So what does this tell us? 1. The routing table can be reduced by at least 5 - 10% by taking better advantage of aggregation opportunities. 2. Another 25% can be accomplished by renumbering individual class C's and very long (>20) prefixes. Iljitsch van Beijnum bART Internet Services

1 0

Announcement for Local IR Training Course in Lisbon
by RIPE NCC Training 26 Jan '96

26 Jan '96

* * * Announcement * * * Local Internet Registries Training Course Date: Monday, 25th March, 1996 Time: 0900 - 1700 Venue: RCCN Fundacao Calculo Cientifico Nacional (FCCN) Rede da Comunidade Cientifica Nacional Av. do Brasil, 101 1799 Lisboa Codex Portugal Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries that contribute to the RIPE NCC. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to <training(a)ripe.net> if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Daniel Karrenberg --- Course Outline -------------- For this second course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to <training(a)ripe.net>. Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at <training(a)ripe.net>. You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

Announcement for Local IR Training Course in Paris
by RIPE NCC Training 26 Jan '96

26 Jan '96

* * * Announcement * * * Local Internet Registries Training Course Date: Monday, 26th February 1996 Time: 0900 - 1700 Venue: Hyatt Hotel Airport Charles de Gaulle Paris France Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries that contribute to the RIPE NCC. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to <training(a)ripe.net> if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Daniel Karrenberg --- Course Outline -------------- For this second course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to <training(a)ripe.net>. Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at <training(a)ripe.net>. You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

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

26 Jan '96

>If you really need it, a much more effective method to get short term relief >is to squeeze some of the "history" out of the forwarding table. The 192.* >block, and some of the high 190's, look like swamps that are ripe for the >picking. This is a though I've been mulling over for a while. Why not have the IANA set a "flag day" for the 192 space. Say, on 1 March 97, the 192.0.0.0/8 space will no longer be routable. At this point, the IANA, then sits on the space, now removed from the routing tables, and reassigns it at a later date. OR Just make 192.0.0.0/8 rfc1597 type of address space? Just a thought that would need more serious discussion to implement. 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 Hakan Hansson 25 Jan '96

25 Jan '96

At 08:20 1996-01-25 -0500, Sean Doran wrote: > >> 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 [etc. etc.] Since, you have presented examples routed through 3300 I felt it was ok to comment this. We have experinced that customers of ours sometimes later purchased a connection from another ISP keeping the connection to us. Therefor will all allocation of address space to that customer no longer be aggregated by us. Even if we know that this customer in most cases has customers of his own, we usually don't reserve blocks for him. Well, you see the result in the routing table. I thought in the beginning of CIDR that I would never had to announce anything but 194.16/13. For connectivity reasons this is not possible. The only solution might be that every network that later becomes an AS has to renumber the complete network (and it's customers also). In addition to that he has to become a Local Internet Registry with his own address space. One AS, one registry.... /Hakan -- Unisource Business Networks Sweden -- Uniplus Internet Services * TIPnet NMC * Goteborg -- phone +46-31-7708072 * fax +46-31-7114664 -- PGP: http://dojan.tip.net/hh/PublicKey.htm

2 1

1st draft: proposed agenda - DB-WG at RIPE 23, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

This is the 1st proposal of a draft agenda for the Database-WG at RIPE 23 in Amsterdam. **Message to the NCC WG scheduling department: If at all possible - please have the DB-WG meeting slot(s) scheduled near the end of the WG stream(s). Thank you! I'd propose to have 2 sessions, - one for the more formal items (A. - D., Y., Z.) and - another one for the more general aspects (E., F., G.). The "general aspects" session should probably precede the formal one. As always, additons, comments, etc. welcome! Apologies if I missed something obvious... See you, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Agenda: Database-WG, RIPE 23, Amsterdam, NL ------------------------------------------------------ A. Administrative stuff - volunteering of the scribe - WG-agenda bashing B. DB-SW report - general status report - "realtime" shadowing - hierarchical authorisation for creation and update - backlink implementation - automatic handle assignment C. DB-Objects and attributes - referral mechanisms and distribution of authoritative data - stored/processed attribute (A: 19.12) - do we want/need a registry object? - mcast extensions for inet-rtr:, peer: attribute (A: ) - ROLE/NOC object, handling of lookup recursion - URL attribute? (credits for the idea to Erik-Jan Bos) D. Copyright for the RIPE-DB proposal to have every whois query return % data is copyrighted, and a pointer to the (C) definition of comment and/or meta-characters (%, #, *) ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ E. Databases and registries interoperation brainstorming about needs, methods,... the 192 review project by B.Manning quality control of data, duplicates alert, fuzzy matching... uniqueness of names across databases (AS macros, route) references to data in a different database common update mechanism for "all" databases (multiple source: values? auto forwarding?) proposal for a coordinated development project? F. User Interfaces Tools online documentation G. Authentication and security ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Y. Input from other WGs Z. AOB Draft 1.0, 23-JAN-1996 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

ripe-104++ - Summary of Policy Changes
by mnorris＠dalkey.hea.ie 25 Jan '96

25 Jan '96

The schedule of WG meetings at RIPE 23 has been posted and the two sessions I sought for the Local IR meeting are back-to-back on Monday afternoon. A meeting of the MBONE WG parallels the second session, so I propose to use the first session (14:00 to 15:30) solely for discussion of the ripe-104++ draft circulated on Monday (copies available at ftp://ftp.ripe.net/ripe/drafts/ripe-104++.[ps|txt] ) As mentioned before, the draft is neither complete nor thoroughly checked for syntax, typos etc. Leaving those aside, the plan is to discuss only the substantive policy issues on Monday. So I've tried to summarise the changes in policy and procedure as they affect RIPE, the local IRs and the ISPs. There's repitition and omission here, but it should serve as a draft guide for the debate. Btw, page numbers refer to the PostScript version. Cheers. Mike Norris ripe-104++ - Summary of Policy Changes -------------------------------------- 1. 2.2. Goals of Public Address Space Distribution (page 4) The goals of: Uniqueness Aggregation Conservation Registration are explicitly stated. 2. 2.4 Validity of assignment (page 7) Assignments of any kind of address space are valid as long as the original criteria on which the assignment was based are still valid. 3. 3. Address Space Assignment Procedures 3.2.1 Required Information (pages 9 to 17) The following set of information must be provided with every with every request for an address assignment. 3.2.1.1. Overview of Organization Contact Persons 3.2.1.2. Current Assignment Space Usage 3.2.1.3. Request Overview Size of Request Addresses to be Used Number of Subnets Internet Connection Country Private Address Space Request Refused PI Requested 3.2.1.4. Addressing Plan 3.2.1.5. Database Information Organization Personal Data 3.2.2. Additional Information Deployment Plan Topological Map Special Circumstances Verification Information 4. 3.3. Evaluation (pages 17 to 19) Every request requires an individual evaluation process that takes current assignment guidelines into account. In the process, it is essential that IR's work to prevent the stockpiling of address space. Meanwhile, to enable proper routing, one must make strategic decisions with regard to aggregation. Evaluation Steps 1. Current address space usage 2. Network Overview 3. Private Address Space 4. Very Small Enterprises (VSE's) 5. Addressing Plan 6. Additional Information 7. Address Reservations 8. Static Dialup 9. Virtual Hosts 3.4. Assignment Procedures 3.4.1. Assignments within Allocations (page 19) Specifically, each set of address space assigned should start on a CIDR (bit) boundary. 3.4.2. PA vs PI Space (pages 20 to 22) Clear contractual arrangements which specify the duration of the address space assignment are mandatory for every assignment of PA address space. Although not strictly required, it is strongly recommended that contractual arrangements are made when assigning PI space as well. The consequences of using PA or PI space must always be made clear to the end user. Assignment of this (PA) address space is valid as long as the criteria for the original assignment are still met and only for the duration of the service agreement between yourself and ISP XXXX. Every new address space assignment must be marked as PA or PI in the RIPE database. Any assigned address space without an explicit type in the status attribute is assumed to be PI space. Formally, address space is not of type PA unless there are contractual agreements regarding the assignment's termination. It is therefore recommended that IRs ask end users to release non-PA address space upon termination of service. 3.5. Assignment Window (page 24) The assignment window is the maximum number of addresses that can be assigned by the local IR to an end user without prior approval by the RIPE NCC. Currently, the maximum size of the assignment window for any local IR is 4096 addresses (/20). If such errors are noticed by the RIPE NCC, the assignment window for the local IR may be decreased to prevent the staff from making erroneous assignments involving a substantial amount of address space. 4. Rules and Guidelines for Allocations (page 26) If a local IR allows another IP service provider to make an assignment from its allocated address space, the local IR is still responsible to guarantee the assignment is made according to the guidelines specified in this document. 4.1. Slow Start of Allocations (page 26) The minimum allocation is /19 (8192 addresses). The maximum size of an individual allocation is /16 (65536 addresses). The size of allocations is based solely on the rate that previously allocated address space has been assigned to end users. 4.2. First Allocation (page 27) The first allocation will be made automatically by the RIPE NCC, generally upon receipt of the first assignment request from the local IR. Because there is no information about the rate at which a new IR will make address assignments, the size of the first allocation is always set at the minimum. 4.3. Further Allocations (page 27) Additional address space will be allocated after the information delivered with the request has been verified, and a new allocation has been deemed necessary. While the RIPE NCC always aims to further the aggregation goal, and therefore to allocate contiguous space, the RIPE policy is that under no circumstances are multiple allocations made to the same local IR guaranteed to be contiguous. 4.4. Allocation Registration (page 28) ALLOCATED UNSPECIFIED This address space has been allocated to an IR, and assignments made from it may be either provider aggregatable or provider independent. This type of allocation is obsolete, and will not be applied to future allocations. Some older allocations have been used for both PA and PI assignments, and as such receive this allocation type.

1 0

Policy Statement on Address Space Allocations
by Daniel Karrenberg 25 Jan '96

25 Jan '96

> Tony Li <tli(a)cisco.com> writes: > > To be more specific, the RIPE NCC has been using a policy such that it will > (at most) grant a prefix one bit shorter than the prefix that has been > used. Under this policy, it would be reasonable to ask for a /17, tho I'm > not saying that you necessarily can prove the growth to support 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. Our basic allocation policy is: 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. In particular it will not be influenced by marketing predictions, amount of capital available or the shoe size of the lawyers visiting our offices. (NB: The value of /19 might change at some point, but the fact that every newly established registry gets *the same size* initial allocation will not.) The reason for this policy is to avoid very lengthy, fruitless and frustrating discussions about the size of initial allocations which end up in expensive (in time and nerves) but basically arbitrary decisions. 2) After the initial /19 further allocations will depend *solely* on the usage rate of the particular registry. These allocations can currently be *anywhere* from /19 to /16 depending on the usage rate. Supernational registries may under certain conditions have more than one /16 allocation. The established usage rate is an objective criterion to determine the sizeof further allocations and our experience shows that we have very few discussions about allocation sizes. Now, as Forrest points out, this makes it desirable for each ISP to have a high usage rate. So local registries may be tempted to use more than needed. This is where the assignment policies come in to make sure that the conservation goal is respected. After all the usage rate is determined by *valid* assignments only. Our assignment policies and procedures provide strong incentives for registries to act prudently and and correctly. 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. 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. 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! It should be noted that additional allocations are very often aggregatable with previous ones. So the number of /19 prefixes announced will decrease over time. I personally expect that we can reach *very* acceptable aggregation levels and current statistics support that: Routing Table router: amsterdam.ripe.net time: Mon Jan 22 11:06:13 1996 Destinations: 32934 Routes: 32934 /8 block hosts routes hosts addres- / sed route 192.0.0.0 4981504 6551 760 193.0.0.0 9264640 2019 4588 194.0.0.0 7665920 1849 4145 195.0.0.0 256 1 256 196.0.0.0 731648 329 2223 197.0.0.0 256 1 256 198.0.0.0 7488000 3705 2021 199.0.0.0 8838144 3338 2647 200.0.0.0 4660736 697 6686 201.0.0.0 256 1 256 202.0.0.0 4258496 1460 2916 203.0.0.0 5831424 780 7476 204.0.0.0 10499072 3660 2868 205.0.0.0 6019584 1793 3357 206.0.0.0 10967808 1649 6651 207.0.0.0 1019136 37 27544 C Space 82226880 27870 2950 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. Daniel Karrenberg RIPE NCC Manager

2 1

Policy Statement on Address Space Allocations
by Daniel Karrenberg 25 Jan '96

25 Jan '96

------- Forwarded Message Date: Wed, 24 Jan 1996 15:46:05 -0800 From: postel(a)ISI.EDU To: nanog(a)merit.edu, cidrd(a)IEPG.ORG, iepg(a)IEPG.ORG, iab(a)ISI.EDU, iesg@ISI .EDU cc: iana(a)ISI.EDU, netreg(a)internic.net, ncc(a)ripe.net, hostmaster(a)apnic.net Subject: Policy Statement on Address Space Allocations Policy Statement on Address Space Allocations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Regional Internet Registries (APNIC, InterNIC, RIPE NCC) refer organizations requesting IP address space to their Internet service providers (ISPs). This is done for various reasons, the main reason being that IP addresses need to be assigned hierarchically to allow aggregation of routing information (CIDR). Customers are warned of possible routing restrictions if addresses are not received from an ISP's CIDR block. Since some ISPs are presently restricting the length of prefixes they route, it is even more important for end users to receive IP addresses from their Internet service provider. Regional Internet registries have no control over the routing policies of any ISP. The IANA has instructed the Internet registries not to assign IP addresses based on any ISP's particular routing policy, rather on specific criteria including utilization efficiency. An organization will be assigned the number of IP addresses it can justify. If this number is not fully routable, that is an issue that should be taken up with the ISP(s) concerned. Regional Internet Registries inform ISPs about allocation and assignment policies. This enables ISPs to take these policies into account when setting their routing policies. s/ IANA, Internic, RIPE-NCC, AP-NIC. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------- End of Forwarded Message

1 0

Re: ripe-104++
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

>- One address for a router >- One address for a Web-Server >- One address for a firewall >- up to 5 additional addresses for "other purposes". >In such cases, they will be allocated 8 or 16 addresses, > ( netmask 240 or 248 ). Neither is this situation, nor in the case depicted later, I do see a case for a full-blown assignment transaction. I would assume that the ISP connecting that web server has the addressesd assigned and manages the adress(es) needed to configure the technical stuff. And assuming that you've got more than one server to support, *you* might want to do an addressing plan and some assessment of your network development.... And if you decide to formally tell your customer about the individual address from your assignment to be used, then this can be seen as local matters. There's a difference, of course, if your're talking about a VSE with a LAN (IP based) that gets connected and might decide to become dual-homed... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

ripe-104++ too big!
by Carol Orange 24 Jan '96

24 Jan '96

Hi again, Unfortunately, not everyone received the document I sent out Monday because it's too big for some mailers. Sorry about that. If you fall in this category, you can pick up the document in: ftp://ftp.ripe.net/ripe/drafts/ripe-104++.ps or ftp://ftp.ripe.net/ripe/drafts/ripe-104++.txt Happy reading, -- Carol PS: Here is the letter which introduced the document: ------------------------------------------------------------------ Dear Local IR Working Group, The document included below is the first part of a document intended to replace ripe-104 and ripe-105. While we have made progress on the latter half, it is not ready for review. You can see what will be covered there if you read Section 1. This will be the background for the discussion mentioned by Mike Norris for the Local IR working group meeting next week. A number of people, most notably Mike Norris, Wilfried Woeber and Janos Zsako, have made useful comments and contributions to the draft below. Any remaining problems are, however, the responsibility of the authors. While our aim was to write down current practices, we understand that it may raise questions about policy. That's why we want to get it out to you before the RIPE meeting next week. Any errors you note can be sent directly to me (orange(a)ripe.net). I look forward to meeting you all next week. -- Carol

1 0

Re: ripe-104++
by saliba＠inco.com.lb 24 Jan '96

24 Jan '96

I agree with alain, I am also an ISP and I have many customers that require one IP address for their web server, so how to manage these requests. For the moment I think that I have to assign my first customer who is waiting for his web address since the beginning of January, a full IP Network number!! Do you have any other idea on how to do it? Regards, Therese > From ripe.net!owner-local-ir Tue Jan 23 22:58:39 1996 > Date: Tue, 23 Jan 1996 21:27:25 -0600 (CST) > From: Alain Golan <alain(a)NetVision.net.il> > To: Carol Orange <orange(a)ripe.net> > Cc: local-ir(a)ripe.net > Subject: Re: ripe-104++ > Mime-Version: 1.0 > > > There is an increasing number of entities requiring > very small address space, I.E. > > - One address for a router > - One address for a Web-Server > - One address for a firewall > - up to 5 additional addresses for "other purposes". > > In such cases, they will be allocated 8 or 16 addresses, > ( netmask 240 or 248 ). > > Requesting written "Additional information" or justification , > from the customer for a first allocation of 16 PA address space, > make us (LIR) a bit ridiculous, and is overloading. > > A telephone conversation like: > > LIR - Helo Mr Joe, > > Joe - Helo NetProvider > > LIR - I understand that you are connecting to our services, > and would like to setup addresses for You, what do you plan > to connect to the Internet ? > > Joe - Oh, I'll be running a web site for our skate-boards factory. > > LIR - And, are you going to connect other computers to the net ? > > Joe - not now, maybe next year I'll setup a mail gateway to > our novell mail system. > > LIR - Anything else in mind for the next two years ? > > Joe - no, the administration don't want our internal network > connected to the internet for security reasons. > > LIR - Do you understand that I will allocate you 6 addresses, > and that if you change your mind, and need more, you will > have to change the addresses of those 6 hosts ? > > Joe - Yes, but actualy it's only the web ... it's okay ! > > LIR - Is your company connected or connecting the Internet > somewhere else ? > > Joe - no, we don't have offices anywhere else. > > LIR - Thanks. > > --------------------------- > > Such a convertation is more realistic and saving more address > space than sending the requested-info form. > > -If Joe had filled the form, he would have probably asked for > more than 8 addresses. > > -For Joe to fill the form, LIR should have: > > - Faxed explanation documents in addition to the person > template. > - spent a lot of time explaining what are the fields. > > > It seems reasonable to me that if a request meet the following: > 1) FIRST - First address allocation for this entity > 2) PA - Provider Agregate > 3) Less or equal to 8 (or 16 ?) ip addresses limit. > 4) Connecting to the internet immediatly. > > The address space will be allocated without getting & > filling a deployment plan and justification. > > Does it make sense ? can it be accepted formally ? > > (I understand that it is not the current policy). > > > \Alain. > > > >

1 0