From hostmaster at ripe.net Thu Jan 4 10:08:23 1996 From: hostmaster at ripe.net (RIPE NCC Hostmaster) Date: Thu, 04 Jan 1996 10:08:23 +0100 Subject: New Status of Last Resort Registries Message-ID: <9601040908.AA14253@ncc.ripe.net> Dear Colleagues, Seasons Greeting and the best wishes for the New Year from all of the RIPE NCC. As announced earlier the status of the Last Resort Registries will change from 1996 on. We appologise for not sending this message earlier. We kindly ask you to respond as soon as possible. Our target to have these matter resolved is the beginning of February, right after the next RIPE Meeting. The NCC Contributors Comittee decided during the last meeting in September that all Local IRs need to contribute to the RIPE NCC to receive registration service. This has implications for the Local IRs that currently run a Registry of Last Resort. There are two possiblities for these LIR's: 1. Contribution to the RIPE NCC 2. Closure of the Last Resort Registry In order to facilitate aggregation of routing information and therefor a stable Internet routing the closure of the Last Resort Registries is the preferred solution. If the first possibility is chosen, the size of the registry needs to be determined and an "Agreement on the provision and use of the RIPE NCC services" needs to be signed and send to the RIPE NCC. For more details please refer to ftp://ftp.ripe.net/ripe/new-registry or contact . If the Last Resort Registry will be closed, please read and edit the following form letter and send it back to The closure of a LIR can only be effective after the issues below are resolved. If you plan to continue the Last Resort Registration Service, please notify us before January 15th. Otherwise your registry will receive no service. In case you run two registries a Last Resort Registry and a Provider Registry, please note, that the operation of the Provider Registry is not effected by this matter. Kind regards, Mirjam Kuehne RIPE NCC ---------------------------------------------------------------------- Dear colleagues, We formally request to close the local Internet Registry operated by XXXXX-Organisation under registry ID xxx.zz effective at . We enclose a final summary of all address space assigned by and through our registry as enclosure A. We also enclose a list of all address space allocated (delegated) to our registry but not yet assigned as enclosure B. We understand that we are not allowed to make any further assignments from this address space after the closure and that this address space can be re-allocated and re-assigned by the RIPE NCC as necessary. We will guarantee that the RIPE NCC can at any time access all records concerning customers's requests for address space as per the "IP Address Space Assignment Procedures" (ripe-104): "IRs will keep records of correspondence and information exchanges in conjunction with the registry function for later review and the resolution of disputes. IRs will hold this information in strict confidence and use it only to review requests and in audit procedures or to resolve disputes." If access can not or will no longer be guaranteed, we will transfer the records to the RIPE NCC after prior agreement on the procedure. The RIPE NCC will hold this information in strict confidence and use it only to review requests, audit procedures or to resolve disputes. Currently ongoing requests for IP address space will either be finished before closing the registry or the requester will be referred to the list of local Internet registries that can be found at ftp://ftp.ripe.net/ripe/registries/ after he/she has been informed about the issues related with PA/PI address space outlined in ripe-127. We understand that the closure of our registry has the following consequences: - The registy entry xxx.zz will be removed from the directory of Local Internet Registries (ftp://ftp.ripe.net/ripe/registries/). - The e-mail addresses registered for registry xxx.zz will be removed from the mailing lists ip-provs at ripe.net, ncc-co at ripe.net and local-ir at ripe.net automatically. Note that it is possible to re-subscribe to local-ir at ripe.net on an individual basis. - All registry requests from XXX-Organisation directly to the RIPE NCC will henceforth be treated as requests from an individual and will not receive registration service unless they are channeled through another local IR. We understand and agree to the above. For the xxx.zz registry operated by XXX-Organisation Enclosure A: EXAMPLE EXAMPLE EXAMPLE ------- Allocation record ----------- 193.0.0.0 - 193.0.255.255 ----------------------------------------------------------------- 193.0.0.0 - 193.0.1.255 1-Dec-94 Internal Infrastructure 193.0.2.0 - 193.0.2.127 1-Dec-94 ABC Organisation 193.0.2.128 - 193.0.2.255 1-Dec-94 ABC Organisation Int. 193.0.3.0 - 193.0.3.255 2-Dec-94 XYC-Organisation 193.0.4.0 - 193.0.7.255 11-Dec-94 AB Network Inc. 193.0.8.0 - 193.0.15.255 11-Dec-94 XY Net-Institute ... Enclosure B: EXAMPLE EXAMPLE EXAMPLE Non-assigned IP addresses: ----------------------------------------------------------------- 193.0.104.0 - 193.0.127.255 193.0.160.0 - 193.0.168.255 193.0.213.0 - 193.0.213.255 193.0.216.0 - 193.0.216.255 193.0.221.0 - 193.0.221.255 193.0.244.0 - 193.0.244.255 193.0.245.0 - 193.0.245.255 From saliba at inco.com.lb Mon Jan 8 17:50:00 1996 From: saliba at inco.com.lb (Therese Saliba) Date: Mon, 8 Jan 96 16:50 GMT Subject: domain name registration Message-ID: As an ISP, Is it possible to register a new domain (for a customer) having one IP address, knowing that that IP address belong to another domain? Regards From mnorris at dalkey.hea.ie Fri Jan 12 16:43:38 1996 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Fri, 12 Jan 96 15:43:38 +0000 Subject: RIPE23: outstanding action items Message-ID: <9601121543.AA04910@dalkey.hea.ie> For info. Mike ------- Forwarded Message Return-Path: markk at internic.net Received: (markk at localhost) by slam.internic.net (8.7.3/SLAM-1) id KAA01025; Fri, 12 Jan 1996 10:37:03 -0500 (EST) From: Mark Kosters Message-Id: <199601121537.KAA01025 at slam.internic.net> Subject: Re: RIPE23: outstanding action items To: mnorris at dalkey.hea.ie (Mike Norris) Date: Fri, 12 Jan 1996 10:37:03 -0500 (EST) Cc: Roderik.Muit at ripe.net, ripe-list at ripe.net In-Reply-To: <9512220836.AA03744 at dalkey.hea.ie> from "Mike Norris" at Dec 22, 95 08:36:15 am X-Mailer: ELM [version 2.4 PL24alpha4] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit rfc1466++ is now in draft - the rfc is to be out shortly. (ftp://ds.internic.net/internet-drafts/draft-hubbard-registry-guidelines-00.txt) Regards, Mark > > > > Action 22.1 on Mike Norris and RIPE NCC > > To find volunteers from the Local IR working > > group to continue working on the revision of > > ripe-104++ without waiting for the publication > > of rfc1466++. > > Volunteers have been found, Daniel has drafted in some expertise > and an editorial group has been formed. The group met at the NCC > last week and continues its work of revising ripe-104 with a view > to circulating a document before RIPE 23. > > Cheers. > > Mike > > - -- Mark Kosters markk at internic.net +1 703 742 4795 Software Engineer InterNIC Registration Services ------- End of Forwarded Message From Daniel.Karrenberg at ripe.net Mon Jan 15 10:23:48 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 15 Jan 1996 10:23:48 +0100 Subject: FYI: RIPE DB and Domain Names Message-ID: <9601150923.AA20822@ncc.ripe.net> ------- Forwarded Message Date: Mon, 15 Jan 1996 10:23:15 +0100 From: Daniel Karrenberg Sender: dfk at ripe.net To: Domain registration staff cc: ripe-op at ripe.net Subject: Unauthorized modifications of RIPEDB > Domain registration staff writes: > Dear NCC, > > > Last week the following new 219 domains appeared in RIPEDB. > I can't believe that all of European TLD administrators > registered this domains at the same time. Moreover with and without CO. There are two basic problems here: 1) Confusion about the role of the RIPE database in *domain names*. The database is not authoritative about domain names. It is just informational for these. The authoritative registry of domain names for TLDs is kept by TLD administrators. They are encouraged use the ripe database to make their registry accessible. This is *not* mandatory. 2) Lack of authorisation in the RIPE database for the *creation* of objects. As David Kessens has pointed out already we are working on this. Once this is implemented TLD administrators can control the creation of objects within their namespace. This is the top priority database development item at the moment. We are also working on a simple referral method so that TLD administrators can run their own whois services, as the NL TLD administrator does. Until these problems are solved the RIPE database can be nothing more than informational about TLDs. Oncve they are solved TLD administrators have the means to keep their data clean if they wish. Daniel ------- End of Forwarded Message From ncc at ripe.net Mon Jan 15 11:04:04 1996 From: ncc at ripe.net (RIPE NCC Staff) Date: Mon, 15 Jan 1996 11:04:04 +0100 Subject: RIPE23: reminder Message-ID: <9601151004.AA21922@ncc.ripe.net> Dear people, This is a reminder that there will be a RIPE meeting soon. If you have missed the previous announcement and want to attend: please do not forget to register. You can find all relevant information at: ftp://ftp.ripe.net/ripe/Next-Meeting/ All further (and previous) discussion on the meeting will be held on the 'ripe-list' mailinglist. To subscribe, please send mail to with 'subscribe ripe-list' in the message body. The mailing list archives can be found at ftp://ftp.ripe.net/ripe/archives/ripe-list/ Appended below is the original announcement for the meeting, but without all the other documents that were appended. ------ R I P E meeting announcement ============================ (This announcement can also be viewed using "finger meeting at ncc.ripe.net") This is to announce that the 23rd RIPE meeting will take place: Dates: 29th January, 1996 start: 10:00 (*) 30th January, 1996 31st January, 1996 end: 15:30 (*) * times subject to change (may vary +/- 1 hour). For exact times, look at ftp://ftp.ripe.net/ripe/Next-Meeting/announcement shortly before the meeting Venue: CWI Kruislaan 413 1098 SJ Amsterdam The Netherlands Host: NIKHEF Registration: Please use the registration form (which will follow in a separate mail) to give notice of your coming as soon as possible. General meeting overview: ------------------------- - Before the working group meetings, on Monday 29th, there will be an EOF (European Operators Forum) meeting. The exact starting time will probably be known shortly before the RIPE meeting. It will end 12:30. - Monday 29th, 14:00-18:00 and Tuesday 30th, 09:00-12:30, there will be various RIPE working groups sessions. The schedule of the previous meeting follows below for reference; the schedule of this meeting is not known yet. - Tuesday 30th, 14:00-18:00 and Wednesday 31st, 09:00-15:30 (*), the plenary session will take place, with reports from the RIPE NCC, reports from the working group meetings and other presentations. General information: -------------------- Currency (checked 18 December 1995): 1 UK pound = Hfl 2.5 1 ECU = Hfl 2.1 1 US$ = Hfl 1.6 More information about Amsterdam: --------------------------------- Websurfers may take a look at: <> http://www.xxlink.nl/cities/amsterdam <> http://www.channels.nl/ Appended to this announcement: ------------------------------ <> directions to the meeting place Documents to follow (separate mail messages): --------------------------------------------- <> details of hotels in Amsterdam close to meeting venue <> registration form for attendance at the meeting <> getting visa for the meeting, if you need one ================================================================== From Daniel.Karrenberg at ripe.net Mon Jan 15 17:25:58 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 15 Jan 1996 17:25:58 +0100 Subject: Developments at the RIPE NCC Message-ID: <9601151626.AA01999@ncc.ripe.net> Dear customers and colleagues, once again it is time for one of my (ir)regular messages about the latest developments at the RIPE NCC. I hope it is one of the last ones serving as an informal report as we plan to start the formal quarterly reports again soon. See below for more details. European Internet ----------------- During 1995 the European Internet has roughly doubled in terms of DNS registered hosts as you can see from the excerpt of the RIPE NCC hostcount below. The number of hosts at the end of December 1995 is 2.14 times larger than the number at the end of December 1994. These are exciting times! For details see ftp://ftp.ripe.net/ripe/hostcount/. Count Delta Delta % Q Delta Q Delta % ------------------------------------------------------------------- Dec 1994 1029270 + 56170 + 5.8% +140872 +15.9% Jan 1995 1106077 + 76780 + 7.5% Feb 1995 1197911 + 91807 + 8.3% Mar 1995 1326078 +128116 + 10.7% +296703 +28.8% Apr 1995 1375921 + 49805 + 3.7% May 1995 1463816 + 87896 + 6.4% Jun 1995 1550520 + 87287 + 5.9% +224988 +16.9% Jul 1995 1694978 +144472 + 9.3% Aug 1995 1773680 + 79205 + 4.7% Sep 1995 1830389 + 56709 + 3.2% +280386 +18.1% Oct 1995 1928380 + 97991 + 5.4% Nov 1995 1999997 + 71617 + 3.7% Dec 1995 2206360 +199419 + 10.0% +369027 +20.2% Local Registries ---------------- The number of local registries has also roughly doubled in 1995; there are 2.18 times more registries than last year: Q4 Q1 Q2 Q3 Q4 Projected 1994 1995 1995 1995 1995 1995 Large ISP 17 17 19 25 28 22 Medium ISP 28 31 35 36 40 42 Small ISP 51 84 119 159 196 188 Enterprise 14 15 17 15 16 20 Last Resort 31 32 32 30 28 32 TOTAL 141 179 222 265 308 304 It is remarkable that the growth of the number of registries so closely follows the growth of the net as measured by the hostcount. From these measures one cannot deduce concentration tendencies in Internet service provision. We are also quite satisfied that the actual numbers are quite close to the predictions we made in Q2 of the year. This gives us some confidence in our planning. For the NCC staff, as for anyone else in the Internet business, this growth has meant a tremendous amount of work, not least in training and integrating new colleagues and working with all those new customers. Luckily the financial position of the NCC has also become much more stable than at this time last year; this provides sufficient material resources to cope with the growth. While final figures for 1995 are not available yet, we expect to close the year with financial reserves which provide a good basis for NCC operations in the foreseeable future. In December last year we have issued invoices for 1996 fees to all established registries. We have been pleasantly surprised by the considerable amounts we have already received. Thank you to those of you paying in time. Will the others please follow that example. ;-) Registration Services --------------------- The junior hostmasters who started in the second half of 1995 are now fully up-to-speed in handling requests. Ticketing and the first manual implementation of work flow management are paying off. In the beginning of December we succeeded to eliminate the permanent queue of requests not yet assigned to a hostmaster which had been in operation since early in the year. Customers started to make pleasant remarks about the turn-around time of requests again. This was a major milestone for registration services. We are using this breathing space to further train the registration services staff, to convert some manually kept internal databases to machine processable format and to introduce the automated work flow management system. The latter changes should be fully transparent to the customers while the former should enable each hostmaster to take more personal responsibilities for allocation and assignment decisions. Because the number of people and resources used by registration services are substantial we have decided to make a start at changing the flat organisational structure of the NCC in this area. From January 1st this year Mirjam Kuehne has been appointed "Manager Registration Services". Mirjam is responsible for day to day operations in this area with all registration services staff reporting to her. Other Activities ---------------- A beta release of the database software has been produced. It includes code for running secondary (shadow) databases in almost real time as well as other improvements. Several local IR training courses have been presented and were received well. The RIPE NCC information servers are getting a total overhaul in a project executed by the school for communications systems of Utrecht university. Very little of that is visible at this point but much work is being done behind the scenes. If you would like to influence the work, consider completing the survey at http://www.ripe.net/ripe/usurv.html. In conjunction with this project address space assignment and allocation procedures are being re-written at this point in order to provide up to date documentation to local registries in a single document. An editing committee recruited from the local-IR working group is helping with this task. A draft is expected to appear shortly and will be discussed at the RIPE meeting. Behind the Scenes ----------------- The RIPE NCC computing infrastructure has seen a lot of necessary replacements as the original hardware is nearing the end of its useful life. We are in the process of re-implementing large parts of the workstation and server environments in order to keep up with changes at the NCC and in the Internet. The computer room servers have been moved to four large 19 inch racks which provides more room and improves reliability. New server hardware based on industrial PCs has been purchased and partially deployed. RAID systems are being tested. New Staff --------- After a long search the NCC finally has a business manager! The search has been longer and more difficult as expected even considering the current circumstances in the Internet world. Not so surprisingly two very promising candidates who had been offered the position decided to join Internet service providers at the last minute, one of them even at the last second. But all is well than ends well! Dr. Carol Orange has been appointed RIPE NCC business manager as of today and will be responsible for financial planning and control, general customer relations and the quarterly reports. Carol joins us from Utrecht university where she has led the abovementioned project to redesign the NCC's information servers. She will work part-time until the end of March when she will have completed long term commitments at Utrecht university. Carol who is originally from Portland Oregon has been living in Amsterdam since 1986. The list of her former employers includes Lucasfilm and CWI. She has been getting her fingers dirty with technical work in those positions and hopes to find an excuse to do that from time to time in the future. She has been teaching juggling to people working at the NCC campus since 1987. Also today Naomi de Bruyn joins the NCC as a full time secretary. Naomi will be our "receptionist" answering the phone and dealing with general messages to . She will also be responsible for a number of internal administrative tasks and help with the organisation of meetings and courses. Naomi has previously worked for the TERENA secretariat on a temporary basis. Next Period ----------- During the first quarter of this year we plan to further consolidate registration services and finally begin starting other activities which have been dormant. We will also put effort into the development of alternative charging models and start to investigate areas where technical work by the NCC is needed. Finally we plan to present a real quarterly report for the first quarter sometime in April. All of us here at the RIPE NCC wish you a good and successful year. If you have any further questions, please do not hesitate to contact us. Regards Daniel Karrenberg RIPE NCC Manager From miguel.sanz at rediris.es Tue Jan 16 19:22:33 1996 From: miguel.sanz at rediris.es (Miguel A. Sanz. RedIRIS/CSIC) Date: Tue, 16 Jan 1996 19:22:33 +0100 Subject: New Status of Last Resort Registries In-Reply-To: RIPE NCC Hostmaster "New Status of Last Resort Registries" (Jan 4, 10:08) References: <9601040908.AA14253@ncc.ripe.net> Message-ID: <9601161922.ZM13693@rediris.es> On Jan 4, 10:08, RIPE NCC Hostmaster wrote: > Subject: New Status of Last Resort Registries > Dear hostmaster, I don't see any reference in the letter to in-addr.arpa delegation being passed from Last Resort Registries to RIPE NCC. It should be included and also the procedure for this transfer (for instance, copy of the primary servers files). Regards, Miguel A. Sanz +---------------------------------------------------------------+ | ES-NIC (Delegated Internet Registry for Spain) | | Centro de Comunicaciones CSIC RedIRIS | | Serrano 142 Tel: + 34 1 5855150 | | 28006 Madrid Fax: + 34 1 5855146 | | SPAIN Email: nic at rediris.es | +---------------------------------------------------------------+ > Dear Colleagues, > > Seasons Greeting and the best wishes for the New Year from all of the > RIPE NCC. > > As announced earlier the status of the Last Resort Registries will > change from 1996 on. > > We appologise for not sending this message earlier. We kindly ask you > to respond as soon as possible. Our target to have these matter > resolved is the beginning of February, right after the next RIPE > Meeting. > > The NCC Contributors Comittee decided during the last meeting in > September that all Local IRs need to contribute to the RIPE NCC to > receive registration service. > > This has implications for the Local IRs that currently run a Registry > of Last Resort. There are two possiblities for these LIR's: > > 1. Contribution to the RIPE NCC > 2. Closure of the Last Resort Registry > > In order to facilitate aggregation of routing information and therefor > a stable Internet routing the closure of the Last Resort Registries is > the preferred solution. > > If the first possibility is chosen, the size of the registry needs to > be determined and an "Agreement on the provision and use of the RIPE > NCC services" needs to be signed and send to the RIPE NCC. For more > details please refer to > > ftp://ftp.ripe.net/ripe/new-registry > > or contact . > > If the Last Resort Registry will be closed, please read and edit the > following form letter and send it back to > > The closure of a LIR can only be effective after the issues below are > resolved. > > If you plan to continue the Last Resort Registration Service, please > notify us before January 15th. Otherwise your registry will receive no > service. > > In case you run two registries a Last Resort Registry and a Provider > Registry, please note, that the operation of the Provider Registry is > not effected by this matter. > > Kind regards, > > Mirjam Kuehne > RIPE NCC > > > ---------------------------------------------------------------------- > > Dear colleagues, > > We formally request to close the local Internet Registry operated by > XXXXX-Organisation under registry ID xxx.zz effective at . > > We enclose a final summary of all address space assigned by and > through our registry as enclosure A. > > We also enclose a list of all address space allocated (delegated) to > our registry but not yet assigned as enclosure B. We understand that > we are not allowed to make any further assignments from this address > space after the closure and that this address space can be > re-allocated and re-assigned by the RIPE NCC as necessary. > > We will guarantee that the RIPE NCC can at any time access all records > concerning customers's requests for address space as per the "IP > Address Space Assignment Procedures" (ripe-104): "IRs will keep > records of correspondence and information exchanges in conjunction > with the registry function for later review and the resolution of > disputes. IRs will hold this information in strict confidence and use > it only to review requests and in audit procedures or to resolve > disputes." > > If access can not or will no longer be guaranteed, we will transfer > the records to the RIPE NCC after prior agreement on the procedure. > > The RIPE NCC will hold this information in strict confidence and use > it only to review requests, audit procedures or to resolve disputes. > > Currently ongoing requests for IP address space will either be > finished before closing the registry or the requester will be referred > to the list of local Internet registries that can be found at > > ftp://ftp.ripe.net/ripe/registries/ > > after he/she has been informed about the issues related with PA/PI > address space outlined in ripe-127. > > We understand that the closure of our registry has the following > consequences: > > - The registy entry xxx.zz will be removed from the directory > of Local Internet Registries (ftp://ftp.ripe.net/ripe/registries/). > > - The e-mail addresses registered for registry xxx.zz will be removed > from the mailing lists ip-provs at ripe.net, ncc-co at ripe.net and > local-ir at ripe.net automatically. Note that it is possible to > re-subscribe to local-ir at ripe.net on an individual basis. > > - All registry requests from XXX-Organisation directly to the RIPE NCC > will henceforth be treated as requests from an individual and will > not receive registration service unless they are channeled through > another local IR. > > We understand and agree to the above. > > For the xxx.zz registry operated by XXX-Organisation > > > > > > Enclosure A: > > EXAMPLE EXAMPLE EXAMPLE > > ------- Allocation record ----------- > > 193.0.0.0 - 193.0.255.255 > ----------------------------------------------------------------- > > > 193.0.0.0 - 193.0.1.255 1-Dec-94 Internal Infrastructure > 193.0.2.0 - 193.0.2.127 1-Dec-94 ABC Organisation > 193.0.2.128 - 193.0.2.255 1-Dec-94 ABC Organisation Int. > 193.0.3.0 - 193.0.3.255 2-Dec-94 XYC-Organisation > 193.0.4.0 - 193.0.7.255 11-Dec-94 AB Network Inc. > 193.0.8.0 - 193.0.15.255 11-Dec-94 XY Net-Institute > ... > > > > Enclosure B: > > EXAMPLE EXAMPLE EXAMPLE > > Non-assigned IP addresses: > ----------------------------------------------------------------- > > 193.0.104.0 - 193.0.127.255 > 193.0.160.0 - 193.0.168.255 > > 193.0.213.0 - 193.0.213.255 > 193.0.216.0 - 193.0.216.255 > 193.0.221.0 - 193.0.221.255 > 193.0.244.0 - 193.0.244.255 > 193.0.245.0 - 193.0.245.255 > > >-- End of excerpt from RIPE NCC Hostmaster From hm-acks at ripe.net Wed Jan 17 10:16:27 1996 From: hm-acks at ripe.net (RIPE NCC Acknowledgements) Date: Wed, 17 Jan 1996 10:16:27 +0100 Subject: NCC#963329 Re: New Status of Last Resort Registries In-Reply-To: Your message of Tue, 16 Jan 1996 19:22:33 +0100 Message-ID: <9601170916.AA01121@ncc.ripe.net> Dear "Miguel A. Sanz. RedIRIS/CSIC", ------------------------------------------------------------------- Your message From: miguel.sanz at rediris.es (Miguel A. Sanz. RedIRIS/CSIC) Date: Tue, 16 Jan 1996 19:22:33 +0100 Message-ID: <9601161922.ZM13693 at rediris.es> Subject: Re: New Status of Last Resort Registries has been received at the RIPE NCC. We have extracted the following information from it: NCC Ticket Number: Your Registry ID: ------------------------------------------------------------------- This message concerns a n e w request which we will process under ticket number NCC#963329. Your message did not specify a registry ID for this request. We have determined manually that the correct registry ID is es.zz. This has lead to some delay and some unnecessary work. Please include your registry ID in your requests by adding a X-NCC-RegID: line in the header or near the beginning of the body of your message. Putting the registry ID in the subject line is not sufficient because our automated procedures will not be able to determine them reliably. The request will be processed for registry es.zz. The service level for registry es.zz is 'normal'. The process will be processed normally. Please make sure that you specify the ticket number in all correspondence regarding this particular request and this particular request only. See ripe-183 for details about ticketising and request tracking. With kind regards The RIPE NCC Hostmaster Team ------------------------------------------------------------------- The body text of your message started as follows: On Jan 4, 10:08, RIPE NCC Hostmaster wrote: > Subject: New Status of Last Resort Registries > Dear hostmaster, I don't see any reference in the letter to in-addr.arpa delegation being passed from Last Resort Registries to RIPE NCC. It should be included and also the procedure for this transfer (for instance, copy of the primary servers files). Regards, Miguel A. Sanz +---------------------------------------------------------------+ | ES-NIC (Delegated Internet Registry for Spain) | | Centro de Comunicaciones CSIC RedIRIS | | Serrano 142 Tel: + 34 1 5855150 | | 28006 Madrid Fax: + 34 1 5855146 | | SPAIN Email: nic at rediris.es | +---------------------------------------------------------------+ > Dear Colleagues, > > Seasons Greeting and the best wishes for the New Year from all of the > RIPE NCC. > > As announced earlier the status of the Last Resort Registries will > change from 1996 on. > > We appologise for not sending this message earlier. We kindly ask you > to respond as soon as possible. Our target to have these matter > resolved is the beginning of February, right after the next RIPE > Meeting. > > The NCC Contributors Comittee decided during the last meeting in > September that all Local IRs need to contribute to the RIPE NCC to > receive registration service. > > This has implications for the Local IRs that currently run a Registry > of Last Resort. There are two possiblities for these LIR's: > > 1. Contribution to the RIPE NCC > 2. Closure of the Last Resort Registry > > In order to facilitate aggregation of routing information and therefor > a stable Internet routing the closure of the Last Resort Registries is > the preferred solution. > > If the first possibility is chosen, the size of the registry needs to > be determined and an "Agreement on the provision and use of the RIPE > NCC services" needs to be signed and s From hostmaster at ripe.net Wed Jan 17 11:53:50 1996 From: hostmaster at ripe.net (RIPE NCC Hostmaster) Date: Wed, 17 Jan 1996 11:53:50 +0100 Subject: NCC#963329 Re: New Status of Last Resort Registries In-Reply-To: Your message of Tue, 16 Jan 1996 19:22:33 MET. <9601161922.ZM13693@rediris.es> References: <9601161922.ZM13693@rediris.es> Message-ID: <9601171053.AA03691@ncc.ripe.net> miguel.sanz at rediris.es (Miguel A. Sanz. RedIRIS/ CSIC) writes: * On Jan 4, 10:08, RIPE NCC Hostmaster wrote: * > Subject: New Status of Last Resort Registrie * s * * Dear hostmaster, * * I don't see any reference in the letter to in- * addr.arpa delegation being * passed from Last Resort Registries to RIPE NCC * . It should be included * and also the procedure for this transfer (for * instance, copy of the * primary servers files). * If a registry closes the RIPE NCC will accept responsibility for reverse delegations. This can indeed best be accomplished by sending us a copy of the files. Thankyou for reminding us of this, Kind regards, John Crain RIPE NCC From mnorris at dalkey.hea.ie Wed Jan 17 16:54:41 1996 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Wed, 17 Jan 1996 15:54:41 GMT Subject: Local IR WG - draft agenda Message-ID: <9601171554.AA10240@dalkey.hea.ie> Please see the following draft agenda for the Local IR Working Group at RIPE 23. Additions, comments etc are all welcome. Perhaps the main item for the WG is consideration of the draft of ripe-104++, "European Internet Registry: Internet Address Space Assignment Procedures". The text will be made available next Monday and will contain a number of important new policies and policy changes. I will try to summarise these to the list so that the discussion under item 4 on the agenda can have some structure. Anyway, watch this space for a major RIPE production coming out real soon now, and be prepared to engage in a constructive exercise of consensus-building around a document which will be of great benefit to the entire IP community in Europe. Cheers. Mike Norris RIPE 23 - 29-31 January 1996 Local IR Working Group D R A F T A G E N D A 1. Preliminaries - scribe needed, please - agree agenda, time slots 2. RIPE 22 - minutes - review of actions 3. Reports from registries - European regional (RIPE NCC) - other registries, significant events, war stories - other regionals 4. Registry Procedures - European registries, ripe-104++ - general guidelines, RFC1466++ 5. Registry services and charges - RIPE NCC charging model - charging by local IRs 6. Tools 7. Input from other WGs - Database - Routing - DNS - other 8. AOB From woeber at cc.univie.ac.at Fri Jan 19 20:45:30 1996 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 19 Jan 1996 20:45:30 MET Subject: Fwd: Network Number Usage Survey-- [ipgr@ISI.EDU] Message-ID: <0099CA37.88DF971E.1@cc.univie.ac.at> Does anyone know details about the background, scope and/or aim of that exercise? "ipgr" seems to be unwilling or unable to reply to messages... Thanks, Wilfried. >Date: Thu, 18 Jan 1996 09:26:10 -0800 >From: ipgr at ISI.EDU >To: domain-admin at univie.ac.at, ipgr at ISI.EDU >Subject: Network Number Usage Survey-- 192.94.57.0 > >Hi, > >We have been asked by members of the PIER Working Group of the IETF, >with the approval of the IANA and Internic, to conduct a survey of a >section of the IPv4 address space. > >Your address appeared in the InterNIC database as the likely person to >ask about the following set of network numbers: >[....] >Your answers are important in planning future allocation of the IP >address space. Thank you for your time. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at 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 -------------------------------------------------------------------------- From GeertJan.deGroot at ripe.net Fri Jan 19 22:11:57 1996 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Fri, 19 Jan 1996 22:11:57 +0100 Subject: Fwd: Network Number Usage Survey-- [ipgr@ISI.EDU] In-Reply-To: Your message of "Fri, 19 Jan 1996 20:45:30 +0700." <0099CA37.88DF971E.1@cc.univie.ac.at> Message-ID: <9601192111.AA19428@ncc.ripe.net> Hi Wilfried, Maybe I can provide some background info to this. You probably know that Bill Manning started a project to look if all the class A's that have been allocated in the past, are still in use. As a result of this exercise, a substantial number of A's have been returned to IANA for reallocation. As a new exercise, Bill is trying to get back 192/8 and ask the people who are using it, to renumber to CIDR-blocks. Since most of 192/8 was assigned in a sequential fashion, the savings to the routing table may be substantial; as far as I remember, 192/8 is responsible for close to 50% of the total size of the routing table. So, while the savings to pool of free address space may be smaller, the savings to the routing table may be substantial if this succeeds. As to the unresponsiveness of ipgr at isi.edu, keep in mind that Bill asked everybody in 192/8.... Hope this helps, Geert Jan On Fri, 19 Jan 1996 20:45:30 MET "Wilfried Woeber, UniVie/ACOnet" wrote: > Does anyone know details about the background, > scope and/or aim of that exercise? > "ipgr" seems to be unwilling or unable to reply to messages... > > Thanks, > Wilfried. > > >Date: Thu, 18 Jan 1996 09:26:10 -0800 > >From: ipgr at ISI.EDU > >To: domain-admin at univie.ac.at, ipgr at ISI.EDU > >Subject: Network Number Usage Survey-- 192.94.57.0 > > > >Hi, > > > >We have been asked by members of the PIER Working Group of the IETF, > >with the approval of the IANA and Internic, to conduct a survey of a > >section of the IPv4 address space. > > > >Your address appeared in the InterNIC database as the likely person to > >ask about the following set of network numbers: > >[....] > >Your answers are important in planning future allocation of the IP > >address space. Thank you for your time. From orange at ripe.net Mon Jan 22 18:53:45 1996 From: orange at ripe.net (Carol Orange) Date: Mon, 22 Jan 1996 18:53:45 +0100 Subject: ripe-104++ Message-ID: <9601221753.AA26424@ncc.ripe.net> 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 at ripe.net). I look forward to meeting you all next week. -- Carol PS: Postscript follows in a separate message. ------------------------------------------------------------------------ European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ European Internet Registry Policies and Procedures Version 0.1 C. Orange, M. Kuehne, D. Karrenberg Document ID: ripe-104++ Obsoletes: ripe-104, ripe-105, ripe-127, ripe-128 ABSTRACT The distribution of IP address space follows the hierarchical scheme described in RFC1466. For Europe and parts of the surrounding area address space is allo- cated by IANA to the RIPE NCC which acts as a regional Internet registry. Address space is allocated by the RIPE NCC to local Internet Registries (IR), who assign it to to end users. In this document, we describe the policies and procedures asso- ciated with address space management that must be followed by local IRs. Moreover, we present a number of services available to local IRs to simplify the tasks associ- ated with address space management. 1. Scope This document describes the European Internet reg- istry system for the distribution of globally unique Internet address space and its operation. Particu- larly it describes the rules and guidelines govern- ing the distribution of this address space. The rules set forth in this document are binding for all address space allocated and assigned via the RIPE NCC. This document does not describe private Internet address space and multicast address space. This document does not describe local additions to the European guidelines. While providing an overview about the global Internet registry system this ____________________________________________________ ripe-104++.txt Page 1 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ document does not describe allocation and assignment rules used by other regional registries. 1.1. Overview The main body of this document comprises eight sec- tions, with content as follows. Section 2 (Internet Address Space and the Internet Registry System) defines different types of IP address space and their purposes. It explains the goals used in assigning such addresses and outlines the hierarchical nature of the Internet Registry system used to achieve these goals. The important distinction between Provider Aggregatable and Provider Independent address space is also covered. In Section 3 (Address Space Assignment Procedures), the procedures to be followed by European IP reg- istries when assigning IP addresses to users. The importance of documentation is stressed, while the various elements of information required are explained in detail. Next, the criteria and stan- dards of evaluation are dealt with. Finally, the actual assignment of address space, of various kinds, is described, as are the accompanying steps which a registry must take. Section 4 (Rules and Guidelines for Allocations) explains how the RIPE NCC allocates IP address space to registries in an efficient and equitable manner and how the status and nature of such allocations are made publicly available in the RIPE database. Section 5 (DNS and Reverse Address Mapping) docu- ments the role of the RIPE NCC in providing reverse delegation, and explains how registries can manage subsidiary reverse delegation of assigned address space. Section 6 (Internet Registry Operations) documents operational procedures of IR. This includes informa- tion on starting and closing an IR, communications, record keeping, confidentiality, and policies on IR operations. Moreover various resources and tools for registry operation are described in that sec- tion. Section 7 (AS Number Assignment Procedures and Poli- cies) describes how to manage a group of IP networks as an autonomous system. Both the procedural and technical issues involved in AS number management ____________________________________________________ ripe-104++.txt Page 2 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ are described. Section 8 (Interdomain Routing Considerations) describes the policies and procedures necessary to originate routes for assigned address space. We conclude with a glossary in which the key terms used in this document are defined. ____________________________________________________ ripe-104++.txt Page 3 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 2. Internet Address Space and the Internet Registry System 2.1. Types of IP Addresses IP addresses for the purposes of this document are 32-bit binary numbers used as addresses in the IPv4 protocols. There are three main types of IP addresses Public Addresses The public IP addresses make up the Internet address space. They are assigned to be glob- ally unique according to the goals described below. The main purpose of this address space is to allow communication using IPv4 over the Internet. A secondary purpose is to allow com- munication using IPv4 over interconnected pri- vate internets. One can currently distinguish two kinds of public addresses: provider inde- pendent (PI) and provider aggregatable (PA) addresses; see below for more details. Private Addresses Some address ranges have been set aside for the operation of private networks using IP. Anyone can use these addresses in their private net- works without any registration or coordination. Hosts using these addresses can not be reached from the Internet. For a thorough description of private address space, please refer to RFC1597. Special and Reserved Addresses There are a number of address ranges reserved for applications like multicasting. These are described elsewhere [ref] and are beyond the scope of this document. ____________________________________________________ ripe-104++.txt Page 4 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 2.2. Goals of Public Address Space Distribution In the remainder of this document, we are primarily concerned with the management of public Internet address space, as defined in the previous section. Every assignment of Internet addresses must guaran- tee that the following restriction is met. Uniqueness Each public Internet address worldwide must be unique. This is an absolute requirement which guarantees that every host on the Internet can be uniquely identified. In addition to the uniqueness requirement, public Internet address space assignments should be made with the following three goals in mind. Aggregation The distribution of public Internet addresses in a hierarchical manner, permitting the aggre- gation of routing information. This is neces- sary to ensure proper operation of Internet routing. This goal could also be called "Routability". Conservation The fair distribution of public Internet address space according to the operational needs of the end users operating networks using this address space. In order to maximize the lifetime of the public Internet address space resource, addresses must be distributed accord- ing to need, and stockpiling must be prevented. Registration The provision of a public registry documenting address space allocation and assignment. This is necessary to ensure uniqueness and to pro- vide information for Internet trouble shooting at all levels. It is in the interest of the Internet community as a whole that the above goals are pursued. It is worth noting that "Conservation" and "Aggregation" are ____________________________________________________ ripe-104++.txt Page 5 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ often conflicting goals, and therefore that each assignment must be evaluated carefully. Moreover, the above goals may occasionally be in conflict with the interests of individual end users or Internet service providers. Careful analysis and judgement are necessary in each individual case to find an appropriate compromise. The rules and guidelines in this document are intended to help Internet reg- istries and end users in their search for good com- promises. ____________________________________________________ ripe-104++.txt Page 6 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 2.3. The Internet Registry System The Internet Registry system has been established to achieve the above stated goals. It consists of hierarchically organized Internet Registries (IRs). Address space is typically assigned to end users by local IRs. The address space assigned is taken from that allocated to the local IR by the regional IR. End users are those organizations operating networks in which the address space is used. The address space may, however, be requested by a consultant (requester) acting on behalf of the end user. Local IRs are typically operated by Internet Service Providers (ISPs). Local IRs hold allocations of address space for assignment to end users. Assigned address space is actually used to operate networks, whereas allocated address space is held by local IRs for future assignments to end users. To achieve both the conservation and aggregation goals, only IRs can hold allocations of address space. IANA The Internet Assigned Numbers Authority has author- ity over all number spaces used in the Internet. This includes IP address space. IANA allocates pub- lic Internet address space to regional IRs according to their established needs. Regional IRs Regional IRs operate in large geopolitical regions such as continents. To date, three Regional IRs have been established, namely the InterNIC serving North America, the AP-NIC serving the Asian Pacific region, and the RIPE NCC serving Europe and sur- rounding areas. Since these do not cover all geo- graphical areas, regional IRs also serve areas around their core service areas. The number of regional IRs is expected to remain small. Regional IRs are established under the Authority of IANA. This requires consensus within the Internet community of the region. In particular, the ISPs in the region under consideration should be involved in the process. The duties of a regional IR include the coordination and representation of the local IRs in its region. ____________________________________________________ ripe-104++.txt Page 7 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ Local IRs Local IRs are established under the authority of a regional IR. Local IRs are typically operated by ISPs and serve the customers of those ISPs as well as the customers of smaller ISPs who are connected to the rest of the Internet through the larger ISP. Other organizations such as large international Enterprises can also operate local IRs. Much of this document is concerned with the respon- sibility of the local IR in the assignment process. In some cases, the local IR assigning the address space is not run by the ISP that will provide con- nectivity. It is important to note that maintenance of the administrative information regarding the assigned address space is the responsibility of the IR that makes the assignment, and not of the ISP providing the connectivity. Furthermore, only IRs can hold address allocations. End-Users Strictly speaking end users are not part of the IR system. They do, however, play an important role with respect to the goals defined above. In order to achieve the conservation goal, for example, end users should plan their networks to use a minimum amount of address space. They must document their addressing and deployment plans to the IR and fur- nish any additional information required by the IR for making assignment decisions. To achieve the aggregation goal, an end user should choose an appropriate local IR. End users should be aware that changing ISPs may require replacing addresses in their networks. Finally end users must provide and update registration data for the address space assigned to them. Requesters In addition to these key players in the Internet Registry System, there are often consultants who setup and manage networks for end users. The consul- tants may be the people actually submitting a request for address space to an IR on behalf of an end user. We refer to the person making the request for an end user as a requester, whether that person is employed by the organization, or is simply acting on behalf of the organization with respect to the address space request. ____________________________________________________ ripe-104++.txt Page 8 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ For Europe, the Internet Registry System hierarchy consists of the following entities (from the top down): IANA, the RIPE NCC, Local IRs. See Appendix A the area covered by the RIPE NCC. 2.4. Provider Independent vs Provider Aggregatable Addresses Provider Aggregatable Address Space Local IRs operated by Internet service providers are allocated Provider Aggregatable (PA) address space which they assign to their end users. This is done in such a way that routing information for many end users of an ISP can be aggregated on the borders of the provider's routing domain. This keeps the num- ber of routes and state changes in the interdomain routing system (between providers) at an acceptable level. The cost of propagating a relatively small number of aggregated routes is much lower than that of propagating each end user's individual routes throughout the entire interdomain routing system. If an end user changes service providers, their PA address space will have to be replaced. As a conse- quence, all hosts and routers at the end user's organization will have to be reconfigured. The end user will need to obtain an assignment from the local IR run by the new service provider, and return the previously assigned address space to the local IR run by the old service provider. To ensure the address space is properly returned, a clear, prefer- ably contractual, understanding is needed between the service provider and the end user. The agreement should state that the assignment of the address space becomes invalid when the provider no longer provides Internet connectivity to the end user or shortly thereafter. The goal of this arrangement is to minimize the load on the interdomain routing system. If the end user continued to use PA address space obtained from their previous service provider when connecting to another service provider, their routing information could not be aggregated and would have to be propa- gated separately throughout the whole interdomain routing system. ____________________________________________________ ripe-104++.txt Page 9 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ Provider Independent Address Space In contrast to PA address space, PI address space can remain assigned to its user as long as the cri- teria for the original assignment are met. The dura- tion of the assignment is independent of the use of a particular provider's services. The apparent advantage of PI address space is that a user's hosts and routers need not be reconfigured if the user decides to change service providers. However, PI addresses are expensive to route because no use can be made of aggregation. All early Internet address space assignments were provider independent. Many assignments made by local IRs are also formally provider independent due to a lack of prior agree- ments between ISP and the end user that the assign- ment will be terminated when the service is. Validity of assignment Assignments of any kind of address space are valid as long as the original criteria on which the assignment was based are still valid. If an assign- mnet is made for a specific purpose and the purpose does no longer exist, also the assignment is no longer valid. If an assignment is based on informa- tion that turns out to be invalid so is the assign- ment. ____________________________________________________ ripe-104++.txt Page 10 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 3. Address Space Assignment Procedures 3.1. Introduction In this section, we describe the procedures to be followed by local IRs when assigning address space to their users. We start with a description of the information to be gathered from the user. The pur- pose of the information gathering is twofold. First, the information is required to make address assign- ment decisions, with respect to the aggregation and conservation goals. Second, the information is required for registration purposes. We go on to describe how this information should be evaluated to make appropriate assignments, and introduce additional considerations that may be essential in the assignment decision. Finally we specify the procedures to be followed in the assign- ment process. Before going into the factors in the assignment pro- cess, we start with some general background informa- tion and policies that determine the information to be gathered, and the procedures to be followed. Address space is assigned by IRs to end users who use it to operate the specific networks described in an address space request. IRs guarantee that no other end user will be assigned the same address space during the validity of the assignment. An assignment is valid as long as the criteria on which it is based remain valid. In accordance with the conservation goal, end users are not permitted to reserve address space. Evalua- tion of IP address space requests must be based on the documentation provided for the following 24 months, as specified in the addressing plan and the current address space usage described in the next section. The amount of address space assigned must be justified by this documentation. This means that address space assigned in the past should be used to meet the current request if possible. Once an orga- nization has used its assigned address space, it can request additional address space based on an updated estimate of growth in its network. ____________________________________________________ ripe-104++.txt Page 11 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 3.2. Documentation To make appropriate assignment decisions, informa- tion must be gathered about the organization, addressing requirements, network infrastructure, current address space usage, and future plans of the end user requesting address space. Some information is essential to the assignment process, and is for- mally required by the IR's. Other information is very helpful in making assignment decisions, but is not strictly required. The Local IR must assure that the required information is complete before proceeding with the request. For gathering the required information, the RIPE NCC provides a set of forms and a set of instructions to fill them in. Although use of the forms provided (or a local-language equivalent) is strongly encour- aged, each local IR can obtain and manage this information as it considers appropriate. Requests requiring evaluation by the NCC must, however, be submitted on a current version of the "IP Address Space Request Form". The information gathered in the assignment process must be maintained permanently by the IR making the assignment. It must be made available to the parent registry immediately upon request. The IR is respon- sible for protecting the end user's privacy. Aside from the data specified in Section (database infor- mation) below, which is published in the registry database, the data gathered must be kept in strict confidence. The IR is not authorized to provide the information to anyone not representing the parent registry. In the subsections that follow, we outline the spe- cific data to be gathered and the reasons for doing so. 3.2.1. Required Information The following set of information must be provided with every request for an address assignment. The data is essential both to properly assigning addresses and to maintaining a global overview of assignments. With the exception of the information specified in Section (current address space usage), all information refers to the currently requested address space. ____________________________________________________ ripe-104++.txt Page 12 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 3.2.1.1. Overview of Organization To properly assess the user's address space require- ments, it is essential to understand the structure of the organization to which the addresses are being assigned, and which part of the organization will make use of the addresses. Consider the following situation. A bicycle manufac- turer based in Belgium has a variety of departments. Some, such as the Front Fork and Derailer depart- ments, specialize in specific bike parts. Others, such as the Sales and Development departments are more general by nature. In such a company, the departments Sales, Development, and Manufacturing may fall directly under the top management, whereas the subdepartments Derailer, Chain, Pedal, and Front Fork fall under the Manufacturing department. If someone submits a request for address space, we must know which part of the organization will make use of the assigned addresses. Suppose, for example, the Manufacturing department is assigned address space for use by all bike parts sub-departments. If shortly thereafter, the Chain department requests address space it is important that we know an assignment has already been made to the organization to meet the Chain department's needs. A similar situation may occur if the Sales department has groups of representatives in several countries. It is essential to know if addresses being requested by the central office will be used in Antwerp or in Madrid. We want to prevent assignments being made for the same subnet by two different parts of the organization. In the case of a distributed sales department, this must also be known to assure a proper assignment with respect to aggregation. The person responsible for making the assignment can only be aware of this situation if an overview of the organization, and the requester's role therein is known. It is therefore important that a brief overview of the organizational structure be pro- vided. This should include details of the parent company, subsidiaries and contact persons. In the case of our bicycle manufacturer, one would expect someone representing the Chain department to produce general information about the structure of the organization in Belgium, and contact persons for the Manufacturing, Sales, and Development depart- ments. We would not expect the same person to pre- sent information on the structure within the Sales ____________________________________________________ ripe-104++.txt Page 13 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ department, such as who manages the office in Rome. Clearly, the assignment process is greatly simpli- fied if an organization coordinates its address space management, and if all requests are made by a single body representing the entire organization. Contact Persons To facilitate handling the request, contact informa- tion is required for the person making the request and for someone at the organization to which the address space will be assigned. The information should be entered on the Requester and User contact templates, respectively. These templates contain name, organization, country, phone, fax-no, and e- mail fields. In each template, the appropriate per- son's name should be specified in full. The organi- zation refers to that in which this person works, and the country refers to that in which the person's office is located. The telephone and fax numbers should include the country prefixes in the form +code, and if the person can be reached by e-mail from the Internet, the address should be specified. The contact person information is only collected to facilitate the address space request. It may or may not include data for persons that will later be entered in the RIPE database. 3.2.1.2. Current Assignment Space Usage To meet the conservation goal in address space assignments, one must have information regarding address space assignments made to the user in the past before new address space can be assigned. A detailed description of how the address space is currently being used is required. Using this infor- mation, we can prevent assigning new address space, where already assigned addresses can be employed to meet the user's needs. Each set of addresses already assigned to the orga- nization must therefore be reported. The current use of these addresses must be documented in a table similar to that below. An entry must be included for each physically separate subnet in the user's network. Subnets are considered to be physically separate if there is an IP router between them. ____________________________________________________ ripe-104++.txt Page 14 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ Each row in the table below contains an entry for a subnet in the end user's organization. Addresses Used Prefix Subnet Mask Size Current 1yr 2yr Description 193.1.193.0 255.255.255.192 64 28 34 50 Derailer 193.1.193.64 255.255.255.224 32 10 12 15 Chain 193.1.193.96 255.255.255.224 32 8 13 17 Front Fork 193.1.193.128 128 Unused 193.1.194.0 255.255.255.0 256 132 170 210 Frame 193.1.195.0 255.255.254.0 512 317 350 380 Assembly 1024 495 579 672 Totals Each entry in the table above is made up of the fol- lowing fields which specify the current and pro- jected use of the address space in the subnet. The Description field is used to specify a short but semantically meaningful description of the role of the subnet in the user's organization. In our exam- ple, we have descriptions corresponding to various bike parts. Together with the size information, this provides significant insight as to the network structure in the organization. The number of network interfaces currently used in the subnet, along with the number expected to be needed in the coming one and two years must also be specified. These numbers are to be entered in the Current, 1yr, and 2yr fields of the subnet entry, and include the number of network interfaces to be used, such as those for hosts, routers, gateways, terminal concentrators, printers, and any other machines requiring one or more network interfaces. The Size field is used to specify the size of the subnet, which determines the maximum number of net- work interfaces that can be incorporated in the sub- net. It must be a power of two, and of course should be greater than or equal to the number specified in the 2yr field. If it is smaller, this may be the motivation for the address request, or it may be a mistake in the requester's planning. The Subnet Mask field is used to specify just that, and finally, in the Prefix field, the position in the assigned address space at which the addresses for this subnet start is specified. As in the example, entries should be made in the ____________________________________________________ ripe-104++.txt Page 15 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ table for assigned address space which is currently not used. 3.2.1.3. Request Overview The network overview is used to obtain a quick idea about the scale of the request. This information allows the IR processing the request to gain immedi- ate insight as to the nature of the assignment request. The exact information to be gathered is: Size of Request To give the IR an immediate indica- tion of the scale of the request, the total number of Internet addresses being requested must be speci- fied under request-size on the network overview form. If the request-size is 512, the user speci- fies a need for that number of Internet addresses. Prior to the use of CIDR, the user would have asked for two Class C networks. Because classless address- ing is now used, the size of the request may be less than 256 or fall between the class borders (e.g. 32, 288, 384). Addresses to be Used To obtain an overview of the structure of the requester's network, one must know how many Internet addresses will actually be used at different points in time. This corresponds to the number of interfaces to the network, which often will be slightly higher than the number of hosts. In the network overview form, the fields addresses- immediate, addresses-year-1, and addresses-year-2 are used to specify how many of the requested net- work addresses will be used immediately following the assignment, within 12 months, and within 24 months, respectively. Number of Subnets In practice, the end user will want to employ the requested addresses in one or more subnets in an organization. The number of physically separate subnets in which the requested addresses will be used is an important factor in making correct assignments. Together with the num- ber of addresses to be used, this provides a global picture of the requester's envisioned network infrastructure. In the network overview form, the fields subnets-immediate, subnets-year-1, and sub- nets-year-2 are used to specify the number of sub- nets in the requester's network plan to be ____________________________________________________ ripe-104++.txt Page 16 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ implemented immediately, within 12 months and within 24 months, respectively. Internet Connection Prior to assigning address space, it is essential to know if the end user requesting IP addresses is already connected to the Internet. If so, then the selection of appropriate address space for this user may depend on which provider(s) currently supplies connectivity. If the user is not connected, but is planning to be, this should also be taken into account. This information is essential if the conservation and aggregation goals of the public address space distribution are to be met. The current and planned connectivity of the user is specified in the inet-connect field of the network overview form. Country Finally, the country or countries in which the addresses will be used must be specified using the ISO 3166 two letter code. The country-net field of the network overview form is reserved for this purpose. If the ISO 3166 code is not known, the full name of the country should be specified. Private Address Space Using private addresses helps to meet the conservation goal. For this reason, users should always be informed that private addresses might be a viable option. In particular, private address space can be employed if not all hosts require network layer access to the Internet. Although users are not required to use private address space even if it would satisfy their needs, it is important that they have considered the possi- bility. The private-considered field in the network overview form should be checked after the requester has indicated whether it is applicable for the user's network. Request Refused If a user's organization has had an assignment request refused in the past, then it is useful to know when and by which IR. Whatever the case, it is useful to know if a request has been refused, and why. This information should be speci- fied in the request-refused field in the network overview form. PI Requested If provider independent address space is requested by the user, special steps will have to ____________________________________________________ ripe-104++.txt Page 17 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ be taken by the local IR processing the request. The PI-requested field in the network overview form should be checked if this is a request for PI address space. 3.2.1.4. Addressing Plan To assess the suitability of assigning the requested address space, an addressing plan is required. This provides detailed information on the projected use of the requested address space. Like the current address space usage, the addressing plan is a table in which every subnet is specified. With few exceptions, the entries in the following table are the same as those in the table of current address space usage. Relative Addresses Used Prefix# Subnet Mask Size Immediate 1yr 2yr Description 0.0.0.0 255.255.255.192 64 8 16 30 Systems Group 0.0.0.64 255.255.255.224 32 17 22 26 Engineering 0.0.0.96 255.255.255.224 32 12 17 20 Manufacturing 0.0.0.128 255.255.255.224 32 10 15 20 Sales 0.0.0.160 255.255.255.240 16 5 9 12 Management 0.0.0.176 255.255.255.240 16 7 8 9 Finance 192 59 87 117 Totals The number of network interfaces immediately required in the subnet, along with the projected need for the coming 12 and 24 months must be speci- fied. These numbers are to be entered in the Immedi- ate, 1yr, and 2yr fields of the subnet entry. In the Relative Prefix field, we specify the rela- tive position in the assigned address space at which the addresses for this subnet will start. The rela- tive position of the first subnet is always 0.0.0.0. For each subsequent subnet, the start position is selected to allow for the total number of hosts in the Size fields of the subnets which precede it. To conserve address space, the start positions of the subnets should be selected to minimize padding in the address space. In the example above, we ____________________________________________________ ripe-104++.txt Page 18 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ arrange the rows in decreasing order of the Size field. This scheme can be applied in general to pre- vent wasting address space between subnets. The size of every valid request for address space will be the sum of sizes of the subnets specified in the addressing plan. Current evaluation criteria assume that addressing is classless. This means that all possible prefixes of any length can be used. If there are technical restrictions preventing the use of certain address ranges or the choice of optimal subnet sizes, these restrictions need to be explicitly documented. Doc- umentation needs to include the precise nature of the restriction, the make, model and version of the hardware or software causing the restriction, and its precise location in the network. 3.2.1.5. Database Information For registration purposes, information is required about the organization needing address space. Infor- mation is also required about the persons involved in the request and administration of the addresses. request. Some of the information may be redundant because the same person can play multiple roles. However, every role can be filled by someone differ- ent, so all information must be supplied in full. The data specified below is to be gathered by the local IR handling the assignment, and will be stored in the registry database, at which point it becomes publicly accessible. Organization Some information about the organization that will be using the addresses must be supplied for maintenance of the RIPE database. The Network Template is supplied for this purpose. To help identify this assignment in the RIPE database, a short, but semantically meaningful name must be entered in the netname field. A short description of the organization that will use the assigned addresses is needed. The information is specified using one or more descr fields in the Net- work Template. If, for example, the assigned addresses will be used by the Department of Neural Surgery at Catatonic State University, then the department and university names may be specified in two descr fields. The ISO 3166 country code should be specified in the country field. The full country ____________________________________________________ ripe-104++.txt Page 19 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ name can be used if the code is not known. The admin-c and tech-c fields are used to specify the IR handle (NIC handle) for the administrative and technical contact persons, respectively. The administrative person specified in the admin-c field must be physically located at the site of the net- work. The technical person specified in the tech-c field may be a network support person located on site, but could also be a consultant that maintains the network for the organization. In both cases, more than one person can be specified. The use of NIC handles to specify each contact person is required, as it assures each person has a unique entry in the database. If the person doesn't have an entry in the database, a unique NIC handle can be acquired upon request. Personal Data For every person involved in an assignment request, we need a full set of personal data. This data can only be omitted if up to date information for the given person is already stored in the RIPE database. If new data is provided for a person with an entry in the database, it will be viewed as an update upon submission, and overwrite the current person data. Otherwise, the following set of data must be specified in the Person Tem- plate. The person's name should be specified in full in the person field. The full postal address is specified using multiple address fields. The international telephone number which can be used to reach the person at work must be entered in the phone field, and the fax number should be entered in the fax-no field. Of course, the NIC handle for this person must be entered in the nic-hdl field to uniquely identify this person in the database. Submission Information In both the Network Template and Person Template, space is reserved to identify the person submitting these entries to the registry database. The submit- ter's e-mail address must be specified in the changed field together with the date the template is submitted. Similarly, the source field is used to specify the registry database where the requester information can be found after an assignment is made. In this ____________________________________________________ ripe-104++.txt Page 20 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ case it will be RIPE, as the requester information for this assignment will be stored in the RIPE database. 3.2.2. Additional Information In the assessment of an assignment request, the additional information described below is always useful. In some cases, IR's may require this data be provided as part of the evaluation process. Deployment Plan Suppose we are dealing with a new corporation that wants to have access to the Inter- net, and estimates an immediate need for 10,000 addresses. In such cases, a deployment plan may be requested from the user. The plan should include a list of events which will lead to the use of the requested addresses, along with the dates that the events will occur. This can be used to determine how realistic the user is being, and if suitable to phase the assignment process in according to the user's plans. Topological Map The old saying "a picture is worth a thousand words" certainly holds in the case of net- works. If a topological map of the current and planned network infrastructure in the requesting organization can be acquired, it can provide insight on the network structure. Such maps are often avail- able, and are quite useful when combined with the addressing plan and current address space usage. Special Circumstances Sometimes, due to the use of old systems or special purpose hardware, the user is unable to make use of assignments based on classless addressing. If this is the case, information should be gathered from the user as to the specific hard- ware or software which presents a problem. Moreover, it is useful to know how long the user will be using the hardware or software which presents a problem. Verification Information In working with a user who hasn't had substantial network experience, it is sometimes hard to determine whether the user's request is based on a realistic plan. It can there- fore be useful to request information which might indicate the degree to which the user understands network planning and management. First, one may ask how accurate the user thinks the estimations in the addressing plan are, and how they have been derived. The corresponding name space plans provide another ____________________________________________________ ripe-104++.txt Page 21 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ indication of how well considered the user's plans are. 3.3. Evaluation Having collected the above information, we must now determine a proper assignment with respect to the conservation and aggregation goals stated in Section 1. Every request requires an individual evaluation process that takes current assignment guidelines into account. Given the above documentation, one must determine if IP addresses should be assigned, and if so, how many and of what type. In the process, it is essential that IR's work to prevent the stockpiling of address space. The use of classless addressing will con- tribute to the conservation of address space. Mean- while, to enable proper routing, one must make strategic decisions with regard to aggregation. These concerns motivate the evaluation process out- lined in this section. Evaluation Steps 1. Current address space usage One should start by comparing the current address space usage provided by the requester with other information available to the IR. After verifying the current address space usage, one should check to see if the requested IP addresses can be taken from those already assigned to the user. 2. Network Overview Next, the size of the request, specified in the Network Overview should be compared with the number of addresses to be used immediately, and within two years of the time the request is made. Here we evaluate the utilization rates, that is address space requested in relation to that to be used. Unless there are special circumstances, imme- diate utilization should be at least 25% of the assigned address space, and the utilization rate one year later should be at least 50%. 3. Private Address Space If private address space might be suitable for this network, it must be assured that the user is aware of this option and has decided against it. Moreover users should be aware that they will have more address space at their disposal if they use private address space. ____________________________________________________ ripe-104++.txt Page 22 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 4. Very Small Enterprises (VSE's) An address space user with a small number of hosts (currently <=32) is referred to as a very small enterprise (VSE) regardless of the size of the organization. Address space for VSEs should be assigned in a classless way. As with all address space requests, care should be taken to avoid assigning more address space than is required. See (Eidnes/deGroot) for appropriate reverse delegation methods. VSEs that do not intend to connect to the Internet should nor- mally not be assigned PI space but referred to pri- vate address space because the effort to renumber into PA space at that point is normally minimal. 5. Addressing Plan In evaluating the addressing plan, one should first check that the totals for the number of addresses to be used immediately, in one year, and in two years, correspond to those speci- fied in the request overview. The validity of the network masks should then be checked to see if they are consistent with the size of the subnet. Some- times address space can be saved by using different subnet masks than specified by the user. If so, the user should be requested to resubmit an addressing plan with a more appropriate use of network masks. In general, there should not be a large gap between the number of addresses requested for a subnet (size) and the number which will be used. This holds even if the requester argues that network adminis- tration will be greatly simplified by an addressing scheme with lots of padding. 6. Additional Information If a deployment plan has been provided, the addressing plan should be reviewed to see if the two correspond. Likewise, one should inspect the topology map if it is available to see if it agrees with the addressing plan. Any information gathered which can be used to check the validity of the current address space usage and addressing plans should be employed to do so. 7. Address Reservations Assignments must be based solely on realistic expectations as specified in the addressing plan and the current address space usage. End users are not permitted to reserve addresses based on long term plans, because it fragments the address space. Such reservations are generally fruitless because they turn out to be unnecessary or insufficient for the user's needs. 8. Static Dialup Due to constraints on the available free pool of IPv4 address space, the use of static ____________________________________________________ ripe-104++.txt Page 23 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ IP address assignments (e.g., one address per cus- tomer) for dial-up users is strongly discouraged. While it is understood that the use of static addressing may ease some aspects of administration, the current rate of consumption of the remaining unassigned IPv4 address space does not permit the assignment of addresses for administrative ease. Organizations considering the use of static IP address assignment are expected to investigate and implement dynamic assignment technologies whenever possible. If allocations for this purpose are indeed made, special allocation and verificatin pro- cedures apply. Please contact the RIPE NCC for details. 9. Virtual Hosts Sometimes a single host is assigned more than one IP address on the same interface and physical network. Often this is used to circumvent shortcomings in higher level protocols such as HTTP. Large scale assignments for this purpose are dis- couraged for the reasons mentioned in the paragraph above. If allocations or assignments for this pur- pose are indeed made, special allocation and verifi- catin procedures apply. Please contact the RIPE NCC for details. 3.4. Assignment Procedures We now describe the specific procedures to be fol- lowed in assigning address space. In the following, we assume that the required information has been gathered, and evaluated as outlined in the previous subsections. The procedures described in this sub- section lead to the assignment of specific address space for the request under consideration. 3.4.1. Assignments within Allocations Once an IR has assured that the address space request merits the assignment of k addresses, the actual set of addresses to be assigned must be selected. If the addresses are to be assigned from a range of address space allocated to the local IR making the assignment, then care must be taken to prevent fragmentation of the allocated space. Specifically, each set of address space assigned should start on a CIDR (bit) boundaries. This means the start address for each set of assigned range must be divisible by the size of the block to be assigned. This helps to achieve the aggregation ____________________________________________________ ripe-104++.txt Page 24 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ goal in address space assignments. Suppose a request can be satisfied with a number small chunks of address space rather than one large one. For example, if 384 addresses are sufficient to satisfy a request, but no more than 256 will be used in a single physical subnet, then the user can be assigned a /24 and a /25 rather than a /23, which results in saving a /25 for another user. Local IRs are encouraged to assign multiple range of address space, rather than a single range in accordance with the conservation goal. Of course the effort to do so should increase as the amount of address space that can be saved in doing so increases. Local IRs are always welcome to request advice from the RIPE NCC in making assignment decisions. In some cases, however, an assignment must be approved by the RIPE NCC even if it is made from a block of address space allocated to the local IR making the assignment. In particular, if the size of the assignment is larger than the local IR is permitted to make, it must be approved by the RIPE NCC in advance. The size of assignments a local IR is per- mitted to make without prior approval is determined by the local IR's assignment window, discussed in Section (Assignment Window). If the addresses are to be assigned from a block not allocated to the local IR, the selection will be made by the IR to which the the address space is allocated. In general, this will be the regional IR. 3.4.2. PA vs PI Space The criteria used to determine the amount of address space and the registration requirements are identi- cal for PA and PI address space. For example, regardless of whether the assignment is for PA or PI address space, an assignment with a prefix longer than /24 can be made if the request can be satisfied with less than 256 addresses. Local IRs must make it clear to the user which type of address space is assigned. 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. ____________________________________________________ ripe-104++.txt Page 25 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ With respect to aggregation, the clear advantages of assigning PA space mandate that IRs recommend its use whenever possible. End users should therefore be advised to use PA space if it appears to be suf- ficient for their situation. The consequences of using PA or PI space must always be made clear to the end user. In particular, to be certain end users understand the consequences of using PA space, the assigning IR must give each user requesting PA space a warning similar to the follow- ing: Assignment of this 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. ISP XXXX has the right to re-assign the address space to another user upon termination of the agreement or following an agreed period thereafter. If the address space assign- ment becomes invalid, you may have to re- configure the addresses of all equipment using this address space. The reconfigura- tion is only necessary if you continue to require global uniqueness of the addresses for that equipment. It is important to realize that some Internet services do not require globally unique addresses. For example, services that can be accessed through a NAT (network address translator) or through an application layer gate- way/firewall don't require the machines which access them to have globally unique addresses. Of course, the consequences of using PI space must also be made clear to the end user. This is accom- plished by giving each user requesting PI space a warning similar to the following: Assignment of this address space is valid as long as the criteria for the original assignment are met. Note that the assign- ment of PI address space does not imply that it will be routable on any part of the Internet. Users may have to pay a pre- mium for routing of PI addresses (as opposed to PA addresses). Eventually, it ____________________________________________________ ripe-104++.txt Page 26 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ may become impossible to get relatively small amounts of PI space routed on most of the Internet. We strongly suggest you contact any prospective service providers for information regarding the possibility and pricing of service when using PI addresses. The type of assigned address space must be regis- tered in the status attribute of the inetnum object in the RIPE database by the assigning IR. The pos- sible values of this attribute are ASSIGNED PA This is used for PA address space that has been assigned to an end user. ASSIGNED PI This is used for PI address space that has been assigned to an end user. Every new address space assignment must be marked as PA or PI in the RIPE database. Moreover, to improve registration of old assignments, IRs are encouraged to mark past assignments in the registry database with PA or PI as appropriate. Any assigned address space without an explicit type in the status attribute is assumed to be PI space. Priority should therefore be given to marking PA space as such. In general, local IRs are provided with ranges of PA space from which they can make assignments. If an end user requests address space of a type which an IR does not assign (typically PI), the IR must refer the end user to a registry which can fulfill the request. IRs that do not assign PI space must sup- port an IR that does provide this service. This includes aiding the end user in the preparation of a properly documented request and furnishing back- ground information to the assigning IR. Local IRs which do not normally assign large amounts of a particular type of address space do not need to hold an allocation of that type of address space. It can be acquired from the RIPE NCC as needed. In general, such assignments will not be aggregatable with other address space assigned by the local IR. ____________________________________________________ ripe-104++.txt Page 27 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ IRs have assigned address space in the past which is aggregated in practice but is not formally of type PA. Formally, address space is not of type PA unless there are contractual agreements regarding the assignment's termination. It is therefore recom- mended that IRs ask end users to release non-PA address space upon termination of service. Simi- larly, if an end user moves to a new IR to obtain Internet services, the new IR should encourage the user to release any non-PA address space they hold, and to request a new assignment (a process which the new IR should be more than happy to support). To minimize the use of non-PA space in the future, IRs should work to make contractual arrangements to con- vert aggregated address space to formal PA address space. 3.4.3. Multihomed Users An end user may have reason to obtain connectivity through more than one service provider. If so, it may be necessary to obtain address space assignments from more than one IR to support different parts of the user's network. In general, there is no problem with users acquiring address space and service from more than one IR. Such users are referred to as mul- tihomed. Because users can be multihomed, IRs must be espe- cially careful in reviewing address space requests, and the corresponding current address space usage described in Section (Current Assignment Space Usage). One must be sure that users are not acquir- ing multiple assignments for the same purpose from different IRs. Moreover, one must check that a sim- ilar address space request has not been refused by another IR for some valid reason. 3.4.4. Update the RIPE Database Registration of objects pertaining to an assignment in the RIPE database makes it possible to track the use of address space, facilitate operational con- tacts, and facilitate studies of address allocation. These activities are essential to effective mainte- nance of the Internet. Submission of objects to the database is the final step in making an assignment. This step makes the assignment definite, and makes public information regarding the assignment available to anyone seeking ____________________________________________________ ripe-104++.txt Page 28 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ it. Care should therefore be taken to assure the correctness of the assignment and of all relevant data prior to completing this step. The information collected about the user's organiza- tion in the Network Template (see Section (Database Information)), should be entered in an inetnum database object. The range of addresses assigned to the user is also entered in the inetnum object, and is specified in dotted quad notation. For example, if an organization is assigned a /22 address set for 1024 network addresses, the range will be something like: 193.1.192.0 - 193.1.195.255. And, as stated above, the status field of the inetnum object is used to specify whether the assigned addresses are PI or PA. In addition to the inetnum object, a person object must be submitted for each of the people specified in the tech-c and admin-c fields of the inetnum object. Assuming the assigning IR has properly stored infor- mation gathered in the assignment process for future reference, submission of the objects described above completes the assignment process. The IR can now provide the end user with the assigned address range and any other data relevant to its use. 3.5. Assignment Window It is essential that local IR staff follow the pro- cedures for address space assignments and apply the evaluation criteria used to determine assignment sizes as discussed above. The procedures are straightforward. The evaluation criteria however, can be difficult to apply to new situations. To assure the conservation, aggregation, and regis- tration goals are met, we must be sure the assign- ment criteria and procedures are properly applied. In general, this means that local IRs with little or no experience should receive maximal support in the assignment process, whereas local IRs with more experience should be allowed to make most assign- ments without consulting the RIPE NCC. Large assign- ments always require prior approval because of their impact on the available address space. To achieve this variation in support level, each local IR is given an assignment window by the RIPE NCC. The assignment window is the maximum number of ____________________________________________________ ripe-104++.txt Page 29 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ addresses that can be assigned by the local IR to an end user without prior approval by the RIPE NCC. The number of addresses is always expressed in /xx nota- tion, so a local IR with an assignment window of /23 is allowed to assign up to 512 addresses to an end user without prior approval of the RIPE NCC. As the local IR staff gain experience, the window size is increased. Every assignment of address space which is larger than the local IR's assignment window is invalid prior to explicit approval by the RIPE NCC. Without such approval, the address space should not be used to address hosts with Internet connectivity. Use of invalid address can result in a failure to meet the uniqueness requirement for Internet addresses. The assignment window is not only applied to indi- vidual assignments, but to multiple assignments to the same end user in a single year. If an local IR makes combined assignments to an organization in the course of a year, the total amount of address space assigned may not exceed the local IR's assignment window. Additional address space can only be assigned to that organization after approval by the RIPE NCC. In general the assignment window for new registries is 0. This means that every assignment requires prior approval by the RIPE NCC before becoming effective. This ensures that the local IR staff become familiar with the evaluation criteria and assignment procedures described in this document. As the local IR staff become familiar with assign- ment procedures, the assignment window can be raised. In general, it will be raised to /24 the first time, which means the local IR staff can make assignments for up to 256 addresses. If the RIPE NCC receives a request to raise the assignment win- dow for a local IR, it will be evaluated based on the proficiency of the local IR staff. This is determined based on whether assignment documentation presented to the RIPE NCC is correctly completed, whether good judgement is shown in the evaluation of address space requests, whether past assignments have been properly registered, and on the experience of the local IR with handling larger assignments. Currently, the maximum size of the assignment window for any local IR is 4096 addresses (/20). This means that every assignment for more than this requires approval of the RIPE NCC. ____________________________________________________ ripe-104++.txt Page 30 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ Sometimes new registration staff at a well estab- lished local IR make errors both in judgement and procedure before they are properly trained to make assignments. 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. As the new staff members receive training, and the proficiency level is again up to par, the assignment window can be increased just as it would be for a new local IR. ____________________________________________________ ripe-104++.txt Page 31 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 4. Rules and Guidelines for Allocations In the previous section, we described the procedures for handling requests for address space, including the selection of a set of addresses for an end user. In completing the assignment, address space is selected from a range that has been allocated to the local IR for this purpose. Of course, before a local IR can select addresses to fulfill a request, it must have a range of address space to choose from. (If the local IR does not have sufficient address space of the type to be assigned, then a request can be submitted to the RIPE NCC.) To meet this need, a range of addresses is made available to a local IR by the RIPE NCC. Such an address range is referred to as an allocation. In Europe, the RIPE NCC is the only IR permitted to allocate address space. A local IR is not allowed to re-allocate part of its allocation to any other organization. Moreover, without prior approval by the NCC, local IRs are not permitted to exchange allocated address space among themselves. In some cases, a local IR acts as a transit provider for an IP service provider which itself is not a local IR. 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. If at some point, an IP service provider decides to become a local IR rather than using an existing local IR to obtain address space, then all subse- quent assignments it makes should be from address space allocated directly to it from the RIPE NCC. Furthermore, address space already assigned by the IP provider from transit providers' allocations should be returned to the transit provider, and new assignments should be made to the end users from the new allocation. In this section, we describe how a local IR can obtain an allocation and how allocated address space should be managed. 4.1. Slow Start of Allocations To prevent allocating large blocks of address space that won't be assigned, the RIPE NCC has introduced the concept of a slow start for allocations. The ____________________________________________________ ripe-104++.txt Page 32 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ idea is to allocate address space to local IRs at the rate it will be assigned. 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. It will be increased or decreased depending on the rate at which a local IR assigns its space. The slow start mechanism implements a consistent and fair policy for every local IR with respect to allo- cations. Although the mechanism is similar to the assignment window mechanism described in the previ- ous section, the policy it implements is different. The size of further allocations depends exclusively on the assignment rate of the local IR concerned while the assignment window depends on the demon- strated proficiency of the registry staff in evalu- ating requests and processing assignments. 4.2. First Allocation When a new local IR starts up, it has no address space allocated to it. 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 assign- ments, the size of the first allocation is always set at the minimum. Remember that the amount of space allocated does not determine the size of assignments a local IR can make. As discussed at the end of the previous sec- tion, a new local IR must have every assignment approved by the RIPE NCC until its assignment window is increased. 4.3. Further Allocations A local IR can obtain additional allocations as required. A request should be submitted to the RIPE NCC when the currently allocated address space is nearly used up, or if a single request requires a larger block of addresses than can be satisfied with the currently allocated address space. To obtain a new allocation, a local IR should submit a request to the RIPE NCC which includes a complete list of the assignments made from all of their allocations. The RIPE NCC will check this information, compare it ____________________________________________________ ripe-104++.txt Page 33 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ with assignments registered in the database and may request further information to determine the need for a new allocation. Additional address space will be allocated after the information delivered with the request has been verified, and a new allocation has been deemed necessary. Unfortunately, there is a tradeoff between the aggregation and conservation goals in making alloca- tions. To further aggregation, the RIPE NCC aims to allocate contiguous address ranges to a local IR. However, because conservation of address space must also be taken into account, this is not always pos- sible. A new allocation to a registry can therefore not be expected to be contiguous with past alloca- tions. While the RIPE NCC always aims to further the aggregation goal, and therefore to allocate contigu- ous space, the RIPE policy is that under no circum- stances are multiple allocations made to the same local IR guaranteed to be contiguous. 4.4. Allocation Registration Allocations are registered in the RIPE Database by the NCC using inetnum objects. Information about the local IR, which is similar to that for an end user receiving an assignment is stored together with the range of allocated address space and its type. The range of addresses is stored in the inetnum field in dotted quad notation, and the type is stored in the status field and can have one of the following values: ALLOCATED PA This address space has been allocated to an IR, and all assignments made from it are provider aggregatable. This is the most common alloca- tion type for local IRs. ALLOCATED PI This address space has been allocated to an IR, and all assignments made from it are provider independent. ALLOCATED UNSPECIFIED This address space has been allocated to an IR, and assignments made from it may be either provider aggregatable or provider independent. ____________________________________________________ ripe-104++.txt Page 34 European IR - Policies and Procedures - Version 0.1 Orange, Kuehne, Karrenberg ____________________________________________________ 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. These objects are maintained by the RIPE NCC. When hierarchical authorization is implemented, autho- rization can be implemented for creation of inetnum objects "under" the allocation objects. ____________________________________________________ ripe-104++.txt Page 35 From orange at ripe.net Mon Jan 22 18:54:40 1996 From: orange at ripe.net (Carol Orange) Date: Mon, 22 Jan 1996 18:54:40 +0100 Subject: ripe-104.ps Message-ID: <9601221754.AA26482@ncc.ripe.net> %!PS-Adobe-3.0 %%Creator: groff version 1.08 %%DocumentNeededResources: font Helvetica %%+ font Helvetica-Bold %%+ font Helvetica-Oblique %%+ font Times-Italic %%+ font Times-Roman %%+ font Courier %%+ font Times-Bold %%DocumentSuppliedResources: file /home/dfk/tgif/ripe-ncc.eps %%+ procset grops 1.08 0 %%Pages: 28 %%PageOrder: Ascend %%Orientation: Portrait %%EndComments %%BeginProlog %%BeginResource: procset grops 1.08 0 /setpacking where{ pop currentpacking true setpacking }if /grops 120 dict dup begin /SC 32 def /A/show load def /B{0 SC 3 -1 roll widthshow}bind def /C{0 exch ashow}bind def /D{0 exch 0 SC 5 2 roll awidthshow}bind def /E{0 rmoveto show}bind def /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def /G{0 rmoveto 0 exch ashow}bind def /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def /I{0 exch rmoveto show}bind def /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def /K{0 exch rmoveto 0 exch ashow}bind def /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def /M{rmoveto show}bind def /N{rmoveto 0 SC 3 -1 roll widthshow}bind def /O{rmoveto 0 exch ashow}bind def /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def /Q{moveto show}bind def /R{moveto 0 SC 3 -1 roll widthshow}bind def /S{moveto 0 exch ashow}bind def /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def /SF{ findfont exch [exch dup 0 exch 0 exch neg 0 0]makefont dup setfont [exch/setfont cvx]cvx bind def }bind def /MF{ findfont [5 2 roll 0 3 1 roll neg 0 0]makefont dup setfont [exch/setfont cvx]cvx bind def }bind def /level0 0 def /RES 0 def /PL 0 def /LS 0 def /PLG{ gsave newpath clippath pathbbox grestore exch pop add exch pop }bind def /BP{ /level0 save def 1 setlinecap 1 setlinejoin 72 RES div dup scale LS{ 90 rotate }{ 0 PL translate }ifelse 1 -1 scale }bind def /EP{ level0 restore showpage }bind def /DA{ newpath arcn stroke }bind def /SN{ transform .25 sub exch .25 sub exch round .25 add exch round .25 add exch itransform }bind def /DL{ SN moveto SN lineto stroke }bind def /DC{ newpath 0 360 arc closepath }bind def /TM matrix def /DE{ TM currentmatrix pop translate scale newpath 0 0 .5 0 360 arc closepath TM setmatrix }bind def /RC/rcurveto load def /RL/rlineto load def /ST/stroke load def /MT/moveto load def /CL/closepath load def /FL{ currentgray exch setgray fill setgray }bind def /BL/fill load def /LW/setlinewidth load def /RE{ findfont dup maxlength 1 index/FontName known not{1 add}if dict begin { 1 index/FID ne{def}{pop pop}ifelse }forall /Encoding exch def dup/FontName exch def currentdict end definefont pop }bind def /DEFS 0 def /EBEGIN{ moveto DEFS begin }bind def /EEND/end load def /CNT 0 def /level1 0 def /PBEGIN{ /level1 save def translate div 3 1 roll div exch scale neg exch neg exch translate 0 setgray 0 setlinecap 1 setlinewidth 0 setlinejoin 10 setmiterlimit []0 setdash /setstrokeadjust where{ pop false setstrokeadjust }if /setoverprint where{ pop false setoverprint }if newpath /CNT countdictstack def userdict begin /showpage{}def }bind def /PEND{ clear countdictstack CNT sub{end}repeat level1 restore }bind def end def /setpacking where{ pop setpacking }if %%EndResource %%IncludeResource: font Helvetica %%IncludeResource: font Helvetica-Bold %%IncludeResource: font Helvetica-Oblique %%IncludeResource: font Times-Italic %%IncludeResource: font Times-Roman %%IncludeResource: font Courier %%IncludeResource: font Times-Bold grops begin/DEFS 52 dict def DEFS begin/u{.001 mul}bind def end/RES 72 def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron/scaron/zcaron /Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef/.notdef/.notdef /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/space /exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright/parenleft /parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four /five/six/seven/eight/nine/colon/semicolon/less/equal/greater/question/at/A/B/C /D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash /bracketright/circumflex/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q /r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase /guillemotleft/guillemotright/bullet/florin/fraction/perthousand/dagger /daggerdbl/endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen/brokenbar /section/dieresis/copyright/ordfeminine/guilsinglleft/logicalnot/minus /registered/macron/degree/plusminus/twosuperior/threesuperior/acute/mu /paragraph/periodcentered/cedilla/onesuperior/ordmasculine/guilsinglright /onequarter/onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde /Adieresis/Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute /Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls /agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla/egrave/eacute /ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis/eth/ntilde/ograve /oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex /udieresis/yacute/thorn/ydieresis]def/Times-Bold at 0 ENC0/Times-Bold RE/Courier at 0 ENC0/Courier RE/Times-Roman at 0 ENC0/Times-Roman RE/Times-Italic at 0 ENC0 /Times-Italic RE/Helvetica-Oblique at 0 ENC0/Helvetica-Oblique RE/Helvetica-Bold at 0 ENC0/Helvetica-Bold RE/Helvetica at 0 ENC0/Helvetica RE %%EndProlog %%Page: 1 1 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 14/Helvetica-Bold at 0 SF(Eur)281.91 132.954 Q(opean Internet Registr)-.28 E (y).14 E -.56(Po)290.8 149.954 S(licies and Pr).56 E(ocedures)-.28 E -.7(Ve) 389.25 166.954 S -.21(rs).7 G(ion 0.1).21 E/F2 12/Helvetica-Oblique at 0 SF .72 -.36(C. O)271.666 211.954 T -.12(ra).36 G(nge).12 E 3.336(,M)-.18 G 3.336(.K) 343.03 211.954 S(uehne)357.346 211.954 Q 3.336(,D)-.18 G 3.336(.K)405.022 211.954 S(arrenberg)419.698 211.954 Q(Document ID: r)304.24 239.954 Q (ipe-104++).18 E(Obsoletes: r)242.944 253.954 Q(ipe-104, r).18 E(ipe-105, r).18 E(ipe-127, r).18 E(ipe-128).18 E/F3 12/Times-Italic at 0 SF(ABSTRA)323.284 309.954 Q(CT)-.36 E/F4 12/Times-Roman at 0 SF .971(The distrib)255.885 342.154 R .971 (ution of IP address space follo)-.24 F .971(ws the hier)-.3 F(-)-.24 E 3.311 (archical scheme described in RFC1466. F)225.885 356.154 R 3.311(or Europe and) -.18 F 1.41(parts of the surrounding area address space is allocated by)225.885 370.154 R(IAN)225.885 384.154 Q 4.759(At)-.42 G 4.759(ot)263.548 384.154 S 1.76 (he RIPE NCC which acts as a re)277.643 384.154 R 1.76(gional Internet)-.18 F (re)225.885 398.154 Q(gistry)-.18 E 5.438(.A)-.78 G 2.438 (ddress space is allocated by the RIPE NCC to)278.687 398.154 R .915 (local Internet Re)225.885 412.154 R .916 (gistries \(IR\), who assign it to to end users.)-.18 F 1.751 (In this document, we describe the policies and procedures)225.885 426.154 R .375(associated with address space management that must be fol-)225.885 440.154 R(lo)225.885 454.154 Q .974(wed by local IRs. Moreo)-.3 F -.18(ve)-.18 G 1.934 -.48(r, w).18 H 3.973(ep).48 G .973(resent a number of ser)403.22 454.154 R(-) -.24 E 1.168(vices a)225.885 468.154 R -.3(va)-.24 G 1.168 (ilable to local IRs to simplify the tasks associated).3 F (with address space management.)225.885 482.154 Q/F5 12/Helvetica at 0 SF 3.336 (1. Scope)72 538.154 R F4 .419 (This document describes the European Internet re)185.385 570.354 R .419 (gistry system for the distri-)-.18 F -.24(bu)185.385 584.354 S 1.242 (tion of globally unique Internet address space and its operation.).24 F -.18 (Pa)7.243 G(rticu-).18 E 1.476(larly it describes the rules and guidelines go) 185.385 598.354 R -.18(ve)-.18 G 1.476(rning the distrib).18 F 1.476 (ution of this)-.24 F 3.167(address space.)185.385 612.354 R 3.167 (The rules set forth in this document are binding for all)9.167 F (address space allocated and assigned via the RIPE NCC.)185.385 626.354 Q .262 (This document does not describe pri)185.385 654.354 R -.3(va)-.3 G .262 (te Internet address space and multicast).3 F .576(address space.)185.385 668.354 R .576(This document does not describe local additions to the Euro-) 6.576 F .571(pean guidelines.)185.385 682.354 R .571(While pro)6.571 F .57 (viding an o)-.18 F -.18(ve)-.18 G(rvie).18 E 3.57(wa)-.3 G .57 (bout the global Internet re)421.26 682.354 R(g-)-.18 E .397 (istry system this document does not describe allocation and assignment rules) 185.385 696.354 R(used by other re)185.385 710.354 Q(gional re)-.18 E (gistries.)-.18 E 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 276.695(pe-104++.ps P)-.15 F (age 1)-.4 E EP %%Page: 2 2 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Helvetica at 0 SF 3.336(1.1. Ov)72 87.954 R -2.976(er vie)-.3 F(w)-.24 E/F2 12/Times-Roman at 0 SF 1.573 (The main body of this document comprises eight sections, with content as) 185.385 106.154 R(follo)185.385 120.154 Q(ws.)-.3 E .819 (Section 2 \(Internet Address Space and the Internet Re)185.385 148.154 R .819 (gistry System\) de\214nes)-.18 F(dif)185.385 162.154 Q .986 (ferent types of IP address space and their purposes.)-.3 F .986(It e)6.986 F .986(xplains the goals)-.18 F 1.244 (used in assigning such addresses and outlines the hierarchical nature of the) 185.385 176.154 R .666(Internet Re)185.385 190.154 R .665 (gistry system used to achie)-.18 F 1.025 -.18(ve t)-.3 H .665(hese goals.).18 F .665(The important distinc-)6.665 F .496(tion between Pro)185.385 204.154 R .497(vider Aggre)-.18 F -.06(ga)-.18 G .497(table and Pro).06 F .497 (vider Independent address space)-.18 F(is also co)185.385 218.154 Q -.18(ve) -.18 G(red.).18 E 1.302 (In Section 3 \(Address Space Assignment Procedures\), the procedures to be) 185.385 246.154 R(follo)185.385 260.154 Q 2.281(wed by European IP re)-.3 F 2.282(gistries when assigning IP addresses to users.)-.18 F 1.064 (The importance of documentation is stressed, while the v)185.385 274.154 R 1.063(arious elements of)-.3 F .539(information required are e)185.385 288.154 R .539(xplained in detail.)-.18 F(Ne)6.539 E .539 (xt, the criteria and standards)-.18 F .521(of e)185.385 302.154 R -.3(va)-.3 G .521(luation are dealt with.).3 F(Finally)6.521 E 3.521(,t)-.78 G .52 (he actual assignment of address space,)370.779 302.154 R .112(of v)185.385 316.154 R .112(arious kinds, is described, as are the accompan)-.3 F .113 (ying steps which a re)-.18 F(gistry)-.18 E(must tak)185.385 330.154 Q(e.)-.12 E 2.579(Section 4 \(Rules and Guidelines for Allocations\) e)185.385 358.154 R 2.579(xplains ho)-.18 F 5.579(wt)-.3 G 2.579(he RIPE)515.089 358.154 R 2.317 (NCC allocates IP address space to re)185.385 372.154 R 2.318 (gistries in an ef)-.18 F 2.318(\214cient and equitable)-.3 F .805 (manner and ho)185.385 386.154 R 3.805(wt)-.3 G .804 (he status and nature of such allocations are made publicly)273.816 386.154 R -.24(av)185.385 400.154 S(ailable in the RIPE database.)-.06 E 1.589 (Section 5 \(DNS and Re)185.385 428.154 R -.18(ve)-.3 G 1.59 (rse Address Mapping\) documents the role of the).18 F 1.123(RIPE NCC in pro) 185.385 442.154 R 1.122(viding re)-.18 F -.18(ve)-.3 G 1.122(rse dele).18 F -.06(ga)-.18 G 1.122(tion, and e).06 F 1.122(xplains ho)-.18 F 4.122(wr)-.3 G -.18(eg)497.406 442.154 S 1.122(istries can).18 F(manage subsidiary re)185.385 456.154 Q -.18(ve)-.3 G(rse dele).18 E -.06(ga)-.18 G (tion of assigned address space.).06 E 1.79(Section 6 \(Internet Re)185.385 484.154 R 1.79(gistry Operations\) documents operational procedures)-.18 F .937 (of IR. This includes information on starting and closing an IR, communica-) 185.385 498.154 R 1.284(tions, record k)185.385 512.154 R 1.284 (eeping, con\214dentiality)-.12 F 4.284(,a)-.78 G 1.284 (nd policies on IR operations.)377.265 512.154 R(More-)7.285 E -.18(ove)185.385 526.154 S 4.262(rv).18 G 1.262(arious resources and tools for re)216.311 526.154 R 1.261(gistry operation are described in that)-.18 F(section.)185.385 540.154 Q 1.107 (Section 7 \(AS Number Assignment Procedures and Policies\) describes ho) 185.385 568.154 R(w)-.3 E .086(to manage a group of IP netw)185.385 582.154 R .086(orks as an autonomous system.)-.12 F .086(Both the proce-)6.086 F .125 (dural and technical issues in)185.385 596.154 R -.24(vo)-.48 G(lv).24 E .125 (ed in AS number management are described.)-.18 F 1.914 (Section 8 \(Interdomain Routing Considerations\) describes the policies and) 185.385 624.154 R (procedures necessary to originate routes for assigned address space.)185.385 638.154 Q 3.067 -.96(We c)185.385 666.154 T 1.147 (onclude with a glossary in which the k).96 F 1.508 -.18(ey t)-.12 H 1.148 (erms used in this document).18 F(are de\214ned.)185.385 680.154 Q 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 276.695(pe-104++.ps P)-.15 F (age 2)-.4 E EP %%Page: 3 3 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Helvetica at 0 SF 3.336(2. Inter)72 87.954 R (net Address Space and the Inter).3 E(net Registr).3 E 3.336(yS).36 G(ystem) 361.116 87.954 Q 3.336(2.1. T)72 129.954 R(ypes of IP Addresses)-1.44 E/F2 12 /Times-Roman at 0 SF 1.97 (IP addresses for the purposes of this document are 32-bit binary numbers) 185.385 148.154 R 1.668(used as addresses in the IPv4 protocols.)185.385 162.154 R 1.668(There are three main types of IP)7.668 F(addresses)185.385 176.154 Q(Public Addresses)185.385 208.354 Q .607(The public IP addresses mak) 215.385 222.354 R 3.607(eu)-.12 G 3.607(pt)370.604 222.354 S .607 (he Internet address space.)383.547 222.354 R(The)6.606 E 3.606(ya)-.18 G(re) 548.676 222.354 Q .474 (assigned to be globally unique according to the goals described belo)215.385 236.354 R -.78(w.)-.3 G 2.362 (The main purpose of this address space is to allo)215.385 250.354 R 5.361(wc) -.3 G(ommunication)488.664 250.354 Q .271(using IPv4 o)215.385 264.354 R -.18 (ve)-.18 G 3.272(rt).18 G .272(he Internet.)298.172 264.354 R 3.272(As)6.272 G .272(econdary purpose is to allo)375.968 264.354 R 3.272(wc)-.3 G(ommu-)523.332 264.354 Q .099(nication using IPv4 o)215.385 278.354 R -.18(ve)-.18 G 3.099(ri) .18 G .099(nterconnected pri)339.417 278.354 R -.3(va)-.3 G .099(te internets.) .3 F .099(One can cur)6.099 F(-)-.24 E .7(rently distinguish tw)215.385 292.354 R 3.701(ok)-.12 G .701(inds of public addresses: pro)331.043 292.354 R .701 (vider independent)-.18 F 2.615(\(PI\) and pro)215.385 306.354 R 2.615 (vider aggre)-.18 F -.06(ga)-.18 G 2.615(table \(P).06 F 2.615 (A\) addresses; see belo)-1.104 F 5.615(wf)-.3 G 2.615(or more)517.729 306.354 R(details.)215.385 320.354 Q(Pri)185.385 352.554 Q -.3(va)-.3 G(te Addresses).3 E 1.398(Some address ranges ha)215.385 366.554 R 1.759 -.18(ve b)-.24 H 1.399 (een set aside for the operation of pri).18 F -.3(va)-.3 G(te).3 E(netw)215.385 380.554 Q .326(orks using IP)-.12 F 3.326(.A)-1.332 G -.18(ny)316.239 380.554 S .325(one can use these addresses in their pri).18 F -.3(va)-.3 G .325(te net-) .3 F -.12(wo)215.385 394.554 S 3.681(rks without an).12 F 6.681(yr)-.18 G -.18 (eg)322.452 394.554 S 3.682(istration or coordination. Hosts using these).18 F 3.954(addresses can not be reached from the Internet.)215.385 408.554 R -.18 (Fo)9.954 G 6.954(rat).18 G(horough)518.004 408.554 Q(description of pri) 215.385 422.554 Q -.3(va)-.3 G(te address space, please refer to RFC1597.).3 E (Special and Reserv)185.385 454.754 Q(ed Addresses)-.18 E 2.035 (There are a number of address ranges reserv)215.385 468.754 R 2.036 (ed for applications lik)-.18 F(e)-.12 E 1.467 (multicasting. These are described else)215.385 482.754 R 1.467 (where [ref] and are be)-.3 F 1.467(yond the)-.18 F(scope of this document.) 215.385 496.754 Q 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 276.695(pe-104++.ps P)-.15 F (age 3)-.4 E EP %%Page: 4 4 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Helvetica at 0 SF 3.336(2.2. Goals)72 87.954 R(of Pub)3.336 E (lic Address Space Distr)-.24 E(ib).18 E(ution)-.24 E/F2 12/Times-Roman at 0 SF .197 (In the remainder of this document, we are primarily concerned with the man-) 185.385 106.154 R .787 (agement of public Internet address space, as de\214ned in the pre)185.385 120.154 R .786(vious section.)-.3 F(Ev)185.385 134.154 Q 2.109 (ery assignment of Internet addresses must)-.18 F/F3 12/Times-Italic at 0 SF(guar) 5.11 E(antee)-.18 E F2 2.11(that the follo)5.11 F(wing)-.3 E (restriction is met.)185.385 148.154 Q(Uniqueness)185.385 180.354 Q (Each public Internet address w)215.385 194.354 Q(orldwide must be unique.)-.12 E .006(This is an absolute requirement which guarantees that e)185.385 226.554 R -.18(ve)-.3 G .006(ry host on the Inter).18 F(-)-.24 E (net can be uniquely identi\214ed.)185.385 240.554 Q 3.112 (In addition to the uniqueness requirement, public Internet address space) 185.385 268.554 R(assignments should be made with the follo)185.385 282.554 Q (wing three goals in mind.)-.3 E(Aggre)185.385 314.754 Q -.06(ga)-.18 G(tion) .06 E F3 .605(The distrib)215.385 328.754 R .605(ution of public Internet addr) -.24 F .604(esses in a hier)-.444 F(ar)-.18 E -.18(ch)-.444 G .604(ical manner) .18 F(,)-1.332 E .145(permitting the a)215.385 342.754 R -.12(gg)-.12 G -.444 (re).12 G .145(gation of r)-.036 F .146(outing information.)-.54 F F2 .146 (This is necessary to)6.146 F 1.735 (ensure proper operation of Internet routing.)215.385 356.754 R 1.734 (This goal could also be)7.734 F(called)215.385 370.754 Q F3(Routability)3 E F2 (.)A(Conserv)185.385 402.954 Q(ation)-.3 E F3 .774(The fair distrib)215.385 416.954 R .774(ution of public Internet addr)-.24 F .774(ess space accor)-.444 F .775(ding to the)-.444 F(oper)215.385 430.954 Q 3.641 (ational needs of the end user)-.18 F 6.64(so)-.12 G(per)410.916 430.954 Q 3.64 (ating networks using this)-.18 F(addr)215.385 444.954 Q .329(ess space)-.444 F (.)-.18 E F2 .33(In order to maximize the lifetime of the public Internet)6.329 F 2.992(address space resource, addresses must be distrib)215.385 458.954 R 2.991(uted according to)-.24 F(need, and stockpiling must be pre)215.385 472.954 Q -.18(ve)-.3 G(nted.).18 E(Re)185.385 505.154 Q(gistration)-.18 E F3 1.221(The pr)215.385 519.154 R -.12(ov)-.54 G 1.221(ision of a public r).12 F -.48(eg)-.444 G 1.222(istry documenting addr).48 F 1.222(ess space alloca-) -.444 F 1.932(tion and assignment.)215.385 533.154 R F2 1.931 (This is necessary to ensure uniqueness and to)7.931 F(pro)215.385 547.154 Q (vide information for Internet trouble shooting at all le)-.18 E -.18(ve)-.3 G (ls.).18 E .357 (It is in the interest of the Internet community as a whole that the abo) 185.385 579.354 R .717 -.18(ve g)-.18 H(oals).18 E 1.708(are pursued.)185.385 593.354 R 1.708(It is w)7.708 F 1.708(orth noting that "Conserv)-.12 F 1.708 (ation" and "Aggre)-.3 F -.06(ga)-.18 G 1.707(tion" are).06 F .361 (often con\215icting goals, and therefore that each assignment must be e) 185.385 607.354 R -.3(va)-.3 G(luated).3 E(carefully)185.385 621.354 Q 6.061 (.M)-.78 G(oreo)246.982 621.354 Q -.18(ve)-.18 G 1.021 -.48(r, t).18 H .061 (he abo).48 F .42 -.18(ve g)-.18 H .06 (oals may occasionally be in con\215ict with the).18 F .384(interests of indi) 185.385 635.354 R .384(vidual end users or Internet service pro)-.3 F 3.385 (viders. Careful)-.18 F(analy-)3.385 E .027 (sis and judgement are necessary in each indi)185.385 649.354 R .027 (vidual case to \214nd an appropriate)-.3 F 3.514(compromise. The)185.385 663.354 R .514(rules and guidelines in this document are intended to help)3.514 F(Internet re)185.385 677.354 Q (gistries and end users in their search for good compromises.)-.18 E 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 276.695(pe-104++.ps P)-.15 F (age 4)-.4 E EP %%Page: 5 5 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Helvetica at 0 SF 3.336(2.3. The)72 87.954 R -3.036(Inter net)3.336 F -2.976(Registr y)3.336 F(System)3.336 E/F2 12/Times-Roman at 0 SF .125 (The Internet Re)185.385 120.154 R .125 (gistry system has been established to achie)-.18 F .484 -.18(ve t)-.3 H .124 (he abo).18 F .484 -.18(ve s)-.18 H(tated).18 E 7.47(goals. It)185.385 134.154 R 4.47(consists of hierarchically or)7.47 F -.06(ga)-.216 G(nized).06 E/F3 12 /Times-Italic at 0 SF 4.471(Internet Re)7.471 F(gistries)-.48 E F2(\(IRs\).)7.471 E 1.472(Address space is typically assigned to end users by)185.385 148.154 R F3(local)4.472 E F2 1.472(IRs. The address)4.472 F .284(space assigned is tak) 185.385 162.154 R .284(en from that allocated to the local IR by the re)-.12 F .284(gional IR.)-.18 F F3 1.52(End user)185.385 176.154 R(s)-.12 E F2 1.52 (are those or)4.52 F -.06(ga)-.216 G 1.52(nizations operating netw).06 F 1.519 (orks in which the address)-.12 F .479(space is used. The address space may) 185.385 190.154 R 3.479(,h)-.78 G -.3(ow)379.574 190.154 S -2.58 -.3(ev e).3 H 1.439 -.48(r, b).3 H 3.479(er).48 G .48(equested by a consultant)438.912 190.154 R F3(\(r)185.385 204.154 Q(equester\))-.444 E F2 .262 (acting on behalf of the end user)3.263 F 6.262(.L)-.66 G .262 (ocal IRs are typically operated)410.324 204.154 R(by)185.385 218.154 Q F3 1.01 (Internet Service Pr)4.01 F -.12(ov)-.54 G(ider).12 E(s)-.12 E F2 4.011 (\(ISPs\). Local)4.011 F 1.011(IRs hold)4.011 F F3(allocations)4.011 E F2 1.011 (of address)4.011 F .002(space for)185.385 232.154 R F3(assignment)3.002 E F2 .001(to end users.)3.002 F .001(Assigned address space is actually used to) 6.001 F 1.59(operate netw)185.385 246.154 R 1.591 (orks, whereas allocated address space is held by local IRs for)-.12 F .13 (future assignments to end users.)185.385 260.154 R 2.05 -.96(To a)6.13 H(chie) .96 E .49 -.18(ve b)-.3 H .13(oth the conserv).18 F .13(ation and aggre-)-.3 F -.06(ga)185.385 274.154 S (tion goals, only IRs can hold allocations of address space.).06 E F1(IANA)72 316.154 Q F2 2.818(The Internet Assigned Numbers Authority has authority o) 185.385 334.354 R -.18(ve)-.18 G 5.818(ra).18 G 2.818(ll number)508.85 334.354 R .617(spaces used in the Internet.)185.385 348.354 R .617 (This includes IP address space.)6.617 F(IAN)6.616 E 3.616(Aa)-.42 G(llocates) 521.34 348.354 Q 1.553(public Internet address space to re)185.385 362.354 R 1.553(gional IRs according to their established)-.18 F(needs.)185.385 376.354 Q F1(Regional IRs)72 418.354 Q F2(Re)185.385 436.554 Q 2.587 (gional IRs operate in lar)-.18 F 2.586(ge geopolitical re)-.216 F 2.586 (gions such as continents. T)-.18 F(o)-.96 E .595(date, three Re)185.385 450.554 R .595(gional IRs ha)-.18 F .955 -.18(ve b)-.24 H .596 (een established, namely the InterNIC serving).18 F .972 (North America, the AP-NIC serving the Asian P)185.385 464.554 R .972 (aci\214c re)-.18 F .972(gion, and the RIPE)-.18 F 2.003 (NCC serving Europe and surrounding areas.)185.385 478.554 R 2.003 (Since these do not co)8.003 F -.18(ve)-.18 G 5.004(ra).18 G(ll)551.328 478.554 Q 1.81(geographical areas, re)185.385 492.554 R 1.81(gional IRs also serv)-.18 F 4.81(ea)-.18 G 1.81(reas around their core service)409.485 492.554 R 3 (areas. The)185.385 506.554 R(number of re)3 E(gional IRs is e)-.18 E (xpected to remain small.)-.18 E(Re)185.385 534.554 Q 2.061 (gional IRs are established under the Authority of IAN)-.18 F 5.061(A. This) -.42 F(requires)5.061 E 2.232 (consensus within the Internet community of the re)185.385 548.554 R 5.232 (gion. In)-.18 F(particular)5.232 E 5.232(,t)-.48 G(he)546.672 548.554 Q .172 (ISPs in the re)185.385 562.554 R .172(gion under consideration should be in) -.18 F -.24(vo)-.48 G(lv).24 E .173(ed in the process. The)-.18 F 2.169 (duties of a re)185.385 576.554 R 2.169 (gional IR include the coordination and representation of the)-.18 F (local IRs in its re)185.385 590.554 Q(gion.)-.18 E F1(Local IRs)72 632.554 Q F2 .401(Local IRs are established under the authority of a re)185.385 650.754 R .401(gional IR.)-.18 F .401(Local IRs are)6.401 F .962 (typically operated by ISPs and serv)185.385 664.754 R 3.962(et)-.18 G .962 (he customers of those ISPs as well as)372.286 664.754 R 1.207 (the customers of smaller ISPs who are connected to the rest of the Internet) 185.385 678.754 R .297(through the lar)185.385 692.754 R .297(ger ISP)-.216 F 6.297(.O)-1.332 G .297(ther or)309.009 692.754 R -.06(ga)-.216 G .297 (nizations such as lar).06 F .296(ge international Enter)-.216 F(-)-.24 E (prises can also operate local IRs.)185.385 706.754 Q 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 276.695(pe-104++.ps P)-.15 F (age 5)-.4 E EP %%Page: 6 6 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF .229 (Much of this document is concerned with the responsibility of the local IR in) 185.385 87.954 R 2.03 (the assignment process. In some cases, the local IR assigning the address) 185.385 101.954 R .849(space is not run by the ISP that will pro)185.385 115.954 R .849(vide connecti)-.18 F(vity)-.3 E 6.849(.I)-.78 G 3.849(ti)479.109 115.954 S 3.849(si)489.63 115.954 S .849(mportant to)501.483 115.954 R 4.924 (note that maintenance of the administrati)185.385 129.954 R 5.283 -.18(ve i) -.3 H 4.923(nformation re).18 F -.06(ga)-.18 G 4.923(rding the).06 F .898 (assigned address space is the responsibility of the IR that mak)185.385 143.954 R .899(es the assign-)-.12 F 1.051(ment, and not of the ISP pro)185.385 157.954 R 1.051(viding the connecti)-.18 F(vity)-.3 E 7.051(.F)-.78 G 1.05 (urthermore, only IRs)455.58 157.954 R(can hold address allocations.)185.385 171.954 Q/F2 12/Helvetica at 0 SF(End-Users)72 213.954 Q F1 .496 (Strictly speaking end users are not part of the IR system.)185.385 232.154 R (The)6.496 E 3.496(yd)-.18 G .496(o, ho)502.448 232.154 R(we)-.3 E -.18(ve)-.3 G -.48(r,).18 G 1.567 (play an important role with respect to the goals de\214ned abo)185.385 246.154 R -.18(ve)-.18 G 4.566(.I).18 G 4.566(no)508.212 246.154 S 1.566(rder to) 524.778 246.154 R(achie)185.385 260.154 Q 1.389 -.18(ve t)-.3 H 1.029 (he conserv).18 F 1.029(ation goal, for e)-.3 F 1.029 (xample, end users should plan their net-)-.18 F -.12(wo)185.385 274.154 S 2.117(rks to use a minimum amount of address space.).12 F(The)8.116 E 5.116(ym) -.18 G 2.116(ust document)491.552 274.154 R 1.329(their addressing and deplo) 185.385 288.154 R 1.329(yment plans to the IR and furnish an)-.12 F 4.329(ya) -.18 G(dditional)515.328 288.154 Q .711 (information required by the IR for making assignment decisions. T)185.385 302.154 R 3.71(oa)-.96 G(chie)527.16 302.154 Q -.18(ve)-.3 G .355(the aggre) 185.385 316.154 R -.06(ga)-.18 G .355 (tion goal, an end user should choose an appropriate local IR. End).06 F .424 (users should be a)185.385 330.154 R -.12(wa)-.18 G .423 (re that changing ISPs may require replacing addresses in).12 F 1.113 (their netw)185.385 344.154 R 4.114(orks. Finally)-.12 F 1.114 (end users must pro)4.114 F 1.114(vide and update re)-.18 F 1.114 (gistration data)-.18 F(for the address space assigned to them.)185.385 358.154 Q F2(Requesters)72 400.154 Q F1 1.902(In addition to these k)185.385 418.354 R 2.261 -.18(ey p)-.12 H 1.901(layers in the Internet Re).18 F 1.901 (gistry System, there are)-.18 F .315 (often consultants who setup and manage netw)185.385 432.354 R .316 (orks for end users. The consul-)-.12 F .437 (tants may be the people actually submitting a request for address space to an) 185.385 446.354 R .292(IR on behalf of an end user)185.385 460.354 R 3.292(.W) -.66 G 3.292(er)333.768 460.354 S .292 (efer to the person making the request for an)346.384 460.354 R .354 (end user as a requester)185.385 474.354 R 3.353(,w)-.48 G .353 (hether that person is emplo)309.961 474.354 R .353(yed by the or)-.12 F -.06 (ga)-.216 G(nization,).06 E .918(or is simply acting on behalf of the or) 185.385 488.354 R -.06(ga)-.216 G .919(nization with respect to the address).06 F(space request.)185.385 502.354 Q -.18(Fo)185.385 548.554 S 3.638(rE).18 G .638(urope, the Internet Re)212.843 548.554 R .638(gistry System hierarch)-.18 F 3.637(yc)-.06 G .637(onsists of the follo)443.385 548.554 R(wing)-.3 E 4.427 (entities \(from the top do)185.385 562.554 R 4.427(wn\): IAN)-.3 F 4.427 (A, the RIPE NCC, Local IRs. See)-.42 F(Appendix A the area co)185.385 576.554 Q -.18(ve)-.18 G(red by the RIPE NCC.).18 E F2 3.336(2.4. Pro)72 618.554 R (vider Independent vs Pro)-.18 E(vider Agg)-.18 E(regatab)-.12 E(le Addresses) -.24 E(Pro)72 650.754 Q(vider Agg)-.18 E(regatab)-.12 E(le Address Space)-.24 E F1 3.638(Local IRs operated by Internet service pro)185.385 668.954 R 3.637 (viders are allocated Pro)-.18 F(vider)-.18 E(Aggre)185.385 682.954 Q -.06(ga) -.18 G .898(table \(P).06 F .898(A\) address space which the)-1.104 F 3.898(ya) -.18 G .898(ssign to their end users.)413.181 682.954 R(This)6.899 E .62 (is done in such a w)185.385 696.954 R .619 (ay that routing information for man)-.12 F 3.619(ye)-.18 G .619 (nd users of an ISP)468.2 696.954 R 2.311(can be aggre)185.385 710.954 R -.06 (ga)-.18 G 2.312(ted on the borders of the pro).06 F(vider')-.18 E 5.312(sr) -.66 G 2.312(outing domain.)453.368 710.954 R(This)8.312 E 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 276.695(pe-104++.ps P)-.15 F (age 6)-.4 E EP %%Page: 7 7 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF -.12(ke)185.385 87.954 S .399 (eps the number of routes and state changes in the interdomain routing sys-).12 F 1.675(tem \(between pro)185.385 101.954 R 1.676(viders\) at an acceptable le) -.18 F -.18(ve)-.3 G 4.676(l. The).18 F 1.676(cost of propag)4.676 F 1.676 (ating a)-.06 F(relati)185.385 115.954 Q -.18(ve)-.3 G .087 (ly small number of aggre).18 F -.06(ga)-.18 G .086(ted routes is much lo).06 F .086(wer than that of prop-)-.3 F(ag)185.385 129.954 Q 1.409 (ating each end user')-.06 F 4.41(si)-.66 G(ndi)308.934 129.954 Q 1.41 (vidual routes throughout the entire interdomain)-.3 F(routing system.)185.385 143.954 Q .545(If an end user changes service pro)185.385 171.954 R .545 (viders, their P)-.18 F 3.545(Aa)-1.104 G .545(ddress space will ha)436.266 171.954 R .904 -.18(ve t)-.24 H(o).18 E .409 (be replaced. As a consequence, all hosts and routers at the end user')185.385 185.954 R 3.41(so)-.66 G -2.628 -.216(rg a)529.62 185.954 T(ni-).216 E 2.162 (zation will ha)185.385 199.954 R 2.521 -.18(ve t)-.24 H 5.161(ob).18 G 5.161 (er)291.603 199.954 S 5.161(econ\214gured. The)306.088 199.954 R 2.161 (end user will need to obtain an)5.161 F .486 (assignment from the local IR run by the ne)185.385 213.954 R 3.486(ws)-.3 G .486(ervice pro)411.096 213.954 R(vider)-.18 E 3.486(,a)-.48 G .486 (nd return the)495.708 213.954 R(pre)185.385 227.954 Q 2.581 (viously assigned address space to the local IR run by the old service)-.3 F (pro)185.385 241.954 Q(vider)-.18 E 3.335(.T)-.66 G 3.335(oe)237.908 241.954 S .335(nsure the address space is properly returned, a clear)252.571 241.954 R 3.336(,p)-.48 G(referably)514.692 241.954 Q 2.024 (contractual, understanding is needed between the service pro)185.385 255.954 R 2.024(vider and the)-.18 F .029(end user)185.385 269.954 R 3.029(.T)-.66 G .029 (he agreement should state that the assignment of the address space)238.435 269.954 R 1.087(becomes in)185.385 283.954 R -.3(va)-.48 G 1.087 (lid when the pro).3 F 1.087(vider no longer pro)-.18 F 1.087 (vides Internet connecti)-.18 F(vity)-.3 E (to the end user or shortly thereafter)185.385 297.954 Q(.)-.66 E .076 (The goal of this arrangement is to minimize the load on the interdomain rout-) 185.385 325.954 R .368(ing system.)185.385 339.954 R .368 (If the end user continued to use P)6.368 F 3.367(Aa)-1.104 G .367 (ddress space obtained from)425.931 339.954 R .797(their pre)185.385 353.954 R .797(vious service pro)-.3 F .798(vider when connecting to another service pro) -.18 F(vider)-.18 E(,)-.48 E .122(their routing information could not be aggre) 185.385 367.954 R -.06(ga)-.18 G .121(ted and w).06 F .121(ould ha)-.12 F .481 -.18(ve t)-.24 H 3.121(ob).18 G 3.121(ep)523.559 367.954 S(rop-)538.008 367.954 Q(ag)185.385 381.954 Q (ated separately throughout the whole interdomain routing system.)-.06 E/F2 12 /Helvetica at 0 SF(Pro)72 423.954 Q(vider Independent Address Space)-.18 E F1 .856 (In contrast to P)185.385 442.154 R 3.856(Aa)-1.104 G .856 (ddress space, PI address space can remain assigned to its)277.692 442.154 R .719(user as long as the criteria for the original assignment are met. The dur\ ation)185.385 456.154 R 1.925 (of the assignment is independent of the use of a particular pro)185.385 470.154 R(vider')-.18 E 4.926(ss)-.66 G(er)544.92 470.154 Q(-)-.24 E 3.77 (vices. The)185.385 484.154 R .769(apparent adv)3.77 F .769 (antage of PI address space is that a user')-.3 F 3.769(sh)-.66 G .769 (osts and)518.231 484.154 R 3.731 (routers need not be recon\214gured if the user decides to change service) 185.385 498.154 R(pro)185.385 512.154 Q 3.681(viders. Ho)-.18 F(we)-.3 E -.18 (ve)-.3 G 1.641 -.48(r, P).18 H 3.681(Ia).48 G .681(ddresses are e)309.288 512.154 R(xpensi)-.18 E 1.041 -.18(ve t)-.3 H 3.681(or).18 G .681 (oute because no use can)439.98 512.154 R 1.462(be made of aggre)185.385 526.154 R -.06(ga)-.18 G 1.462 (tion. All early Internet address space assignments were).06 F(pro)185.385 540.154 Q .07(vider independent. Man)-.18 F 3.07(ya)-.18 G .07 (ssignments made by local IRs are also formally)329.871 540.154 R(pro)185.385 554.154 Q .684 (vider independent due to a lack of prior agreements between ISP and the)-.18 F (end user that the assignment will be terminated when the service is.)185.385 568.154 Q F2 -.84(Va)72 610.154 S(lidity of assignment).84 E F1 1.448 (Assignments of an)185.385 628.354 R 4.448(yk)-.18 G 1.448 (ind of address space are v)293.877 628.354 R 1.447 (alid as long as the original)-.3 F .006(criteria on which the assignment w) 185.385 642.354 R .007(as based are still v)-.12 F 3.007(alid. If)-.3 F .007 (an assignmnet is)3.007 F 1.502 (made for a speci\214c purpose and the purpose does no longer e)185.385 656.354 R 1.502(xist, also the)-.18 F .828(assignment is no longer v)185.385 670.354 R .828(alid. If an assignment is based on information that)-.3 F (turns out to be in)185.385 684.354 Q -.3(va)-.48 G(lid so is the assignment.) .3 E 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 276.695(pe-104++.ps P)-.15 F (age 7)-.4 E EP %%Page: 8 8 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Helvetica at 0 SF 3.336(3. Address)72 87.954 R(Space Assignment Procedures) 3.336 E 3.336(3.1. Introduction)72 129.954 R/F2 12/Times-Roman at 0 SF .538 (In this section, we describe the procedures to be follo)185.385 162.154 R .537 (wed by local IRs when)-.3 F 2.386(assigning address space to their users. W) 185.385 176.154 R 5.386(es)-.96 G 2.387(tart with a description of the)410.419 176.154 R 2.067(information to be g)185.385 190.154 R 2.067 (athered from the user)-.06 F 5.066(.T)-.66 G 2.066 (he purpose of the information)407.092 190.154 R -.06(ga)185.385 204.154 S 3.361(thering is tw).06 F 3.362 (ofold. First, the information is required to mak)-.12 F 6.362(ea)-.12 G (ddress)527.34 204.154 Q .171(assignment decisions, with respect to the aggre) 185.385 218.154 R -.06(ga)-.18 G .171(tion and conserv).06 F .171(ation goals.) -.3 F(Second, the information is required for re)185.385 232.154 Q (gistration purposes.)-.18 E 4.362 -.96(We g)185.385 264.354 T 5.442(oo).96 G 5.442(nt)229.965 264.354 S 5.442(od)244.743 264.354 S 2.442(escribe ho)262.185 264.354 R 5.442(wt)-.3 G 2.442(his information should be e)330.753 264.354 R -.3(va)-.3 G 2.443(luated to mak).3 F(e)-.12 E .291 (appropriate assignments, and introduce additional considerations that may be) 185.385 278.354 R .606 (essential in the assignment decision. Finally we specify the procedures to be) 185.385 292.354 R(follo)185.385 306.354 Q(wed in the assignment process.)-.3 E 1.038(Before going into the f)185.385 334.354 R 1.037 (actors in the assignment process, we start with some)-.12 F 1.001 (general background information and policies that determine the information) 185.385 348.354 R(to be g)185.385 362.354 Q (athered, and the procedures to be follo)-.06 E(wed.)-.3 E .645 (Address space is assigned by IRs to end users who use it to operate the spe-) 185.385 390.354 R 1.074(ci\214c netw)185.385 404.354 R 1.075 (orks described in an address space request.)-.12 F 1.075 (IRs guarantee that no)7.075 F .46 (other end user will be assigned the same address space during the v)185.385 418.354 R .459(alidity of)-.3 F .685(the assignment.)185.385 432.354 R .686 (An assignment is v)6.686 F .686(alid as long as the criteria on which it is) -.3 F(based remain v)185.385 446.354 Q(alid.)-.3 E 2.515 (In accordance with the conserv)185.385 474.354 R 2.515 (ation goal, end users are not permitted to)-.3 F(reserv)185.385 488.354 Q 3.29 (ea)-.18 G .29(ddress space. Ev)228.467 488.354 R .291 (aluation of IP address space requests must be based)-.3 F 1.072 (on the documentation pro)185.385 502.354 R 1.072(vided for the follo)-.18 F 1.071(wing 24 months, as speci\214ed in)-.3 F .296 (the addressing plan and the current address space usage described in the ne) 185.385 516.354 R(xt)-.18 E .082(section. The amount of address space assigned\ must be justi\214ed by this docu-)185.385 530.354 R .249 (mentation. This means that address space assigned in the past should be used) 185.385 544.354 R 1.858(to meet the current request if possible.)185.385 558.354 R 1.857(Once an or)7.857 F -.06(ga)-.216 G 1.857(nization has used its) .06 F 1.216 (assigned address space, it can request additional address space based on an) 185.385 572.354 R(updated estimate of gro)185.385 586.354 Q(wth in its netw)-.3 E(ork.)-.12 E F1 3.336(3.2. Documentation)72 628.354 R F2 4.604 -.96(To m) 185.385 660.554 T(ak).96 E 5.684(ea)-.12 G 2.684 (ppropriate assignment decisions, information must be g)240.325 660.554 R (athered)-.06 E .667(about the or)185.385 674.554 R -.06(ga)-.216 G .667 (nization, addressing requirements, netw).06 F .668(ork infrastructure, cur) -.12 F(-)-.24 E .476 (rent address space usage, and future plans of the end user requesting address) 185.385 688.554 R 6.431(space. Some)185.385 702.554 R 3.431 (information is essential to the assignment process, and is)6.431 F 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 276.695(pe-104++.ps P)-.15 F (age 8)-.4 E EP %%Page: 9 9 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF 1.47(formally required by the IR')185.385 87.954 R 1.47 (s. Other information is v)-.66 F 1.469(ery helpful in making)-.18 F .807 (assignment decisions, b)185.385 101.954 R .807(ut is not strictly required.) -.24 F .808(The Local IR must assure)6.808 F .369 (that the required information is complete before proceeding with the request.) 185.385 115.954 R -.18(Fo)185.385 143.954 S 5.582(rg).18 G 2.582 (athering the required information, the RIPE NCC pro)213.395 143.954 R 2.583 (vides a set of)-.18 F .109(forms and a set of instructions to \214ll them in.) 185.385 157.954 R .109(Although use of the forms pro-)6.109 F .964 (vided \(or a local-language equi)185.385 171.954 R -.3(va)-.3 G .964 (lent\) is strongly encouraged, each local IR).3 F .134 (can obtain and manage this information as it considers appropriate.)185.385 185.954 R(Requests)6.133 E 1.41(requiring e)185.385 199.954 R -.3(va)-.3 G 1.411(luation by the NCC must, ho).3 F(we)-.3 E -.18(ve)-.3 G 2.371 -.48(r, b) .18 H 4.411(es).48 G 1.411(ubmitted on a current)450.783 199.954 R -.18(ve) 185.385 213.954 S(rsion of the "IP Address Space Request F).18 E(orm".)-.18 E .498(The information g)185.385 241.954 R .497 (athered in the assignment process must be maintained per)-.06 F(-)-.24 E .373 (manently by the IR making the assignment.)185.385 255.954 R .373 (It must be made a)6.373 F -.3(va)-.24 G .374(ilable to the).3 F .986 (parent re)185.385 269.954 R .985 (gistry immediately upon request. The IR is responsible for protect-)-.18 F .381(ing the end user')185.385 283.954 R 3.381(sp)-.66 G(ri)280.233 283.954 Q -.3(va)-.3 G -.18(cy).3 G 3.381(.A)-.6 G .381 (side from the data speci\214ed in Section \(database)323.706 283.954 R 2.726 (information\) belo)185.385 297.954 R 4.286 -.78(w, w)-.3 H 2.726 (hich is published in the re).78 F 2.725(gistry database, the data)-.18 F -.06 (ga)185.385 311.954 S .911(thered must be k).06 F .911 (ept in strict con\214dence.)-.12 F .912(The IR is not authorized to pro-)6.911 F(vide the information to an)185.385 325.954 Q (yone not representing the parent re)-.18 E(gistry)-.18 E(.)-.78 E .345 (In the subsections that follo)185.385 353.954 R 1.905 -.78(w, w)-.3 H 3.345 (eo).78 G .344(utline the speci\214c data to be g)356.691 353.954 R .344 (athered and)-.06 F(the reasons for doing so.)185.385 367.954 Q/F2 12 /Helvetica at 0 SF 3.336(3.2.1. Required)72 409.954 R(Inf)3.336 E -3.036 (or mation)-.36 F F1 .58(The follo)185.385 442.154 R .58 (wing set of information must be pro)-.3 F .58(vided with e)-.18 F -.18(ve)-.3 G .581(ry request for an).18 F 5.331 (address assignment. The data is essential both to properly assigning)185.385 456.154 R 2.346(addresses and to maintaining a global o)185.385 470.154 R -.18 (ve)-.18 G(rvie).18 E 5.346(wo)-.3 G 5.347(fa)438.111 470.154 S 2.347 (ssignments. W)452.782 470.154 R 2.347(ith the)-.48 F -.18(ex)185.385 484.154 S 3.244 (ception of the information speci\214ed in Section \(current address space).18 F(usage\), all information refers to the currently requested address space.) 185.385 498.154 Q F2 3.336(3.2.1.1. Ov)72 540.154 R -2.976(er vie)-.3 F 3.336 (wo)-.24 G 3.336(fO)178.536 540.154 S(rganization)194.544 540.154 Q F1 3.826 -.96(To p)185.385 572.354 T 1.906(roperly assess the user').96 F 4.906(sa)-.66 G 1.906(ddress space requirements, it is essential to)340.259 572.354 R .483 (understand the structure of the or)185.385 586.354 R -.06(ga)-.216 G .482 (nization to which the addresses are being).06 F (assigned, and which part of the or)185.385 600.354 Q -.06(ga)-.216 G (nization will mak).06 E 3(eu)-.12 G(se of the addresses.)456.945 600.354 Q 1.324(Consider the follo)185.385 628.354 R 1.324(wing situation. A bic)-.3 F 1.324(ycle manuf)-.18 F 1.325(acturer based in Belgium)-.12 F 2.246(has a v) 185.385 642.354 R 2.245(ariety of departments. Some, such as the)-.3 F/F3 12 /Times-Italic at 0 SF -2.22 -.66(Fr o)5.245 H 2.245(nt F).66 F(ork)-1.26 E F1(and) 5.245 E F3(Der)5.245 E(ailer)-.18 E F1 1.224 (departments, specialize in speci\214c bik)185.385 656.354 R 4.224(ep)-.12 G 1.224(arts. Others, such as the)388.017 656.354 R F3(Sales)4.225 E F1(and)4.225 E F3(De)185.385 670.354 Q(velopment)-.18 E F1 .018 (departments are more general by nature. In such a compan)3.018 F 1.577 -.78 (y, t)-.18 H(he).78 E .675(departments Sales, De)185.385 684.354 R -.18(ve)-.3 G .675(lopment, and Manuf).18 F .675(acturing may f)-.12 F .676 (all directly under)-.12 F 2.476 (the top management, whereas the subdepartments)185.385 698.354 R F3(Der)5.475 E(ailer)-.18 E 5.475(,C)-1.332 G 2.475(hain, P)498.153 698.354 R(edal,)-.96 E F1(and)185.385 712.354 Q F3 -2.22 -.66(Fr o)3.303 H .304(nt F).66 F(ork)-1.26 E F1 -.12(fa)3.304 G .304(ll under the Manuf).12 F .304 (acturing department. If someone submits)-.12 F 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 276.695(pe-104++.ps P)-.15 F (age 9)-.4 E EP %%Page: 10 10 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF 4.746(ar)185.385 87.954 S 1.745 (equest for address space, we must kno)199.455 87.954 R 4.745(ww)-.3 G 1.745 (hich part of the or)415.324 87.954 R -.06(ga)-.216 G(nization).06 E .149 (will mak)185.385 101.954 R 3.149(eu)-.12 G .15 (se of the assigned addresses. Suppose, for e)242.227 101.954 R .15 (xample, the)-.18 F/F2 12/Times-Italic at 0 SF(Manufac-)3.15 E(turing)185.385 115.954 Q F1 1.899(department is assigned address space for use by all bik)4.9 F 4.899(ep)-.12 G 1.899(arts sub-)515.109 115.954 R 5.604(departments. If) 185.385 129.954 R 2.604(shortly thereafter)5.604 F 5.604(,t)-.48 G(he)365.613 129.954 Q F2(Chain)5.604 E F1 2.605(department requests address)5.605 F .973 (space it is important that we kno)185.385 143.954 R 3.972(wa)-.3 G 3.972(na) 364.872 143.954 S .972(ssignment has already been made to)380.172 143.954 R 1.291(the or)185.385 157.954 R -.06(ga)-.216 G 1.291(nization to meet the).06 F F2(Chain)4.291 E F1(department')4.292 E 4.292(sn)-.66 G 4.292(eeds. A)434.46 157.954 R 1.292(similar situation)4.292 F 1.636(may occur if the)185.385 171.954 R F2(Sales)4.636 E F1 1.635(department has groups of representati)4.636 F -.18(ve)-.3 G 4.635(si).18 G 4.635(ns)513.861 171.954 S -2.58 -.3(ev e) 529.164 171.954 T(ral).3 E 3.748(countries. It)185.385 185.954 R .748 (is essential to kno)3.748 F 3.748(wi)-.3 G 3.748(fa)353.565 185.954 S .749 (ddresses being requested by the central)366.637 185.954 R(of)185.385 199.954 Q .246(\214ce will be used in Antwerp or in Madrid. W)-.3 F 3.246(ew)-.96 G .245 (ant to pre)430.089 199.954 R -.18(ve)-.3 G .245(nt assignments).18 F .363 (being made for the same subnet by tw)185.385 213.954 R 3.363(od)-.12 G(if) 385.473 213.954 Q .363(ferent parts of the or)-.3 F -.06(ga)-.216 G .363 (nization. In).06 F .015(the case of a distrib)185.385 227.954 R .015 (uted sales department, this must also be kno)-.24 F .014(wn to assure a)-.3 F (proper assignment with respect to aggre)185.385 241.954 Q -.06(ga)-.18 G (tion.).06 E .637 (The person responsible for making the assignment can only be a)185.385 269.954 R -.12(wa)-.18 G .638(re of this).12 F .108(situation if an o)185.385 283.954 R -.18(ve)-.18 G(rvie).18 E 3.107(wo)-.3 G 3.107(ft)307.808 283.954 S .107(he or) 318.247 283.954 R -.06(ga)-.216 G .107(nization, and the requester').06 F 3.107 (sr)-.66 G .107(ole therein is)495.794 283.954 R(kno)185.385 297.954 Q 1.448 (wn. It is therefore important that a brief o)-.3 F -.18(ve)-.18 G(rvie).18 E 4.448(wo)-.3 G 4.448(ft)462.068 297.954 S 1.448(he or)473.848 297.954 R -.06 (ga)-.216 G(nizational).06 E 2.014(structure be pro)185.385 311.954 R 5.014 (vided. This)-.18 F 2.014(should include details of the parent compan)5.014 F -.78(y,)-.18 G(subsidiaries and contact persons.)185.385 325.954 Q 1.619 (In the case of our bic)185.385 353.954 R 1.619(ycle manuf)-.18 F(acturer)-.12 E 4.619(,o)-.48 G 1.619(ne w)395.87 353.954 R 1.619(ould e)-.12 F 1.62 (xpect someone repre-)-.18 F .134(senting the)185.385 367.954 R F2(Chain)3.134 E F1 .133(department to produce general information about the struc-)3.134 F .471(ture of the or)185.385 381.954 R -.06(ga)-.216 G .472 (nization in Belgium, and contact persons for the).06 F F2(Manufactur)3.472 E (-)-.24 E(ing)185.385 395.954 Q 3.045(,S)-.12 G(ales,)212.646 395.954 Q F1(and) 3.045 E F2(De)3.045 E(velopment)-.18 E F1 .045(departments. W)3.045 F 3.045(ew) -.96 G .045(ould not e)416.559 395.954 R .045(xpect the same per)-.18 F(-)-.24 E .362(son to present information on the structure within the)185.385 409.954 R F2(Sales)3.363 E F1 .363(department, such)3.363 F(as who manages the of)185.385 423.954 Q(\214ce in Rome.)-.3 E(Clearly)185.385 451.954 Q 3.763(,t)-.78 G .762 (he assignment process is greatly simpli\214ed if an or)230.032 451.954 R -.06 (ga)-.216 G .762(nization coor).06 F(-)-.24 E .72 (dinates its address space management, and if all requests are made by a sin-) 185.385 465.954 R(gle body representing the entire or)185.385 479.954 Q -.06 (ga)-.216 G(nization.).06 E/F3 12/Helvetica at 0 SF(Contact P)72 521.954 Q(ersons) -.6 E F1 2.285 -.96(To f)185.385 554.154 T .365 (acilitate handling the request, contact information is required for the per) .84 F(-)-.24 E 2.023(son making the request and for someone at the or)185.385 568.154 R -.06(ga)-.216 G 2.024(nization to which the).06 F 1.729 (address space will be assigned.)185.385 582.154 R 1.728 (The information should be entered on the)7.728 F F2(Requester)185.385 596.154 Q F1(and)3.451 E F2(User)3.452 E F1 .452(contact templates, respecti)3.452 F -.18(ve)-.3 G(ly).18 E 6.452(.T)-.78 G .452(hese templates contain)448.448 596.154 R F2(name)185.385 610.154 Q 4.401(,o)-.12 G -.444(rg)224.658 610.154 S 1.401(anization, country).444 F 4.401(,p)-.66 G(hone)336.36 610.154 Q 4.401(,f) -.12 G(ax-no,)370.305 610.154 Q F1(and)4.401 E F2(e-mail)4.401 E F1 1.4 (\214elds. In each tem-)4.401 F .904(plate, the appropriate person')185.385 624.154 R 3.904(sn)-.66 G .905(ame should be speci\214ed in full. The or) 342.637 624.154 R -.06(ga)-.216 G(ni-).06 E .224 (zation refers to that in which this person w)185.385 638.154 R .224 (orks, and the country refers to that)-.12 F 2.857(in which the person')185.385 652.154 R 5.857(so)-.66 G -.3<668c>308.137 652.154 S 2.857(ce is located.).3 F 2.858(The telephone and f)8.857 F 2.858(ax numbers)-.12 F .632 (should include the country pre\214x)185.385 666.154 R .632(es in the form)-.18 F F2(+code)3.632 E(,)-.12 E F1 .631(and if the person can)3.631 F (be reached by e-mail from the Internet, the address should be speci\214ed.) 185.385 680.154 Q 2.613(The contact person information is only collected to f) 185.385 708.154 R 2.613(acilitate the address)-.12 F 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 10)-.4 E EP %%Page: 11 11 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF 1.216 (space request. It may or may not include data for persons that will later be) 185.385 87.954 R(entered in the RIPE database.)185.385 101.954 Q/F2 12 /Helvetica at 0 SF 3.336(3.2.1.2. Current)72 143.954 R(Assignment Space Usage) 3.336 E F1 2.921 -.96(To m)185.385 176.154 T 1.001(eet the conserv).96 F 1.002 (ation goal in address space assignments, one must ha)-.3 F -.18(ve)-.24 G .235 (information re)185.385 190.154 R -.06(ga)-.18 G .235 (rding address space assignments made to the user in the past).06 F .276 (before ne)185.385 204.154 R 3.276(wa)-.3 G .276(ddress space can be assigned.) 247.605 204.154 R 3.276(Ad)6.276 G .277(etailed description of ho)414.549 204.154 R 3.277(wt)-.3 G(he)546.672 204.154 Q .304 (address space is currently being used is required.)185.385 218.154 R .303 (Using this information, we)6.303 F 1.204(can pre)185.385 232.154 R -.18(ve)-.3 G 1.204(nt assigning ne).18 F 4.204(wa)-.3 G 1.205 (ddress space, where already assigned addresses)324.721 232.154 R(can be emplo) 185.385 246.154 Q(yed to meet the user')-.12 E 3(sn)-.66 G(eeds.)362.901 246.154 Q .726(Each set of addresses already assigned to the or)185.385 274.154 R -.06(ga)-.216 G .725(nization must therefore be).06 F 1.086 (reported. The current use of these addresses must be documented in a table) 185.385 288.154 R .152(similar to that belo)185.385 302.154 R 4.711 -.78(w. A) -.3 H 3.151(ne).78 G .151(ntry must be included for each ph)316.055 302.154 R .151(ysically separate)-.06 F .017(subnet in the user')185.385 316.154 R 3.018 (sn)-.66 G(etw)286.782 316.154 Q .018(ork. Subnets are considered to be ph)-.12 F .018(ysically separate)-.06 F .854(if there is an IP router between them.) 185.385 330.154 R .854(Each ro)6.854 F 3.854(wi)-.3 G 3.854(nt)429.569 330.154 S .854(he table belo)442.759 330.154 R 3.853(wc)-.3 G(ontains)523.332 330.154 Q (an entry for a subnet in the end user')185.385 344.154 Q 3(so)-.66 G -2.628 -.216(rg a)374.349 344.154 T(nization.).216 E/F3 8/Courier at 0 SF(Addresses Used) 372.585 379.154 Q 38.4(Prefix Subnet)185.385 393.154 R 24(Mask Size)4.8 F (Current 1yr 2yr)9.6 E(Description)454.185 393.154 Q 14.4 (193.1.193.0 255.255.255.192 64)185.385 421.154 R 4.8(28 34 50)391.785 421.154 R(Derailer)454.185 421.154 Q 9.6(193.1.193.64 255.255.255.224)185.385 435.154 R 28.8(32 10)348.585 435.154 R 4.8(12 15)9.6 F(Chain)454.185 435.154 Q 9.6 (193.1.193.96 255.255.255.224)185.385 449.154 R 33.6(32 8)348.585 449.154 R 4.8 (13 17)9.6 F(Front Fork)454.185 449.154 Q 91.2(193.1.193.128 128 Unused)185.385 463.154 R 14.4(193.1.194.0 255.255.255.0)185.385 477.154 R 24(256 132)343.785 477.154 R(170 210)4.8 E(Frame)454.185 477.154 Q 14.4(193.1.195.0 255.255.254.0) 185.385 491.154 R 24(512 317)343.785 491.154 R(350 380)4.8 E(Assembly)454.185 491.154 Q 24(1024 495)335.385 519.154 R(579 672)4.8 E(Totals)455.385 519.154 Q F1 .619(Each entry in the table abo)185.385 554.154 R .979 -.18(ve i)-.18 H 3.619(sm).18 G .619(ade up of the follo)352.33 554.154 R .619 (wing \214elds which spec-)-.3 F 2.028 (ify the current and projected use of the address space in the subnet.)185.385 568.154 R(The)8.028 E/F4 12/Times-Italic at 0 SF(Description)185.385 582.154 Q F1 3.088(\214eld is used to specify a short b)6.087 F 3.088 (ut semantically meaningful)-.24 F .805 (description of the role of the subnet in the user')185.385 596.154 R 3.805(so) -.66 G -2.628 -.216(rg a)434.073 596.154 T .805(nization. In our e).216 F(xam-) -.18 E .414(ple, we ha)185.385 610.154 R .774 -.18(ve d)-.24 H .414 (escriptions corresponding to v).18 F .414(arious bik)-.3 F 3.415(ep)-.12 G 3.415(arts. T)464.146 610.154 R .415(ogether with)-.96 F .449 (the size information, this pro)185.385 624.154 R .449 (vides signi\214cant insight as to the netw)-.18 F .448(ork struc-)-.12 F (ture in the or)185.385 638.154 Q -.06(ga)-.216 G(nization.).06 E 1.538 (The number of netw)185.385 666.154 R 1.538(ork interf)-.12 F 1.539 (aces currently used in the subnet, along with)-.12 F .118(the number e)185.385 680.154 R .118(xpected to be needed in the coming one and tw)-.18 F 3.117(oy) -.12 G .117(ears must also)489.774 680.154 R 1.574 (be speci\214ed. These numbers are to be entered in the)185.385 694.154 R F4 (Curr)4.574 E 1.574(ent, 1yr)-.444 F(,)-1.332 E F1(and)4.574 E F4(2yr)4.575 E F1 .337(\214elds of the subnet entry)185.385 708.154 R 3.336(,a)-.78 G .336 (nd include the number of netw)316.272 708.154 R .336(ork interf)-.12 F .336 (aces to be)-.12 F 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 11)-.4 E EP %%Page: 12 12 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF .083(used, such as those for hosts, routers, g)185.385 87.954 R(ate)-.06 E -.12(wa)-.3 G .083(ys, terminal concentrators, print-).12 F (ers, and an)185.385 101.954 Q 3(yo)-.18 G (ther machines requiring one or more netw)251.853 101.954 Q(ork interf)-.12 E (aces.)-.12 E(The)185.385 129.954 Q/F2 12/Times-Italic at 0 SF(Size)3.596 E F1 .595(\214eld is used to specify the size of the subnet, which determines the) 3.595 F .66(maximum number of netw)185.385 143.954 R .66(ork interf)-.12 F .66 (aces that can be incorporated in the sub-)-.12 F .445(net. It must be a po) 185.385 157.954 R .445(wer of tw)-.3 F .445 (o, and of course should be greater than or equal)-.12 F .403 (to the number speci\214ed in the)185.385 171.954 R F2(2yr)3.403 E F1 .403 (\214eld. If it is smaller)3.403 F 3.403(,t)-.48 G .403(his may be the moti-) 457.724 171.954 R -.3(va)185.385 185.954 S .484 (tion for the address request, or it may be a mistak).3 F 3.483(ei)-.12 G 3.483 (nt)450.243 185.954 S .483(he requester')463.062 185.954 R 3.483(sp)-.66 G (lan-)539.34 185.954 Q(ning.)185.385 199.954 Q(The)185.385 227.954 Q F2 1.228 (Subnet Mask)4.228 F F1 1.228 (\214eld is used to specify just that, and \214nally)4.228 F 4.229(,i)-.78 G 4.229(nt)500.666 227.954 S(he)514.231 227.954 Q F2(Pr)4.229 E(e\214x)-.444 E F1 1.528(\214eld, the position in the assigned address space at which the address\ es for)185.385 241.954 R(this subnet start is speci\214ed.)185.385 255.954 Q .988(As in the e)185.385 283.954 R .989 (xample, entries should be made in the table for assigned address)-.18 F (space which is currently not used.)185.385 297.954 Q/F3 12/Helvetica at 0 SF 3.336(3.2.1.3. Request)72 339.954 R(Ov)3.336 E -2.976(er vie)-.3 F(w)-.24 E F1 1.248(The netw)185.385 358.154 R 1.248(ork o)-.12 F -.18(ve)-.18 G(rvie).18 E 4.248(wi)-.3 G 4.248(su)303.321 358.154 S 1.247 (sed to obtain a quick idea about the scale of the)318.237 358.154 R .395 (request. This information allo)185.385 372.154 R .395 (ws the IR processing the request to g)-.3 F .396(ain imme-)-.06 F 1.21 (diate insight as to the nature of the assignment request. The e)185.385 386.154 R 1.21(xact informa-)-.18 F(tion to be g)185.385 400.154 Q(athered is:) -.06 E/F4 12/Times-Bold at 0 SF 1.15(Size of Request)185.385 432.354 R F1 3.07 -.96(To g)4.15 H -2.58 -.3(iv e).96 H 1.151 (the IR an immediate indication of the scale of the)4.45 F .002(request, the t\ otal number of Internet addresses being requested must be speci-)185.385 446.354 R .971(\214ed under)185.385 460.354 R F2 -.444(re)3.971 G(quest-size) .444 E F1 .971(on the netw)3.971 F .971(ork o)-.12 F -.18(ve)-.18 G(rvie).18 E 3.971(wf)-.3 G 3.971(orm. If)429.242 460.354 R(the)3.971 E F2 -.444(re)3.972 G (quest-size).444 E F1(is)3.972 E .566 (512, the user speci\214es a need for that number of Internet addresses.) 185.385 474.354 R .566(Prior to)6.566 F 2.658(the use of CIDR, the user w) 185.385 488.354 R 2.659(ould ha)-.12 F 3.019 -.18(ve a)-.24 H(sk).18 E 2.659 (ed for tw)-.12 F 5.659(oC)-.12 G 2.659(lass C netw)473.806 488.354 R(orks.) -.12 E .384(Because classless addressing is no)185.385 502.354 R 3.383(wu)-.3 G .383(sed, the size of the request may be less)369.308 502.354 R(than 256 or f) 185.385 516.354 Q(all between the class borders \(e.g. 32, 288, 384\).)-.12 E F4(Addr)185.385 548.554 Q 4.042(esses to be Used)-.216 F F1 5.962 -.96(To o) 7.042 H 4.042(btain an o).96 F -.18(ve)-.18 G(rvie).18 E 7.042(wo)-.3 G 7.042 (ft)444.521 548.554 S 4.043(he structure of the)458.895 548.554 R(requester') 185.385 562.554 Q 3.859(sn)-.66 G(etw)247.228 562.554 Q .859(ork, one must kno) -.12 F 3.858(wh)-.3 G 1.458 -.3(ow m)371.898 562.554 T(an).3 E 3.858(yI)-.18 G .858(nternet addresses will actu-)424.458 562.554 R 1.509(ally be used at dif) 185.385 576.554 R 1.51 (ferent points in time. This corresponds to the number of)-.3 F(interf)185.385 590.554 Q .104(aces to the netw)-.12 F .103 (ork, which often will be slightly higher than the number)-.12 F(of hosts.) 185.385 604.554 Q 2.391(In the netw)185.385 632.554 R 2.391(ork o)-.12 F -.18 (ve)-.18 G(rvie).18 E 5.391(wf)-.3 G 2.391(orm, the \214elds)318.801 632.554 R F2(addr)5.392 E(esses-immediate)-.444 E 5.392(,a)-.12 G(ddr)513.12 632.554 Q (esses-)-.444 E(year)185.385 646.554 Q(-1,)-.24 E F1(and)3.738 E F2(addr)3.738 E(esses-year)-.444 E(-2)-.24 E F1 .738(are used to specify ho)3.738 F 3.738(wm) -.3 G(an)458.997 646.554 Q 3.737(yo)-.18 G 3.737(ft)485.882 646.554 S .737 (he requested)496.951 646.554 R(netw)185.385 660.554 Q 4.175 (ork addresses will be used immediately follo)-.12 F 4.175 (wing the assignment,)-.3 F(within 12 months, and within 24 months, respecti) 185.385 674.554 Q -.18(ve)-.3 G(ly).18 E(.)-.78 E 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 12)-.4 E EP %%Page: 13 13 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Bold at 0 SF 3.214(Number of Subnets)185.385 87.954 R/F2 12 /Times-Roman at 0 SF 3.213(In practice, the end user will w)6.214 F 3.213 (ant to emplo)-.12 F 6.213(yt)-.12 G(he)546.672 87.954 Q .785 (requested addresses in one or more subnets in an or)185.385 101.954 R -.06(ga) -.216 G 3.785(nization. The).06 F(number)3.785 E .704(of ph)185.385 115.954 R .704(ysically separate subnets in which the requested addresses will be used) -.06 F 2.707(is an important f)185.385 129.954 R 2.707 (actor in making correct assignments.)-.12 F -.96(To)8.708 G 2.708 (gether with the).96 F 3.876(number of addresses to be used, this pro)185.385 143.954 R 3.876(vides a global picture of the)-.18 F(requester')185.385 157.954 Q 3.51(se)-.66 G -.48(nv)246.207 157.954 S .51(isioned netw).48 F .51 (ork infrastructure. In the netw)-.12 F .511(ork o)-.12 F -.18(ve)-.18 G(rvie) .18 E 3.511(wf)-.3 G(orm,)535.668 157.954 Q .827(the \214elds)185.385 171.954 R /F3 12/Times-Italic at 0 SF(subnets-immediate)3.827 E 3.827(,s)-.12 G(ubnets-year) 335.07 171.954 Q(-1,)-.24 E F2(and)3.827 E F3(subnets-year)3.827 E(-2)-.24 E F2 .827(are used to)3.827 F 1.399(specify the number of subnets in the requester') 185.385 185.954 R 4.399(sn)-.66 G(etw)434.537 185.954 Q 1.4 (ork plan to be imple-)-.12 F(mented immediately)185.385 199.954 Q 3(,w)-.78 G (ithin 12 months and within 24 months, respecti)297.597 199.954 Q -.18(ve)-.3 G (ly).18 E(.)-.78 E F1(Inter)185.385 232.154 Q .284(net Connection)-.18 F F2 .284(Prior to assigning address space, it is essential to kno)3.284 F(w)-.3 E .029 (if the end user requesting IP addresses is already connected to the Internet.) 185.385 246.154 R(If)6.029 E .919 (so, then the selection of appropriate address space for this user may depend) 185.385 260.154 R .994(on which pro)185.385 274.154 R .994 (vider\(s\) currently supplies connecti)-.18 F(vity)-.3 E 6.994(.I)-.78 G 3.994 (ft)454.713 274.154 S .994(he user is not con-)466.039 274.154 R 1.872 (nected, b)185.385 288.154 R 1.871 (ut is planning to be, this should also be tak)-.24 F 1.871 (en into account. This)-.12 F .443(information is essential if the conserv) 185.385 302.154 R .443(ation and aggre)-.3 F -.06(ga)-.18 G .443 (tion goals of the pub-).06 F .135(lic address space distrib)185.385 316.154 R .134(ution are to be met.)-.24 F .134(The current and planned connec-)6.134 F (ti)185.385 330.154 Q .057(vity of the user is speci\214ed in the)-.3 F F3 (inet-connect)3.058 E F2 .058(\214eld of the netw)3.058 F .058(ork o)-.12 F -.18(ve)-.18 G(rvie).18 E(w)-.3 E(form.)185.385 344.154 Q F1(Country)185.385 376.354 Q F2(Finally)3.037 E 3.037(,t)-.78 G .036 (he country or countries in which the addresses will be used)274.355 376.354 R .731(must be speci\214ed using the ISO 3166 tw)185.385 390.354 R 3.731(ol)-.12 G .731(etter code.)397.777 390.354 R(The)6.732 E F3(country-net)3.732 E F2 (\214eld)3.732 E .974(of the netw)185.385 404.354 R .973(ork o)-.12 F -.18(ve) -.18 G(rvie).18 E 3.973(wf)-.3 G .973(orm is reserv)313.131 404.354 R .973 (ed for this purpose.)-.18 F .973(If the ISO 3166)6.973 F(code is not kno) 185.385 418.354 Q(wn, the full name of the country should be speci\214ed.)-.3 E F1(Pri)185.385 450.554 Q -.12(va)-.12 G .737(te Addr).12 F .737(ess Space)-.216 F F2 .737(Using pri)3.737 F -.3(va)-.3 G .737 (te addresses helps to meet the conserv).3 F(a-)-.3 E 2.759(tion goal.)185.385 464.554 R -.18(Fo)8.758 G 5.758(rt).18 G 2.758(his reason, users should al) 267.82 464.554 R -.12(wa)-.12 G 2.758(ys be informed that pri).12 F -.3(va)-.3 G(te).3 E .093(addresses might be a viable option. In particular)185.385 478.554 R 3.093(,p)-.48 G(ri)428.277 478.554 Q -.3(va)-.3 G .094 (te address space can be).3 F(emplo)185.385 492.554 Q 3.721 (yed if not all hosts require netw)-.12 F 3.72 (ork layer access to the Internet.)-.12 F .53 (Although users are not required to use pri)185.385 506.554 R -.3(va)-.3 G .53 (te address space e).3 F -.18(ve)-.3 G 3.53(ni).18 G 3.53(fi)510.391 506.554 S 3.531(tw)521.253 506.554 S(ould)536.664 506.554 Q 1.365 (satisfy their needs, it is important that the)185.385 520.554 R 4.365(yh)-.18 G -2.7 -.24(av e)409.785 520.554 T 1.365(considered the possibility)4.605 F(.) -.78 E(The)185.385 534.554 Q F3(private-consider)7.617 E(ed)-.444 E F2 4.618 (\214eld in the netw)7.617 F 4.618(ork o)-.12 F -.18(ve)-.18 G(rvie).18 E 7.618 (wf)-.3 G 4.618(orm should be)480.1 534.554 R(check)185.385 548.554 Q 2.591 (ed after the requester has indicated whether it is applicable for the)-.12 F (user')185.385 562.554 Q 3(sn)-.66 G(etw)222.381 562.554 Q(ork.)-.12 E F1 2.562 (Request Refused)185.385 594.754 R F2 2.562(If a user')5.562 F 5.562(so)-.66 G -2.628 -.216(rg a)343.167 594.754 T 2.563 (nization has had an assignment request).216 F .864 (refused in the past, then it is useful to kno)185.385 608.754 R 3.864(ww)-.3 G .864(hen and by which IR.)414.708 608.754 R(What-)6.864 E -2.58 -.3(ev e) 185.385 622.754 T 3.04(rt).3 G .04(he case, it is useful to kno)211.933 622.754 R 3.041(wi)-.3 G 3.041(far)351.236 622.754 S .041 (equest has been refused, and wh)370.638 622.754 R 1.601 -.78(y. T)-.06 H(his) .78 E 1.766(information should be speci\214ed in the)185.385 636.754 R F3 -.444 (re)4.765 G(quest-r).444 E(efused)-.444 E F2 1.765(\214eld in the netw)4.765 F (ork)-.12 E -.18(ove)185.385 650.754 S(rvie).18 E 3(wf)-.3 G(orm.)236.373 650.754 Q F1 .123(PI Requested)185.385 682.954 R F2 .123(If pro)3.123 F .124 (vider independent address space is requested by the user)-.18 F(,)-.48 E 1.786 (special steps will ha)185.385 696.954 R 2.146 -.18(ve t)-.24 H 4.786(ob).18 G 4.786(et)322.883 696.954 S(ak)336.333 696.954 Q 1.785 (en by the local IR processing the request.)-.12 F(The)185.385 710.954 Q F3 (PI-r)4.609 E(equested)-.444 E F2 1.609(\214eld in the netw)4.609 F 1.609 (ork o)-.12 F -.18(ve)-.18 G(rvie).18 E 4.609(wf)-.3 G 1.61 (orm should be check)430.372 710.954 R 1.61(ed if)-.12 F 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 13)-.4 E EP %%Page: 14 14 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF(this is a request for PI address space.)185.385 87.954 Q/F2 12/Helvetica at 0 SF 3.336(3.2.1.4. Addressing)72 129.954 R(Plan)3.336 E F1 2.048 -.96(To a)185.385 162.154 T .128 (ssess the suitability of assigning the requested address space, an).96 F/F3 12 /Times-Italic at 0 SF(addr)3.127 E(ess-)-.444 E .409(ing plan)185.385 176.154 R F1 .409(is required.)3.409 F .409(This pro)6.409 F .41 (vides detailed information on the projected use)-.18 F 1.764 (of the requested address space.)185.385 190.154 R(Lik)7.763 E 4.763(et)-.12 G (he)378.461 190.154 Q F3(curr)4.763 E 1.763(ent addr)-.444 F 1.763 (ess space usa)-.444 F -.12(ge,)-.12 G F1(the)4.883 E (addressing plan is a table in which e)185.385 204.154 Q -.18(ve)-.3 G (ry subnet is speci\214ed.).18 E -.48(Wi)185.385 232.154 S .662(th fe).48 F 3.662(we)-.3 G .662(xceptions, the entries in the follo)239.065 232.154 R .662 (wing table are the same as those)-.3 F (in the table of current address space usage.)185.385 246.154 Q/F4 8/Courier at 0 SF 144(Relative Addresses)185.385 281.154 R(Used)4.8 E 24(Prefix# Subnet) 185.385 295.154 R 28.8(Mask Size)4.8 F(Immediate 1yr 2yr)9.6 E(Description)9.6 E 24(0.0.0.0 255.255.255.192)185.385 323.154 R 48(64 8)338.985 323.154 R 4.8 (16 30 Systems)9.6 F(Group)4.8 E 19.2(0.0.0.64 255.255.255.224)185.385 337.154 R 43.2(32 17)338.985 337.154 R 4.8(22 26 Engineering)9.6 F 19.2 (0.0.0.96 255.255.255.224)185.385 351.154 R 43.2(32 12)338.985 351.154 R 4.8 (17 20 Manufacturing)9.6 F 14.4(0.0.0.128 255.255.255.224 32)185.385 365.154 R 4.8(10 15 20 Sales)396.585 365.154 R 14.4(0.0.0.160 255.255.255.240 16)185.385 379.154 R 14.4(59)401.385 379.154 S 4.8(12 Management)434.985 379.154 R 14.4 (0.0.0.176 255.255.255.240 16)185.385 393.154 R 14.4(789)401.385 393.154 S (Finance)454.185 393.154 Q 43.2(192 59)335.385 421.154 R(87 117)9.6 E(Totals) 9.6 E F1 .659(The number of netw)185.385 460.354 R .659(ork interf)-.12 F .659 (aces immediately required in the subnet, along)-.12 F .666 (with the projected need for the coming 12 and 24 months must be speci\214ed.) 185.385 474.354 R .773(These numbers are to be entered in the)185.385 488.354 R F3(Immediate)3.772 E 3.772(,1)-.12 G(yr)443.488 488.354 Q(,)-1.332 E F1(and) 3.772 E F3(2yr)3.772 E F1 .772(\214elds of the)3.772 F(subnet entry)185.385 502.354 Q(.)-.78 E 1.438(In the)185.385 530.354 R F3 1.438(Relative Pr)4.438 F (e\214x)-.444 E F1 1.438(\214eld, we specify the relati)4.438 F 1.798 -.18 (ve p)-.3 H 1.439(osition in the assigned).18 F 1.347 (address space at which the addresses for this subnet will start. The relati) 185.385 544.354 R -.18(ve)-.3 G .449(position of the \214rst subnet is al) 185.385 558.354 R -.12(wa)-.12 G .449(ys 0.0.0.0. F).12 F .45 (or each subsequent subnet, the)-.18 F 1.734 (start position is selected to allo)185.385 572.354 R 4.733(wf)-.3 G 1.733 (or the total number of hosts in the)359.48 572.354 R F3(Size)4.733 E F1 (\214elds of the subnets which precede it.)185.385 586.354 Q 5.235 -.96(To c) 185.385 628.354 T(onserv).96 E 6.315(ea)-.18 G 3.316 (ddress space, the start positions of the subnets should be)258.183 628.354 R .13(selected to minimize padding in the address space.)185.385 642.354 R .13 (In the e)6.13 F .13(xample abo)-.18 F -.18(ve)-.18 G 3.13(,w).18 G(e)552.672 642.354 Q 1.564(arrange the ro)185.385 656.354 R 1.565 (ws in decreasing order of the)-.3 F F3(Size)4.565 E F1 1.565 (\214eld. This scheme can be)4.565 F 1.73(applied in general to pre)185.385 670.354 R -.18(ve)-.3 G 1.73(nt w).18 F 1.729 (asting address space between subnets.)-.12 F(The)7.729 E 1.009(size of e) 185.385 684.354 R -.18(ve)-.3 G 1.009(ry v).18 F 1.01 (alid request for address space will be the sum of sizes of the)-.3 F (subnets speci\214ed in the addressing plan.)185.385 698.354 Q 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 14)-.4 E EP %%Page: 15 15 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF 1.511(Current e)185.385 87.954 R -.3(va)-.3 G 1.511 (luation criteria assume that addressing is classless.).3 F 1.511(This means) 7.511 F 1.799(that all possible pre\214x)185.385 101.954 R 1.799(es of an)-.18 F 4.799(yl)-.18 G 1.799(ength can be used.)351.807 101.954 R 1.8 (If there are technical)7.8 F .266(restrictions pre)185.385 115.954 R -.18(ve) -.3 G .265(nting the use of certain address ranges or the choice of opti-).18 F .585(mal subnet sizes, these restrictions need to be e)185.385 129.954 R .585 (xplicitly documented.)-.18 F(Docu-)6.585 E 1.921 (mentation needs to include the precise nature of the restriction, the mak) 185.385 143.954 R(e,)-.12 E .176(model and v)185.385 157.954 R .176 (ersion of the hardw)-.18 F .176(are or softw)-.12 F .177 (are causing the restriction, and its)-.12 F(precise location in the netw) 185.385 171.954 Q(ork.)-.12 E/F2 12/Helvetica at 0 SF 3.336(3.2.1.5. Database)72 213.954 R(Inf)3.336 E -3.036(or mation)-.36 F F1 -.18(Fo)185.385 232.154 S 6.287(rr).18 G -.18(eg)212.156 232.154 S 3.287 (istration purposes, information is required about the or).18 F -.06(ga)-.216 G (nization).06 E 4.372 (needing address space. Information is also required about the persons)185.385 246.154 R(in)185.385 260.154 Q -.24(vo)-.48 G(lv).24 E 1.156 (ed in the request and administration of the addresses.)-.18 F 4.155 (request. Some)7.156 F .502 (of the information may be redundant because the same person can play mul-) 185.385 274.154 R 1.784(tiple roles.)185.385 288.154 R(Ho)7.784 E(we)-.3 E -.18 (ve)-.3 G 2.744 -.48(r, e).18 H -.18(ve).18 G 1.783 (ry role can be \214lled by someone dif).18 F 1.783(ferent, so all)-.3 F .461 (information must be supplied in full.)185.385 302.154 R .462 (The data speci\214ed belo)6.462 F 3.462(wi)-.3 G 3.462(st)497.682 302.154 S 3.462(ob)509.148 302.154 S 3.462(eg)524.61 302.154 S(ath-)539.34 302.154 Q 1.037 (ered by the local IR handling the assignment, and will be stored in the re) 185.385 316.154 R(g-)-.18 E (istry database, at which point it becomes publicly accessible.)185.385 330.154 Q/F3 12/Times-Bold at 0 SF(Or)185.385 362.354 Q(ganization)-.12 E F1 .102 (Some information about the or)3.102 F -.06(ga)-.216 G .103 (nization that will be using the).06 F .85 (addresses must be supplied for maintenance of the RIPE database. The)185.385 376.354 R/F4 12/Times-Italic at 0 SF(Net-)3.85 E(work T)185.385 390.354 Q(emplate) -1.104 E F1(is supplied for this purpose.)3 E 2.906 -.96(To h)185.385 418.354 T .986(elp identify this assignment in the RIPE database, a short, b).96 F .987 (ut semanti-)-.24 F 3.727(cally meaningful name must be entered in the)185.385 432.354 R F4(netname)6.727 E F1 6.726(\214eld. A)6.727 F(short)6.726 E .207 (description of the or)185.385 446.354 R -.06(ga)-.216 G .208 (nization that will use the assigned addresses is needed.).06 F 1.331 (The information is speci\214ed using one or more)185.385 460.354 R F4(descr) 4.331 E F1 1.331(\214elds in the)4.331 F F4(Network)4.331 E -1.104(Te)185.385 474.354 S(mplate)1.104 E(.)-.18 E F1 .124(If, for e)6.124 F .124 (xample, the assigned addresses will be used by the Depart-)-.18 F 1.781 (ment of Neural Sur)185.385 488.354 R 1.781(gery at Catatonic State Uni)-.216 F -.18(ve)-.3 G(rsity).18 E 4.781(,t)-.78 G 1.781(hen the department)462.458 488.354 R 1.604(and uni)185.385 502.354 R -.18(ve)-.3 G 1.604 (rsity names may be speci\214ed in tw).18 F(o)-.12 E F4(descr)4.604 E F1 4.605 (\214elds. The)4.604 F 1.605(ISO 3166)4.605 F .445 (country code should be speci\214ed in the)185.385 516.354 R F4(country)3.444 E F1 3.444(\214eld. The)3.444 F .444(full country name)3.444 F (can be used if the code is not kno)185.385 530.354 Q(wn.)-.3 E(The)185.385 562.554 Q F4(admin-c)3.246 E F1(and)3.246 E F4(tec)3.246 E(h-c)-.18 E F1 .247 (\214elds are used to specify the IR handle)3.246 F F4 .247(\(NIC handle\)) 3.247 F F1 4.429(for the administrati)185.385 576.554 R 4.789 -.18(ve a)-.3 H 4.428(nd technical contact persons, respecti).18 F -.18(ve)-.3 G(ly).18 E 10.428(.T)-.78 G(he)546.672 576.554 Q(administrati)185.385 590.554 Q 4.157 -.18 (ve p)-.3 H 3.797(erson speci\214ed in the).18 F F4(admin-c)6.798 E F1 3.798 (\214eld must be ph)6.798 F(ysically)-.06 E .359 (located at the site of the netw)185.385 604.554 R 3.358(ork. The)-.12 F .358 (technical person speci\214ed in the)3.358 F F4(tec)3.358 E(h-)-.18 E(c)185.385 618.554 Q F1 .824(\214eld may be a netw)3.824 F .824 (ork support person located on site, b)-.12 F .825(ut could also be a)-.24 F 2.073(consultant that maintains the netw)185.385 632.554 R 2.073 (ork for the or)-.12 F -.06(ga)-.216 G 5.072(nization. In).06 F 2.072 (both cases,)5.072 F 1.258(more than one person can be speci\214ed.)185.385 646.554 R 1.259(The use of NIC handles to specify)7.258 F .773 (each contact person is required, as it assures each person has a unique entry) 185.385 660.554 R .357(in the database.)185.385 674.554 R .357 (If the person doesn')6.357 F 3.358(th)-.216 G -2.7 -.24(av e)375.962 674.554 T .358(an entry in the database, a unique)3.598 F (NIC handle can be acquired upon request.)185.385 688.554 Q 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 15)-.4 E EP %%Page: 16 16 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Bold at 0 SF -.24(Pe)185.385 87.954 S .529(rsonal Data).24 F/F2 12 /Times-Roman at 0 SF -.18(Fo)3.529 G 3.529(re).18 G -.18(ve)286.572 87.954 S .528 (ry person in).18 F -.24(vo)-.48 G(lv).24 E .528 (ed in an assignment request, we need)-.18 F 3.786(af)185.385 101.954 S .786 (ull set of personal data. This data can only be omitted if up to date infor) 198.495 101.954 R(-)-.24 E 1.215(mation for the gi)185.385 115.954 R -.18(ve) -.3 G 4.215(np).18 G 1.215(erson is already stored in the RIPE database.) 296.421 115.954 R 1.215(If ne)7.215 F(w)-.3 E .61(data is pro)185.385 129.954 R .611(vided for a person with an entry in the database, it will be vie)-.18 F (wed)-.3 E .693(as an update upon submission, and o)185.385 143.954 R -.18(ve) -.18 G .693(rwrite the current person data. Other).18 F(-)-.24 E .152 (wise, the follo)185.385 157.954 R .152 (wing set of data must be speci\214ed in the)-.3 F/F3 12/Times-Italic at 0 SF -.96 (Pe)3.153 G -.12(rs).96 G .153(on T).12 F(emplate)-1.104 E(.)-.18 E F2(The) 6.153 E(person')185.385 171.954 Q 3.597(sn)-.66 G .597 (ame should be speci\214ed in full in the)234.978 171.954 R F3(per)3.596 E(son) -.12 E F2 3.596(\214eld. The)3.596 F .596(full postal)3.596 F 2.601 (address is speci\214ed using multiple)185.385 185.954 R F3(addr)5.602 E(ess) -.444 E F2 5.602(\214elds. The)5.602 F 2.602(international tele-)5.602 F .011 (phone number which can be used to reach the person at w)185.385 199.954 R .011 (ork must be entered)-.12 F .817(in the)185.385 213.954 R F3(phone)3.818 E F2 .818(\214eld, and the f)3.818 F .818(ax number should be entered in the)-.12 F F3(fax-no)3.818 E F2(\214eld.)3.818 E .263 (Of course, the NIC handle for this person must be entered in the)185.385 227.954 R F3(nic-hdl)3.262 E F2(\214eld)3.262 E (to uniquely identify this person in the database.)185.385 241.954 Q/F4 12 /Helvetica at 0 SF(Submission Inf)72 283.954 Q -3.036(or mation)-.36 F F2 2.303 (In both the Netw)185.385 316.154 R 2.303(ork T)-.12 F 2.303 (emplate and Person T)-.84 F 2.303(emplate, space is reserv)-.84 F 2.304(ed to) -.18 F .046(identify the person submitting these entries to the re)185.385 330.154 R .046(gistry database.)-.18 F .046(The sub-)6.046 F(mitter')185.385 344.154 Q 4.146(se)-.66 G 1.147(-mail address must be speci\214ed in the) 231.531 344.154 R F3 -.18(ch)4.147 G(ang).18 E(ed)-.12 E F2 1.147 (\214eld together with)4.147 F(the date the template is submitted.)185.385 358.154 Q(Similarly)185.385 386.154 Q 3.979(,t)-.78 G(he)239.596 386.154 Q F3 (sour)3.979 E(ce)-.444 E F2 .978(\214eld is used to specify the re)3.979 F .978 (gistry database where the)-.18 F .641 (requester information can be found after an assignment is made. In this case) 185.385 400.154 R 2.525 (it will be RIPE, as the requester information for this assignment will be) 185.385 414.154 R(stored in the RIPE database.)185.385 428.154 Q F4 3.336 (3.2.2. Additional)72 484.154 R(Inf)3.336 E -3.036(or mation)-.36 F F2 3.924 (In the assessment of an assignment request, the additional information)185.385 502.354 R 1.047(described belo)185.385 516.354 R 4.047(wi)-.3 G 4.047(sa) 271.827 516.354 S -.12(lwa)285.87 516.354 S 1.046 (ys useful. In some cases, IR').12 F 4.046(sm)-.66 G 1.046 (ay require this data)463.218 516.354 R(be pro)185.385 530.354 Q (vided as part of the e)-.18 E -.3(va)-.3 G(luation process.).3 E F1 .19 (Deployment Plan)185.385 558.354 R F2 .19(Suppose we are dealing with a ne)3.19 F 3.19(wc)-.3 G .19(orporation that w)455.751 558.354 R(ants)-.12 E 1.371 (to ha)185.385 572.354 R 1.731 -.18(ve a)-.24 H 1.37 (ccess to the Internet, and estimates an immediate need for 10,000).18 F .586 (addresses. In such cases, a)185.385 586.354 R F3 .586(deployment plan)3.586 F F2 .587(may be requested from the user)3.586 F(.)-.66 E 1.876 (The plan should include a list of e)185.385 600.354 R -.18(ve)-.3 G 1.875 (nts which will lead to the use of the).18 F .235 (requested addresses, along with the dates that the e)185.385 614.354 R -.18 (ve)-.3 G .235(nts will occur).18 F 6.236(.T)-.66 G .236(his can)524.104 614.354 R .76(be used to determine ho)185.385 628.354 R 3.76(wr)-.3 G .759 (ealistic the user is being, and if suitable to phase)319.193 628.354 R (the assignment process in according to the user')185.385 642.354 Q 3(sp)-.66 G (lans.)428.685 642.354 Q F1 -1.104(To)185.385 670.354 S .648(pological Map) 1.104 F F2 .648(The old saying "a picture is w)3.648 F .649(orth a thousand w) -.12 F .649(ords" cer)-.12 F(-)-.24 E .589(tainly holds in the case of netw) 185.385 684.354 R 3.589(orks. If)-.12 F(a)3.589 E F3(topolo)3.589 E .589 (gical map)-.12 F F2 .589(of the current and)3.589 F 5.635(planned netw)185.385 698.354 R 5.636(ork infrastructure in the requesting or)-.12 F -.06(ga)-.216 G 5.636(nization can be).06 F .027(acquired, it can pro)185.385 712.354 R .026 (vide insight on the netw)-.18 F .026(ork structure. Such maps are often)-.12 F 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 16)-.4 E EP %%Page: 17 17 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF -.24(av)185.385 87.954 S .899 (ailable, and are quite useful when combined with the addressing plan and)-.06 F(current address space usage.)185.385 101.954 Q/F2 12/Times-Bold at 0 SF .624 (Special Cir)185.385 129.954 R(cumstances)-.216 E F1 .623 (Sometimes, due to the use of old systems or special)3.624 F 1.438 (purpose hardw)185.385 143.954 R 1.438(are, the user is unable to mak)-.12 F 4.438(eu)-.12 G 1.439(se of assignments based on)422.261 143.954 R .703 (classless addressing. If this is the case, information should be g)185.385 157.954 R .702(athered from)-.06 F 1.471(the user as to the)185.385 171.954 R /F3 12/Times-Italic at 0 SF 1.471(speci\214c har)4.471 F(dwar)-.444 E 4.471(eo) -.444 G 4.471(rs)373.102 171.954 S(oftwar)386.909 171.954 Q(e)-.444 E F1 1.472 (which presents a problem.)4.471 F(Moreo)185.385 185.954 Q -.18(ve)-.18 G 1.667 -.48(r, i).18 H 3.707(ti).48 G 3.707(su)252.283 185.954 S .707(seful to kno) 266.658 185.954 R 3.707(wh)-.3 G 1.307 -.3(ow l)342.807 185.954 T .706 (ong the user will be using the hardw).3 F(are)-.12 E(or softw)185.385 199.954 Q(are which presents a problem.)-.12 E F2 -1.2(Ve)185.385 227.954 S .582 (ri\214cation Inf)1.2 F(ormation)-.3 E F1 .582(In w)3.582 F .582 (orking with a user who hasn')-.12 F 3.583(th)-.216 G .583(ad substantial) 491.753 227.954 R(netw)185.385 241.954 Q 2.265(ork e)-.12 F 2.265 (xperience, it is sometimes hard to determine whether the user')-.18 F(s)-.66 E .187(request is based on a realistic plan. It can therefore be useful to reque\ st infor)185.385 255.954 R(-)-.24 E 1.381(mation which might indicate the de) 185.385 269.954 R 1.38(gree to which the user understands net-)-.18 F -.12(wo) 185.385 283.954 S 1.585(rk planning and management. First, one may ask ho).12 F 4.586(wa)-.3 G 1.586(ccurate the user)479.528 283.954 R 1.769 (thinks the estimations in the addressing plan are, and ho)185.385 297.954 R 4.769(wt)-.3 G(he)486.422 297.954 Q 4.769(yh)-.18 G -2.7 -.24(av e)514.339 297.954 T(been)5.009 E(deri)185.385 311.954 Q -.18(ve)-.3 G 1.261 (d. The corresponding name space plans pro).18 F 1.262 (vide another indication of)-.18 F(ho)185.385 325.954 Q 3(ww)-.3 G (ell considered the user')217.413 325.954 Q 3(sp)-.66 G(lans are.)342.057 325.954 Q/F4 12/Helvetica at 0 SF 3.336(3.3. Ev)72 367.954 R(aluation)-.3 E F1(Ha) 185.385 386.154 Q 1.925(ving collected the abo)-.24 F 2.285 -.18(ve i)-.18 H 1.925(nformation, we must no).18 F 4.925(wd)-.3 G 1.925(etermine a proper) 469.514 386.154 R 1.187(assignment with respect to the conserv)185.385 400.154 R 1.187(ation and aggre)-.3 F -.06(ga)-.18 G 1.187(tion goals stated in).06 F .522(Section 1.)185.385 414.154 R(Ev)6.521 E .521(ery request requires an indi) -.18 F .521(vidual e)-.3 F -.3(va)-.3 G .521(luation process that tak).3 F(es) -.12 E(current assignment guidelines into account.)185.385 428.154 Q(Gi)185.385 456.154 Q -.18(ve)-.3 G 4.183(nt).18 G 1.183(he abo)221.752 456.154 R 1.543 -.18(ve d)-.18 H 1.184(ocumentation, one must determine if IP addresses should) .18 F .073(be assigned, and if so, ho)185.385 470.154 R 3.072(wm)-.3 G(an) 327.504 470.154 Q 3.072(ya)-.18 G .072 (nd of what type. In the process, it is essen-)353.052 470.154 R 1.738 (tial that IR')185.385 484.154 R 4.738(sw)-.66 G 1.738(ork to pre)261.483 484.154 R -.18(ve)-.3 G 1.739(nt the stockpiling of address space. The use of) .18 F 2.802(classless addressing will contrib)185.385 498.154 R 2.802 (ute to the conserv)-.24 F 2.801(ation of address space.)-.3 F .297 (Meanwhile, to enable proper routing, one must mak)185.385 512.154 R 3.297(es) -.12 G(trate)449.598 512.154 Q .297(gic decisions with)-.18 F(re)185.385 526.154 Q -.06(ga)-.18 G 1.265(rd to aggre).06 F -.06(ga)-.18 G 4.265 (tion. These).06 F 1.264(concerns moti)4.264 F -.3(va)-.3 G 1.264(te the e).3 F -.3(va)-.3 G 1.264(luation process out-).3 F(lined in this section.)185.385 540.154 Q F4(Ev)72 582.154 Q(aluation Steps)-.3 E F2 .766(1. Curr)185.385 600.354 R .766(ent addr)-.216 F .766(ess space usage)-.216 F F1 .766 (One should start by comparing the current)3.766 F 1.009 (address space usage pro)185.385 614.354 R 1.008 (vided by the requester with other information a)-.18 F -.3(va)-.24 G(il-).3 E 1.212(able to the IR.)185.385 628.354 R 1.212(After v)7.212 F 1.212 (erifying the current address space usage, one should)-.18 F 1.424 (check to see if the requested IP addresses can be tak)185.385 642.354 R 1.423 (en from those already)-.12 F(assigned to the user)185.385 656.354 Q(.)-.66 E F2 .407(2. Netw)185.385 684.354 R .407(ork Ov)-.12 F(er)-.12 E(view)-.12 E F1 (Ne)3.407 E .407(xt, the size of the request, speci\214ed in the)-.18 F F3 (Network)3.408 E(Overvie)185.385 698.354 Q(w)-.18 E F1 2.897 (should be compared with the number of addresses to be used)5.897 F (immediately)185.385 712.354 Q 3.813(,a)-.78 G .813(nd within tw)256.746 712.354 R 3.813(oy)-.12 G .814(ears of the time the request is made. Here we) 334.737 712.354 R 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 17)-.4 E EP %%Page: 18 18 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF -.3(eva)185.385 87.954 S .023(luate the utilization ra\ tes, that is address space requested in relation to that).3 F 2.445 (to be used.)185.385 101.954 R 2.446 (Unless there are special circumstances, immediate utilization)8.445 F .565(sh\ ould be at least 25% of the assigned address space, and the utilization rate) 185.385 115.954 R(one year later should be at least 50%.)185.385 129.954 Q/F2 12/Times-Bold at 0 SF .379(3. Pri)185.385 157.954 R -.12(va)-.12 G .379(te Addr) .12 F .379(ess Space)-.216 F F1(If)3.379 E/F3 12/Times-Italic at 0 SF .379 (private addr)3.379 F .379(ess space)-.444 F F1 .38(might be suitable for this) 3.379 F(netw)185.385 171.954 Q 2.196 (ork, it must be assured that the user is a)-.12 F -.12(wa)-.18 G 2.196 (re of this option and has).12 F .445(decided ag)185.385 185.954 R .445 (ainst it.)-.06 F(Moreo)6.445 E -.18(ve)-.18 G 3.445(ru).18 G .445 (sers should be a)336.049 185.954 R -.12(wa)-.18 G .445(re that the).12 F 3.446 (yw)-.18 G .446(ill ha)494.204 185.954 R .806 -.18(ve m)-.24 H(ore).18 E (address space at their disposal if the)185.385 199.954 Q 3(yu)-.18 G(se pri) 372.837 199.954 Q -.3(va)-.3 G(te address space.).3 E F2 .009(4. V)185.385 227.954 R .009(ery Small Enter)-1.2 F .008(prises \(VSE')-.12 F(s\))-.444 E F1 .008(An address space user with a small num-)3.008 F .847 (ber of hosts \(currently <=32\) is referred to as a v)185.385 241.954 R .848 (ery small enterprise \(VSE\))-.18 F(re)185.385 255.954 Q -.06(ga)-.18 G .324 (rdless of the size of the or).06 F -.06(ga)-.216 G 3.323(nization. Address).06 F .323(space for VSEs should be)3.323 F .882(assigned in a classless w)185.385 269.954 R(ay)-.12 E 6.882(.A)-.78 G 3.882(sw)335.871 269.954 S .882 (ith all address space requests, care should)353.085 269.954 R 3.844(be tak) 185.385 283.954 R 3.844(en to a)-.12 F -.24(vo)-.24 G 3.843 (id assigning more address space than is required.).24 F(See)9.843 E 1.092 (\(Eidnes/deGroot\) for appropriate re)185.385 297.954 R -.18(ve)-.3 G 1.092 (rse dele).18 F -.06(ga)-.18 G 1.092(tion methods.).06 F 1.093(VSEs that do) 7.093 F 2.442 (not intend to connect to the Internet should normally not be assigned PI) 185.385 311.954 R 1.898(space b)185.385 325.954 R 1.898(ut referred to pri)-.24 F -.3(va)-.3 G 1.899(te address space because the ef).3 F 1.899 (fort to renumber)-.3 F(into P)185.385 339.954 Q 3(As)-1.104 G (pace at that point is normally minimal.)228.957 339.954 Q F2 .405(5. Addr) 185.385 367.954 R .405(essing Plan)-.216 F F1 .405(In e)3.405 F -.3(va)-.3 G .405(luating the addressing plan, one should \214rst check).3 F 1.7 (that the totals for the number of addresses to be used immediately)185.385 381.954 R 4.701(,i)-.78 G 4.701(no)529.971 381.954 S(ne)546.672 381.954 Q(year) 185.385 395.954 Q 3.423(,a)-.48 G .423(nd in tw)217.308 395.954 R 3.422(oy)-.12 G .422(ears, correspond to those speci\214ed in the request o)272.792 395.954 R -.18(ve)-.18 G(rvie).18 E -.78(w.)-.3 G .814(The v)185.385 409.954 R .814 (alidity of the netw)-.3 F .814(ork masks should then be check)-.12 F .815 (ed to see if the)-.12 F 3.815(ya)-.18 G(re)548.676 409.954 Q .092 (consistent with the size of the subnet.)185.385 423.954 R .091 (Sometimes address space can be sa)6.091 F -.18(ve)-.24 G(d).18 E 1.894 (by using dif)185.385 437.954 R 1.894 (ferent subnet masks than speci\214ed by the user)-.3 F 4.895(.I)-.66 G 4.895 (fs)490.995 437.954 S 1.895(o, the user)504.554 437.954 R .88 (should be requested to resubmit an addressing plan with a more appropriate) 185.385 451.954 R(use of netw)185.385 465.954 Q(ork masks.)-.12 E .691 (In general, there should not be a lar)185.385 493.954 R .692(ge g)-.216 F .692 (ap between the number of addresses)-.06 F .77 (requested for a subnet \(size\) and the number which will be used. This holds) 185.385 507.954 R -2.58 -.3(ev e)185.385 521.954 T 3.832(ni).3 G 3.832(ft) 214.729 521.954 S .832(he requester ar)225.893 521.954 R .833(gues that netw) -.216 F .833(ork administration will be greatly sim-)-.12 F (pli\214ed by an addressing scheme with lots of padding.)185.385 535.954 Q F2 2.725(6. Additional Inf)185.385 563.954 R(ormation)-.3 E F1 2.724(If a deplo) 5.725 F 2.724(yment plan has been pro)-.12 F 2.724(vided, the)-.18 F 1.226 (addressing plan should be re)185.385 577.954 R(vie)-.3 E 1.227 (wed to see if the tw)-.3 F 4.227(oc)-.12 G 1.227(orrespond. Lik)456.213 577.954 R -.3(ew)-.12 G(ise,).3 E .724 (one should inspect the topology map if it is a)185.385 591.954 R -.3(va)-.24 G .723(ilable to see if it agrees with).3 F 1.357(the addressing plan. An)185.385 605.954 R 4.357(yi)-.18 G 1.357(nformation g)316.285 605.954 R 1.358 (athered which can be used to check)-.06 F 1.272(the v)185.385 619.954 R 1.271 (alidity of the current address space usage and addressing plans should)-.3 F (be emplo)185.385 633.954 Q(yed to do so.)-.12 E F2 2.936(7. Addr)185.385 661.954 R 2.936(ess Reser)-.216 F -.12(va)-.12 G(tions).12 E F1 2.936 (Assignments must be based solely on realistic)5.936 F -.18(ex)185.385 675.954 S .232(pectations as speci\214ed in the addressing plan and the current addres\ s space).18 F 3.906(usage. End)185.385 689.954 R .906 (users are not permitted to reserv)3.906 F 3.906(ea)-.18 G .907 (ddresses based on long term)419.061 689.954 R 5.001 (plans, because it fragments the address space.)185.385 703.954 R 5 (Such reserv)445.664 703.954 R 5(ations are)-.3 F 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 18)-.4 E EP %%Page: 19 19 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF .561(generally fruitless because the)185.385 87.954 R 3.561(yt)-.18 G .561(urn out to be unnecessary or insuf)344.745 87.954 R .561 (\214cient for)-.3 F(the user')185.385 101.954 Q 3(sn)-.66 G(eeds.)240.045 101.954 Q/F2 12/Times-Bold at 0 SF .093(8. Static Dialup)185.385 129.954 R F1 .093 (Due to constraints on the a)3.093 F -.3(va)-.24 G .092 (ilable free pool of IPv4 address).3 F 1.891 (space, the use of static IP address assignments \(e.g., one address per cus-) 185.385 143.954 R .757(tomer\) for dial-up users is strongly discouraged.) 185.385 157.954 R .756(While it is understood that)6.756 F .16 (the use of static addressing may ease some aspects of administration, the cur) 185.385 171.954 R(-)-.24 E 2.201 (rent rate of consumption of the remaining unassigned IPv4 address space) 185.385 185.954 R .343 (does not permit the assignment of addresses for administrati)185.385 199.954 R .704 -.18(ve e)-.3 H 3.344(ase. Or).18 F -.06(ga)-.216 G(ni-).06 E 1.503 (zations considering the use of static IP address assignment are e)185.385 213.954 R 1.502(xpected to)-.18 F(in)185.385 227.954 Q -.18(ve)-.48 G(stig).18 E .122(ate and implement dynamic assignment technologies whene)-.06 F -.18(ve) -.3 G 3.123(rp).18 G(ossi-)535.332 227.954 Q 4.457(ble. If)185.385 241.954 R 1.457(allocations for this purpose are indeed made, special allocation and) 4.457 F -.18(ve)185.385 255.954 S(ri\214catin procedures apply).18 E 6(.P)-.78 G(lease contact the RIPE NCC for details.)334.065 255.954 Q F2 2.672(9. V) 185.385 283.954 R 2.672(irtual Hosts)-.444 F F1 2.672 (Sometimes a single host is assigned more than one IP)5.672 F .121 (address on the same interf)185.385 297.954 R .12(ace and ph)-.12 F .12 (ysical netw)-.06 F 3.12(ork. Often)-.12 F .12(this is used to cir)3.12 F(-) -.24 E(cumv)185.385 311.954 Q 1.087(ent shortcomings in higher le)-.18 F -.18 (ve)-.3 G 4.087(lp).18 G 1.088(rotocols such as HTTP)380.48 311.954 R 7.088(.L) -1.332 G(ar)509.488 311.954 Q 1.088(ge scale)-.216 F 1.734 (assignments for this purpose are discouraged for the reasons mentioned in) 185.385 325.954 R 3.305(the paragraph abo)185.385 339.954 R -.18(ve)-.18 G 9.305(.I).18 G 6.305(fa)305.232 339.954 S 3.305 (llocations or assignments for this purpose are)320.861 339.954 R .185 (indeed made, special allocation and v)185.385 353.954 R .184 (eri\214catin procedures apply)-.18 F 6.184(.P)-.78 G .184(lease con-)509.504 353.954 R(tact the RIPE NCC for details.)185.385 367.954 Q/F3 12/Helvetica at 0 SF 3.336(3.4. Assignment)72 409.954 R(Procedures)3.336 E F1 2.458 -.96(We n) 185.385 442.154 T 1.138 -.3(ow d).96 H .538 (escribe the speci\214c procedures to be follo).3 F .538 (wed in assigning address)-.3 F 4.423(space. In)185.385 456.154 R 1.423 (the follo)4.423 F 1.423 (wing, we assume that the required information has been)-.3 F -.06(ga)185.385 470.154 S 1.064(thered, and e).06 F -.3(va)-.3 G 1.065 (luated as outlined in the pre).3 F 1.065(vious subsections.)-.3 F 1.065 (The proce-)7.065 F .878(dures described in this subsection lead to the assign\ ment of speci\214c address)185.385 484.154 R (space for the request under consideration.)185.385 498.154 Q F3 3.336 (3.4.1. Assignments)72 540.154 R(within Allocations)3.336 E F1 .613 (Once an IR has assured that the address space request merits the assignment) 185.385 558.354 R(of)185.385 572.354 Q/F4 12/Times-Italic at 0 SF(k)3.313 E F1 .312(addresses, the actual set of addresses to be assigned must be selected.) 3.313 F(If)6.312 E 1.209 (the addresses are to be assigned from a range of address space allocated to) 185.385 586.354 R .509 (the local IR making the assignment, then care must be tak)185.385 600.354 R .509(en to pre)-.12 F -.18(ve)-.3 G .508(nt frag-).18 F 2.714 (mentation of the allocated space.)185.385 614.354 R(Speci\214cally)8.715 E 5.715(,e)-.78 G 2.715(ach set of address space)432.516 614.354 R 2.998 (assigned should start on a CIDR \(bit\) boundaries.)185.385 628.354 R 2.998 (This means the start)8.998 F 1.546 (address for each set of assigned range must be di)185.385 642.354 R 1.547 (visible by the size of the)-.3 F 1.061(block to be assigned.)185.385 656.354 R 1.06(This helps to achie)7.06 F 1.42 -.18(ve t)-.3 H 1.06(he aggre).18 F -.06 (ga)-.18 G 1.06(tion goal in address).06 F(space assignments.)185.385 670.354 Q 1.611 (Suppose a request can be satis\214ed with a number small chunks of address) 185.385 698.354 R .55(space rather than one lar)185.385 712.354 R .549(ge one.) -.216 F -.18(Fo)6.549 G 3.549(re).18 G .549(xample, if 384 addresses are suf) 371.595 712.354 R(\214cient)-.3 E 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 19)-.4 E EP %%Page: 20 20 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF 1.218(to satisfy a request, b)185.385 87.954 R 1.219 (ut no more than 256 will be used in a single ph)-.24 F(ysical)-.06 E .335(sub\ net, then the user can be assigned a /24 and a /25 rather than a /23, which) 185.385 101.954 R 1.199(results in sa)185.385 115.954 R 1.199 (ving a /25 for another user)-.24 F 4.199(.L)-.66 G 1.2 (ocal IRs are encouraged to assign)391.045 115.954 R .032(multiple range of ad\ dress space, rather than a single range in accordance with)185.385 129.954 R 1.637(the conserv)185.385 143.954 R 1.638(ation goal. Of course the ef)-.3 F 1.638(fort to do so should increase as the)-.3 F (amount of address space that can be sa)185.385 157.954 Q -.18(ve)-.24 G 3(di) .18 G 3(nd)394.245 157.954 S(oing so increases.)409.245 157.954 Q .046 (Local IRs are al)185.385 185.954 R -.12(wa)-.12 G .045 (ys welcome to request advice from the RIPE NCC in mak-).12 F 1.891 (ing assignment decisions. In some cases, ho)185.385 199.954 R(we)-.3 E -.18 (ve)-.3 G 2.852 -.48(r, a).18 H 4.892(na).48 G 1.892(ssignment must be)464.876 199.954 R(appro)185.385 213.954 Q -.18(ve)-.18 G 3.524(db).18 G 3.524(yt) 239.201 213.954 S .524(he RIPE NCC e)252.061 213.954 R -.18(ve)-.3 G 3.524(ni) .18 G 3.523(fi)353.673 213.954 S 3.523(ti)364.528 213.954 S 3.523(sm)374.723 213.954 S .523(ade from a block of address space)392.25 213.954 R 1.088 (allocated to the local IR making the assignment. In particular)185.385 227.954 R 4.089(,i)-.48 G 4.089(ft)498.417 227.954 S 1.089(he size of)509.838 227.954 R 1.57(the assignment is lar)185.385 241.954 R 1.57 (ger than the local IR is permitted to mak)-.216 F 1.569(e, it must be)-.12 F (appro)185.385 255.954 Q -.18(ve)-.18 G 3.845(db).18 G 3.845(yt)239.522 255.954 S .846(he RIPE NCC in adv)252.703 255.954 R 3.846(ance. The)-.3 F .846 (size of assignments a local IR)3.846 F 1.16(is permitted to mak)185.385 269.954 R 4.159(ew)-.12 G 1.159(ithout prior appro)299.896 269.954 R -.3(va) -.18 G 4.159(li).3 G 4.159(sd)408.553 269.954 S 1.159 (etermined by the local IR')423.38 269.954 R(s)-.66 E/F2 12/Times-Italic at 0 SF (assignment window)185.385 283.954 Q(,)-.888 E F1 (discussed in Section \(Assignment W)3 E(indo)-.48 E(w\).)-.3 E .402(If the ad\ dresses are to be assigned from a block not allocated to the local IR,)185.385 311.954 R 1 (the selection will be made by the IR to which the the address space is allo-) 185.385 325.954 R(cated. In general, this will be the re)185.385 339.954 Q (gional IR.)-.18 E/F3 12/Helvetica at 0 SF 3.336(3.4.2. P)72 381.954 R 3.336(Av) -1.44 G 3.336(sP)132.6 381.954 S 3.336(IS)149.94 381.954 S(pace)164.616 381.954 Q F1 .796 (The criteria used to determine the amount of address space and the re)185.385 400.154 R(gistra-)-.18 E 1.59(tion requirements are identical for P)185.385 414.154 R 4.59(Aa)-1.104 G 1.59(nd PI address space.)383.781 414.154 R -.18(Fo) 7.589 G 4.589(re).18 G(xample,)519.672 414.154 Q(re)185.385 428.154 Q -.06(ga) -.18 G .003(rdless of whether the assignment is for P).06 F 3.003(Ao)-1.104 G 3.003(rP)417.357 428.154 S 3.003(Ia)431.028 428.154 S .003 (ddress space, an assign-)443.355 428.154 R .29(ment with a pre\214x longer th\ an /24 can be made if the request can be satis\214ed)185.385 442.154 R (with less than 256 addresses.)185.385 456.154 Q 2.342(Local IRs must mak) 185.385 484.154 R 5.343(ei)-.12 G 5.343(tc)303.294 484.154 S 2.343 (lear to the user which type of address space is)317.301 484.154 R 1.43 (assigned. Clear contractual arrangements which specify the)185.385 498.154 R F2(dur)4.429 E(ation)-.18 E F1 1.429(of the)4.429 F .562 (address space assignment are mandatory for e)185.385 512.154 R -.18(ve)-.3 G .562(ry assignment of P).18 F 3.562(Aa)-1.104 G(ddress)527.34 512.154 Q 4.166 (space. Although)185.385 526.154 R 1.165 (not strictly required, it is strongly recommended that con-)4.166 F (tractual arrangements are made when assigning PI space as well.)185.385 540.154 Q -.48(Wi)185.385 568.154 S .135(th respect to aggre).48 F -.06(ga)-.18 G .135(tion, the clear adv).06 F .136(antages of assigning P)-.3 F 3.136(As) -1.104 G .136(pace man-)508.22 568.154 R .499 (date that IRs recommend its use whene)185.385 582.154 R -.18(ve)-.3 G 3.499 (rp).18 G 3.499(ossible. End)400.69 582.154 R .498(users should there-)3.499 F 1.05(fore be advised to use P)185.385 596.154 R 4.05(As)-1.104 G 1.051 (pace if it appears to be suf)321.225 596.154 R 1.051 (\214cient for their situa-)-.3 F(tion.)185.385 610.154 Q .527 (The consequences of using P)185.385 638.154 R 3.527(Ao)-1.104 G 3.527(rP) 343.888 638.154 S 3.527(Is)358.083 638.154 S .526(pace must al)370.274 638.154 R -.12(wa)-.12 G .526(ys be made clear to the).12 F .895(end user)185.385 652.154 R 6.896(.I)-.66 G 3.896(np)239.832 652.154 S(articular)255.728 652.154 Q 3.896(,t)-.48 G 3.896(ob)305.464 652.154 S 3.896(ec)321.36 652.154 S .896 (ertain end users understand the consequences)335.912 652.154 R .412 (of using P)185.385 666.154 R 3.412(As)-1.104 G .412 (pace, the assigning IR must gi)250.521 666.154 R .772 -.18(ve e)-.3 H .412 (ach user requesting P).18 F 3.411(As)-1.104 G(pace)536.016 666.154 Q 3(aw) 185.385 680.154 S(arning similar to the follo)202.257 680.154 Q(wing:)-.3 E 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 20)-.4 E EP %%Page: 21 21 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF .965(Assignment of this address space is v)215.385 87.954 R .966(alid as long as the criteria)-.3 F .15 (for the original assignment are still met and only for the duration)215.385 101.954 R .891(of the service agreement between yourself and ISP XXXX. ISP) 215.385 115.954 R 1.935 (XXXX has the right to re-assign the address space to another)215.385 129.954 R 1.331(user upon termination of the agreement or follo)215.385 143.954 R 1.331 (wing an agreed)-.3 F 4.052(period thereafter)215.385 157.954 R 10.052(.I)-.66 G 7.051(ft)315.457 157.954 S 4.051(he address space assignment becomes)329.84 157.954 R(in)215.385 171.954 Q -.3(va)-.48 G .487(lid, you may ha).3 F .847 -.18(ve t)-.24 H 3.487(or).18 G .488(e-con\214gure the addresses of all equip-) 342.608 171.954 R .074 (ment using this address space. The recon\214guration is only neces-)215.385 185.954 R 5.295(sary if you continue to require global uniqueness of the) 215.385 199.954 R .432 (addresses for that equipment. It is important to realize that some)215.385 213.954 R 1.731(Internet services do not require globally unique addresses. F) 215.385 227.954 R(or)-.18 E -.18(ex)215.385 241.954 S .751 (ample, services that can be accessed through a N).18 F 3.415 -1.332(AT \()-.42 H(netw)1.332 E(ork)-.12 E 6.63 (address translator\) or through an application layer g)215.385 255.954 R(ate-) -.06 E -.12(wa)215.385 269.954 S(y/\214re).12 E -.12(wa)-.3 G 2.096(ll don').12 F 5.096(tr)-.216 G 2.096(equire the machines which access them to)314.137 269.954 R(ha)215.385 283.954 Q .36 -.18(ve g)-.24 H(lobally unique addresses.) .18 E .169 (Of course, the consequences of using PI space must also be made clear to the) 185.385 316.154 R 2.054(end user)185.385 330.154 R 5.054(.T)-.66 G 2.053 (his is accomplished by gi)242.485 330.154 R 2.053 (ving each user requesting PI space a)-.3 F -.12(wa)185.385 344.154 S (rning similar to the follo).12 E(wing:)-.3 E .965 (Assignment of this address space is v)215.385 376.354 R .966 (alid as long as the criteria)-.3 F .399(for the original assignment are met.) 215.385 390.354 R .398(Note that the assignment of)6.399 F 1.235 (PI address space does not imply that it will be routable on an)215.385 404.354 R(y)-.18 E .843(part of the Internet. Users may ha)215.385 418.354 R 1.202 -.18 (ve t)-.24 H 3.842(op).18 G .842(ay a premium for rout-)415.324 418.354 R .639 (ing of PI addresses \(as opposed to P)215.385 432.354 R 3.639(Aa)-1.104 G 3.639(ddresses\). Ev)409.362 432.354 R(entually)-.18 E 3.639(,i)-.78 G(t) 524.664 432.354 Q 2.161(may become impossible to get relati)215.385 446.354 R -.18(ve)-.3 G 2.16(ly small amounts of PI).18 F 1.295 (space routed on most of the Internet.)215.385 460.354 R 3.215 -.96(We s)7.295 H 1.295(trongly suggest you).96 F .112(contact an)215.385 474.354 R 3.112(yp) -.18 G(rospecti)279.413 474.354 Q .472 -.18(ve s)-.3 H .112(ervice pro).18 F .112(viders for information re)-.18 F -.06(ga)-.18 G(rd-).06 E 5.292 (ing the possibility and pricing of service when using PI)215.385 488.354 R (addresses.)215.385 502.354 Q .813 (The type of assigned address space must be re)185.385 534.554 R .813 (gistered in the)-.18 F/F2 12/Times-Italic at 0 SF(status)3.813 E F1(attrib)3.813 E(ute)-.24 E .126(of the)185.385 548.554 R F2(inetnum)3.126 E F1 .127 (object in the RIPE database by the assigning IR.)3.126 F .127(The possible) 6.127 F -.3(va)185.385 562.554 S(lues of this attrib).3 E(ute are)-.24 E (ASSIGNED P)185.385 594.754 Q(A)-1.104 E .008(This is used for P)215.385 608.754 R 3.008(Aa)-1.104 G .008 (ddress space that has been assigned to an end user)315.313 608.754 R(.)-.66 E (ASSIGNED PI)185.385 640.954 Q .262 (This is used for PI address space that has been assigned to an end user) 215.385 654.954 R(.)-.66 E(Ev)185.385 687.154 Q .027(ery ne)-.18 F 3.027(wa)-.3 G .027(ddress space assignment must be mark)244.935 687.154 R .027(ed as P)-.12 F 3.027(Ao)-1.104 G 3.027(rP)481.227 687.154 S 3.026(Ii)494.922 687.154 S 3.026 (nt)505.28 687.154 S .026(he RIPE)517.642 687.154 R 3.339(database. Moreo) 185.385 701.154 R -.18(ve)-.18 G 4.299 -.48(r, t).18 H 6.339(oi).48 G(mpro) 310.866 701.154 Q 3.699 -.18(ve r)-.18 H -.18(eg).18 G 3.339 (istration of old assignments, IRs are).18 F 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 21)-.4 E EP %%Page: 22 22 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF .94(encouraged to mark past assignments in the re) 185.385 87.954 R .94(gistry database with P)-.18 F 3.94(Ao)-1.104 G 3.94(rP) 539.396 87.954 S(I)554.004 87.954 Q 1.73(as appropriate. An)185.385 101.954 R 4.73(ya)-.18 G 1.73(ssigned address space without an e)293.031 101.954 R 1.731 (xplicit type in the)-.18 F .56(status attrib)185.385 115.954 R .559 (ute is assumed to be PI space.)-.24 F .559(Priority should therefore be gi) 6.559 F -.18(ve)-.3 G(n).18 E(to marking P)185.385 129.954 Q 3(As)-1.104 G (pace as such.)262.617 129.954 Q .884(In general, local IRs are pro)185.385 157.954 R .885(vided with ranges of P)-.18 F 3.885(As)-1.104 G .885 (pace from which the)451.221 157.954 R(y)-.18 E .423(can mak)185.385 171.954 R 3.423(ea)-.12 G .423 (ssignments. If an end user requests address space of a type which)240.087 171.954 R .741(an IR does not assign \(typically PI\), the IR must refer the e\ nd user to a re)185.385 185.954 R(g-)-.18 E .57 (istry which can ful\214ll the request.)185.385 199.954 R .569 (IRs that do not assign PI space must sup-)6.569 F .321 (port an IR that does pro)185.385 213.954 R .322 (vide this service. This includes aiding the end user in)-.18 F .411 (the preparation of a properly documented request and furnishing background) 185.385 227.954 R(information to the assigning IR.)185.385 241.954 Q .247 (Local IRs which do not normally assign lar)185.385 269.954 R .248 (ge amounts of a particular type of)-.216 F .097 (address space do not need to hold an allocation of that type of)185.385 283.954 R .097(address space.)6.097 F 1.31 (It can be acquired from the RIPE NCC as needed. In general, such assign-) 185.385 297.954 R .133(ments will not be aggre)185.385 311.954 R -.06(ga)-.18 G .132(table with other address space assigned by the local).06 F(IR.)185.385 325.954 Q 1.113(IRs ha)185.385 353.954 R 1.473 -.18(ve a)-.24 H 1.113 (ssigned address space in the past which is aggre).18 F -.06(ga)-.18 G 1.114 (ted in practice).06 F -.24(bu)185.385 367.954 S 4.861(ti).24 G 4.861(sn) 208.678 367.954 S 1.86(ot formally of type P)224.207 367.954 R 1.86(A. F)-1.104 F(ormally)-.18 E 4.86(,a)-.78 G 1.86(ddress space is not of type P)403.296 367.954 R(A)-1.104 E 1.118(unless there are contractual agreements re)185.385 381.954 R -.06(ga)-.18 G 1.118(rding the assignment').06 F 4.118(st)-.66 G (ermina-)520.68 381.954 Q 4.15(tion. It)185.385 395.954 R 1.149 (is therefore recommended that IRs ask end users to release non-P)4.15 F(A) -1.104 E .123(address space upon termination of service.)185.385 409.954 R (Similarly)6.123 E 3.123(,i)-.78 G 3.123(fa)449.43 409.954 S 3.123(ne)461.877 409.954 S .124(nd user mo)476.328 409.954 R -.18(ve)-.18 G 3.124(st).18 G(o)552 409.954 Q 3.26(an)185.385 423.954 S .859 -.3(ew I)199.973 423.954 T 3.259(Rt).3 G 3.259(oo)235.519 423.954 S .259(btain Internet services, the ne)250.778 423.954 R 3.259(wI)-.3 G 3.259(Rs)408.397 423.954 S .259 (hould encourage the user to)424.328 423.954 R .177(release an)185.385 437.954 R 3.177(yn)-.18 G(on-P)248.199 437.954 Q 3.177(Aa)-1.104 G .177 (ddress space the)286.932 437.954 R 3.177(yh)-.18 G .177 (old, and to request a ne)380.259 437.954 R 3.178(wa)-.3 G(ssignment)509.328 437.954 Q .099(\(a process which the ne)185.385 451.954 R 3.099(wI)-.3 G 3.099 (Rs)313.872 451.954 S .099(hould be more than happ)329.643 451.954 R 3.099(yt) -.12 G 3.098(os)461.67 451.954 S 3.098(upport\). T)475.436 451.954 R 3.098(om) -.96 G(in-)544.668 451.954 Q 1.072(imize the use of non-P)185.385 465.954 R 4.072(As)-1.104 G 1.073(pace in the future, IRs should w)313.961 465.954 R 1.073(ork to mak)-.12 F 4.073(ec)-.12 G(on-)542.004 465.954 Q 3.302 (tractual arrangements to con)185.385 479.954 R -.18(ve)-.48 G 3.302(rt aggre) .18 F -.06(ga)-.18 G 3.301(ted address space to formal P).06 F(A)-1.104 E (address space.)185.385 493.954 Q/F2 12/Helvetica at 0 SF 3.336(3.4.3. Multihomed) 72 535.954 R(Users)3.336 E F1 1.005(An end user may ha)185.385 554.154 R 1.365 -.18(ve r)-.24 H 1.005(eason to obtain connecti).18 F 1.006 (vity through more than one)-.3 F 1.407(service pro)185.385 568.154 R(vider) -.18 E 4.407(.I)-.66 G 4.407(fs)274.995 568.154 S 1.406 (o, it may be necessary to obtain address space assign-)288.066 568.154 R .186 (ments from more than one IR to support dif)185.385 582.154 R .187 (ferent parts of the user')-.3 F 3.187(sn)-.66 G(etw)521.796 582.154 Q(ork.) -.12 E 1.273 (In general, there is no problem with users acquiring address space and ser) 185.385 596.154 R(-)-.24 E (vice from more than one IR. Such users are referred to as)185.385 610.154 Q/F3 12/Times-Italic at 0 SF(multihomed.)3 E F1 .724 (Because users can be multihomed, IRs must be especially careful in re)185.385 638.154 R(vie)-.3 E(w-)-.3 E 2.842 (ing address space requests, and the corresponding)185.385 652.154 R F3(curr) 5.841 E 2.841(ent addr)-.444 F 2.841(ess space)-.444 F(usa)185.385 666.154 Q -.12(ge)-.12 G F1 .225 (described in Section \(Current Assignment Space Usage\).)3.344 F .225 (One must be)6.225 F 1.061 (sure that users are not acquiring multiple assignments for the same purpose) 185.385 680.154 R 1.379(from dif)185.385 694.154 R 1.379(ferent IRs.)-.3 F (Moreo)7.379 E -.18(ve)-.18 G 2.339 -.48(r, o).18 H 1.379 (ne must check that a similar address space).48 F (request has not been refused by another IR for some v)185.385 708.154 Q (alid reason.)-.3 E 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 22)-.4 E EP %%Page: 23 23 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Helvetica at 0 SF 3.336(3.4.4. Update)72 87.954 R(the RIPE Database)3.336 E /F2 12/Times-Roman at 0 SF(Re)185.385 106.154 Q 2.549 (gistration of objects pertaining to an assignment in the RIPE database)-.18 F (mak)185.385 120.154 Q .272 (es it possible to track the use of address space, f)-.12 F .273 (acilitate operational con-)-.12 F .945(tacts, and f)185.385 134.154 R .945 (acilitate studies of address allocation.)-.12 F .944(These acti)6.945 F .944 (vities are essen-)-.3 F(tial to ef)185.385 148.154 Q(fecti)-.3 E .36 -.18 (ve m)-.3 H(aintenance of the Internet.).18 E 1.1(Submission of objects to the\ database is the \214nal step in making an assign-)185.385 176.154 R 4.389 (ment. This)185.385 190.154 R 1.389(step mak)4.389 F 1.389 (es the assignment de\214nite, and mak)-.12 F 1.388(es public informa-)-.12 F 2.195(tion re)185.385 204.154 R -.06(ga)-.18 G 2.195(rding the assignment a).06 F -.3(va)-.24 G 2.195(ilable to an).3 F 2.195(yone seeking it. Care should)-.18 F .399(therefore be tak)185.385 218.154 R .398 (en to assure the correctness of the assignment and of all rele-)-.12 F -.3(va) 185.385 232.154 S(nt data prior to completing this step.).3 E .671 (The information collected about the user')185.385 260.154 R 3.671(so)-.66 G -2.628 -.216(rg a)401.379 260.154 T .671(nization in the).216 F/F3 12 /Times-Italic at 0 SF .672(Network T)3.671 F(em-)-1.104 E(plate)185.385 274.154 Q F2 .903(\(see Section \(Database Information\)\), should be entered in an)3.903 F F3(inetnum)3.902 E F2 .105(database object. The range of addresses assigned \ to the user is also entered in)185.385 288.154 R(the)185.385 302.154 Q F3 (inetnum)3.89 E F2 .889(object, and is speci\214ed in dotted quad notation. F) 3.89 F .889(or e)-.18 F .889(xample, if)-.18 F .451(an or)185.385 316.154 R -.06(ga)-.216 G .451(nization is assigned a /22 address set for 1024 netw).06 F .452(ork addresses, the)-.12 F 1.709(range will be something lik)185.385 330.154 R(e:)-.12 E F3 1.709(193.1.192.0 - 193.1.195.255.)4.709 F F2 1.709 (And, as stated)7.709 F(abo)185.385 344.154 Q -.18(ve)-.18 G 4.359(,t).18 G(he) 224.376 344.154 Q F3(status)4.36 E F2 1.36 (\214eld of the inetnum object is used to specify whether the)4.36 F (assigned addresses are PI or P)185.385 358.154 Q(A.)-1.104 E .316 (In addition to the)185.385 386.154 R F3(inetnum)3.316 E F2 .316(object, a) 3.316 F F3(per)3.316 E(son)-.12 E F2 .316(object must be submitted for each) 3.316 F .22(of the people speci\214ed in the)185.385 400.154 R F3(tec)3.22 E (h-c)-.18 E F2(and)3.22 E F3(admin-c)3.22 E F2 .22(\214elds of the)3.22 F F3 (inetnum)3.22 E F2(object.)3.22 E 1.404 (Assuming the assigning IR has properly stored information g)185.385 428.154 R 1.404(athered in the)-.06 F .744 (assignment process for future reference, submission of the objects described) 185.385 442.154 R(abo)185.385 456.154 Q 1.802 -.18(ve c)-.18 H 1.442 (ompletes the assignment process.).18 F 1.441(The IR can no)7.441 F 4.441(wp) -.3 G(ro)486.646 456.154 Q 1.441(vide the end)-.18 F (user with the assigned address range and an)185.385 470.154 Q 3(yo)-.18 G (ther data rele)409.821 470.154 Q -.3(va)-.3 G(nt to its use.).3 E F1 3.336 (3.5. Assignment)72 512.154 R(Windo)3.336 E(w)-.18 E F2 2.552 (It is essential that local IR staf)185.385 530.354 R 5.552(ff)-.3 G(ollo) 359.261 530.354 Q 5.552(wt)-.3 G 2.553(he procedures for address space)395.185 530.354 R 1.289(assignments and apply the e)185.385 544.354 R -.3(va)-.3 G 1.288(luation criteria used to determine assignment).3 F .125 (sizes as discussed abo)185.385 558.354 R -.18(ve)-.18 G 6.126(.T).18 G .126 (he procedures are straightforw)318.834 558.354 R .126(ard. The e)-.12 F -.3 (va)-.3 G(luation).3 E(criteria ho)185.385 572.354 Q(we)-.3 E -.18(ve)-.3 G .96 -.48(r, c).18 H(an be dif).48 E(\214cult to apply to ne)-.3 E 3(ws)-.3 G (ituations.)424.809 572.354 Q 3.458 -.96(To a)185.385 600.354 T 1.538 (ssure the conserv).96 F 1.538(ation, aggre)-.3 F -.06(ga)-.18 G 1.538 (tion, and re).06 F 1.537(gistration goals are met, we)-.18 F .791 (must be sure the assignment criteria and procedures are properly applied. In) 185.385 614.354 R .75(general, this means that local IRs with little or no e) 185.385 628.354 R .75(xperience should recei)-.18 F -.18(ve)-.3 G 2.232 (maximal support in the assignment process, whereas local IRs with more)185.385 642.354 R -.18(ex)185.385 656.354 S .99(perience should be allo).18 F .99 (wed to mak)-.3 F 3.99(em)-.12 G .989(ost assignments without consulting) 386.685 656.354 R .796(the RIPE NCC. Lar)185.385 670.354 R .796 (ge assignments al)-.216 F -.12(wa)-.12 G .796(ys require prior appro).12 F -.3 (va)-.18 G 3.796(lb).3 G .796(ecause of)512.228 670.354 R (their impact on the a)185.385 684.354 Q -.3(va)-.24 G(ilable address space.).3 E 6.451 -.96(To a)185.385 712.354 T(chie).96 E 4.891 -.18(ve t)-.3 H 4.531 (his v).18 F 4.53(ariation in support le)-.3 F -.18(ve)-.3 G 4.53 (l, each local IR is gi).18 F -.18(ve)-.3 G 7.53(na).18 G(n)552 712.354 Q 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 23)-.4 E EP %%Page: 24 24 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Italic at 0 SF .567(assignment window)185.385 87.954 R/F2 12 /Times-Roman at 0 SF .567(by the RIPE NCC. The assignment windo)3.567 F 3.568(wi) -.3 G 3.568(st)503.536 87.954 S .568(he maxi-)515.108 87.954 R .201 (mum number of addresses that can be assigned by the local IR to an end user) 185.385 101.954 R .198(without prior appro)185.385 115.954 R -.3(va)-.18 G 3.198(lb).3 G 3.198(yt)302.487 115.954 S .198 (he RIPE NCC. The number of addresses is al)315.021 115.954 R -.12(wa)-.12 G (ys).12 E -.18(ex)185.385 129.954 S .485 (pressed in /xx notation, so a local IR with an assignment windo).18 F 3.484 (wo)-.3 G 3.484(f/)523.696 129.954 S .484(23 is)534.512 129.954 R(allo)185.385 143.954 Q .906 (wed to assign up to 512 addresses to an end user without prior appro)-.3 F -.3 (va)-.18 G(l).3 E .703(of the RIPE NCC.)185.385 157.954 R .703 (As the local IR staf)6.703 F 3.703(fg)-.3 G .703(ain e)390.337 157.954 R .703 (xperience, the windo)-.18 F 3.703(ws)-.3 G .703(ize is)532.301 157.954 R (increased.)185.385 171.954 Q(Ev)185.385 199.954 Q .312 (ery assignment of address space which is lar)-.18 F .312 (ger than the local IR')-.216 F 3.313(sa)-.66 G(ssign-)529.332 199.954 Q .376 (ment windo)185.385 213.954 R 3.376(wi)-.3 G 3.376(si)257.837 213.954 S -2.34 -.48(nv a)269.217 213.954 T .375(lid prior to e).48 F .375(xplicit appro)-.18 F -.3(va)-.18 G 3.375(lb).3 G 3.375(yt)431.304 213.954 S .375(he RIPE NCC. W) 444.015 213.954 R(ithout)-.48 E 1.734(such appro)185.385 227.954 R -.3(va)-.18 G 1.734(l, the address space should not be used to address hosts with).3 F .103 (Internet connecti)185.385 241.954 R(vity)-.3 E 3.103(.U)-.78 G .103(se of in) 298.823 241.954 R -.3(va)-.48 G .103(lid address can result in a f).3 F .102 (ailure to meet the)-.12 F(uniqueness requirement for Internet addresses.) 185.385 255.954 Q .434(The assignment windo)185.385 283.954 R 3.434(wi)-.3 G 3.434(sn)310.047 283.954 S .434(ot only applied to indi)324.149 283.954 R .435 (vidual assignments, b)-.3 F .435(ut to)-.24 F 1.571 (multiple assignments to the same end user in a single year)185.385 297.954 R 7.57(.I)-.66 G 4.57(fa)493.638 297.954 S 4.57(nl)507.532 297.954 S 1.57 (ocal IR)521.438 297.954 R(mak)185.385 311.954 Q .935 (es combined assignments to an or)-.12 F -.06(ga)-.216 G .935 (nization in the course of a year).06 F 3.936(,t)-.48 G(he)546.672 311.954 Q .349(total amount of address space assigned may not e)185.385 325.954 R .349 (xceed the local IR')-.18 F 3.349(sa)-.66 G(ssign-)529.332 325.954 Q .517 (ment windo)185.385 339.954 R 5.077 -.78(w. A)-.3 H .517 (dditional address space can only be assigned to that or).78 F -.06(ga)-.216 G (ni-).06 E(zation after appro)185.385 353.954 Q -.3(va)-.18 G 3(lb).3 G 3(yt) 293.205 353.954 S(he RIPE NCC.)305.541 353.954 Q 1.399 (In general the assignment windo)185.385 381.954 R 4.398(wf)-.3 G 1.398(or ne) 363.714 381.954 R 4.398(wr)-.3 G -.18(eg)406.194 381.954 S 1.398(istries is 0.) .18 F 1.398(This means that)7.398 F -2.58 -.3(ev e)185.385 395.954 T .364 (ry assignment requires prior appro).3 F -.3(va)-.18 G 3.364(lb).3 G 3.364(yt) 391.864 395.954 S .364(he RIPE NCC before becoming)404.564 395.954 R(ef)185.385 409.954 Q(fecti)-.3 E -.18(ve)-.3 G 3.015(.T).18 G .014 (his ensures that the local IR staf)239.928 409.954 R 3.014(fb)-.3 G .014 (ecome f)406.036 409.954 R .014(amiliar with the e)-.12 F -.3(va)-.3 G(lua-).3 E(tion criteria and assignment procedures described in this document.)185.385 423.954 Q .039(As the local IR staf)185.385 451.954 R 3.039(fb)-.3 G .04 (ecome f)290.928 451.954 R .04(amiliar with assignment procedures, the assign-) -.12 F .642(ment windo)185.385 465.954 R 3.642(wc)-.3 G .642 (an be raised. In general, it will be raised to /24 the \214rst time,)260.361 465.954 R 4.257(which means the local IR staf)185.385 479.954 R 7.257(fc)-.3 G 4.257(an mak)365.259 479.954 R 7.257(ea)-.12 G 4.258(ssignments for up to 256) 422.301 479.954 R 3.82(addresses. If)185.385 493.954 R .819(the RIPE NCC recei) 3.82 F -.18(ve)-.3 G 3.819(sar).18 G .819(equest to raise the assignment win-) 385.593 493.954 R(do)185.385 507.954 Q 3.784(wf)-.3 G .784 (or a local IR, it will be e)213.529 507.954 R -.3(va)-.3 G .784 (luated based on the pro\214cienc).3 F 3.785(yo)-.18 G 3.785(ft)508.442 507.954 S .785(he local)519.559 507.954 R 2.218(IR staf)185.385 521.954 R 5.218 (f. This)-.3 F 2.218(is determined based on whether assignment documentation) 5.218 F .499 (presented to the RIPE NCC is correctly completed, whether good judgement) 185.385 535.954 R 1.841(is sho)185.385 549.954 R 1.841(wn in the e)-.3 F -.3 (va)-.3 G 1.84(luation of address space requests, whether past assign-).3 F 1.374(ments ha)185.385 563.954 R 1.734 -.18(ve b)-.24 H 1.374(een properly re) .18 F 1.374(gistered, and on the e)-.18 F 1.375(xperience of the local IR)-.18 F 3.886(with handling lar)185.385 577.954 R 3.886(ger assignments.)-.216 F (Currently)9.886 E 6.886(,t)-.78 G 3.885(he maximum size of the)427.139 577.954 R .289(assignment windo)185.385 591.954 R 3.289(wf)-.3 G .289(or an)288.323 591.954 R 3.289(yl)-.18 G .289 (ocal IR is 4096 addresses \(/20\). This means that)325.381 591.954 R -2.58 -.3 (ev e)185.385 605.954 T(ry assignment for more than this requires appro).3 E -.3(va)-.18 G 3(lo).3 G 3(ft)452.373 605.954 S(he RIPE NCC.)462.705 605.954 Q 1.265(Sometimes ne)185.385 633.954 R 4.265(wr)-.3 G -.18(eg)270.943 633.954 S 1.265(istration staf).18 F 4.265(fa)-.3 G 4.265(taw)356.309 633.954 S 1.264 (ell established local IR mak)382.167 633.954 R 4.264(ee)-.12 G(rrors)535.344 633.954 Q 1.636(both in judgement and procedure before the)185.385 647.954 R 4.637(ya)-.18 G 1.637(re properly trained to mak)420.94 647.954 R(e)-.12 E 4.636(assignments. If)185.385 661.954 R 1.635 (such errors are noticed by the RIPE NCC, the assignment)4.636 F(windo)185.385 675.954 Q 3.931(wf)-.3 G .931(or the local IR may be decreased to pre)231.676 675.954 R -.18(ve)-.3 G .932(nt the staf).18 F 3.932(ff)-.3 G .932(rom making) 498.736 675.954 R 1.079(erroneous assignments in)185.385 689.954 R -.24(vo)-.48 G 1.079(lving a substantial amount of address space.).24 F(As)7.079 E .68 (the ne)185.385 703.954 R 3.68(ws)-.3 G(taf)231.769 703.954 Q 3.68(fm)-.3 G .68 (embers recei)261.141 703.954 R 1.04 -.18(ve t)-.3 H .68 (raining, and the pro\214cienc).18 F 3.68(yl)-.18 G -2.58 -.3(ev e)481.509 703.954 T 3.681(li).3 G 3.681(sa)508.038 703.954 S -.06(ga)521.715 703.954 S .681(in up).06 F 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 24)-.4 E EP %%Page: 25 25 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF .393(to par)185.385 87.954 R 3.393(,t)-.48 G .393 (he assignment windo)222.687 87.954 R 3.392(wc)-.3 G .392 (an be increased just as it w)341.884 87.954 R .392(ould be for a ne)-.12 F(w) -.3 E(local IR.)185.385 101.954 Q 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 25)-.4 E EP %%Page: 26 26 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Helvetica at 0 SF 3.336(4. Rules)72 87.954 R(and Guidelines f)3.336 E (or Allocations)-.36 E/F2 12/Times-Roman at 0 SF .03(In the pre)185.385 106.154 R .031(vious section, we described the procedures for handling requests for)-.3 F .193 (address space, including the selection of a set of addresses for an end user) 185.385 120.154 R 3.193(.I)-.66 G(n)552 120.154 Q 1.396 (completing the assignment, address space is selected from a range that has) 185.385 134.154 R(been)185.385 148.154 Q/F3 12/Times-Italic at 0 SF(allocated)3.74 E F2 .74(to the local IR for this purpose.)3.74 F .74 (Of course, before a local IR)6.74 F .342 (can select addresses to ful\214ll a request, it must ha)185.385 162.154 R .702 -.18(ve a r)-.24 H .343(ange of address space).18 F .387(to choose from.) 185.385 176.154 R .387(\(If the local IR does not ha)6.387 F .747 -.18(ve s) -.24 H(uf).18 E .386(\214cient address space of the)-.3 F (type to be assigned, then a request can be submitted to the RIPE NCC.\)) 185.385 190.154 Q 2.202 -.96(To m)185.385 218.154 T .283 (eet this need, a range of addresses is made a).96 F -.3(va)-.24 G .283 (ilable to a local IR by the).3 F .232 (RIPE NCC. Such an address range is referred to as an)185.385 232.154 R F3 (allocation.)3.232 E F2 .231(In Europe,)6.232 F .499 (the RIPE NCC is the only IR permitted to allocate address space. A local IR) 185.385 246.154 R 1.203(is not allo)185.385 260.154 R 1.202 (wed to re-allocate part of its allocation to an)-.3 F 4.202(yo)-.18 G 1.202 (ther or)472.426 260.154 R -.06(ga)-.216 G(nization.).06 E(Moreo)185.385 274.154 Q -.18(ve)-.18 G 1.458 -.48(r, w).18 H .498(ithout prior appro).48 F -.3(va)-.18 G 3.498(lb).3 G 3.498(yt)356.361 274.154 S .498 (he NCC, local IRs are not permitted to)369.195 274.154 R -.18(ex)185.385 288.154 S(change allocated address space among themselv).18 E(es.)-.18 E .56 (In some cases, a local IR acts as a transit pro)185.385 316.154 R .56 (vider for an IP service pro)-.18 F(vider)-.18 E .233 (which itself is not a local IR.)185.385 330.154 R .233(If a local IR allo) 6.233 F .233(ws another IP service pro)-.3 F(vider)-.18 E 1.035(to mak)185.385 344.154 R 4.034(ea)-.12 G 4.034(na)233.99 344.154 S 1.034 (ssignment from its allocated address space, the local IR is still)249.352 344.154 R .867 (responsible to guarantee the assignment is made according to the guidelines) 185.385 358.154 R(speci\214ed in this document.)185.385 372.154 Q .944 (If at some point, an IP service pro)185.385 400.154 R .944 (vider decides to become a local IR rather)-.18 F 1.208(than using an e)185.385 414.154 R 1.208(xisting local IR to obtain address space, then all subsequent) -.18 F 1.677(assignments it mak)185.385 428.154 R 1.677 (es should be from address space allocated directly to it)-.12 F .485 (from the RIPE NCC.)185.385 442.154 R .486 (Furthermore, address space already assigned by the IP)6.486 F(pro)185.385 456.154 Q 1.036(vider from transit pro)-.18 F 1.036 (viders' allocations should be returned to the transit)-.18 F(pro)185.385 470.154 Q(vider)-.18 E 3.148(,a)-.48 G .148(nd ne)236.857 470.154 R 3.149(wa) -.3 G .149(ssignments should be made to the end users from the ne)280.174 470.154 R(w)-.3 E(allocation.)185.385 484.154 Q .592 (In this section, we describe ho)185.385 512.154 R 3.592(wal)-.3 G .591 (ocal IR can obtain an allocation and ho)357.865 512.154 R(w)-.3 E (allocated address space should be managed.)185.385 526.154 Q F1 3.336 (4.1. Slo)72 568.154 R 3.336(wS)-.18 G -2.856(tar t)135.852 568.154 R (of Allocations)3.336 E F2 3.315 -.96(To p)185.385 586.354 T(re).96 E -.18(ve) -.3 G 1.395(nt allocating lar).18 F 1.396(ge blocks of address space that w) -.216 F(on')-.12 E 4.396(tb)-.216 G 4.396(ea)503.948 586.354 S(ssigned,)519 586.354 Q 1.97(the RIPE NCC has introduced the concept of a)185.385 600.354 R F3 1.97(slow start)4.97 F F2 1.97(for allocations.)4.97 F 2.956 (The idea is to allocate address space to local IRs at the rate it will be) 185.385 614.354 R 1.552 (assigned. The minimum allocation is /19 \(8192 addresses\).)185.385 628.354 R 1.552(The maximum)7.552 F .637(size of an indi)185.385 642.354 R .637 (vidual allocation is /16 \(65536 addresses\).)-.3 F .638(The size of alloca-) 6.637 F 1.192(tions is based solely on the rate that pre)185.385 656.354 R 1.192(viously allocated address space has)-.3 F 1.114 (been assigned to end users.)185.385 670.354 R 1.114 (It will be increased or decreased depending on)7.114 F (the rate at which a local IR assigns its space.)185.385 684.354 Q .917 (The slo)185.385 712.354 R 3.917(ws)-.3 G .917 (tart mechanism implements a consistent and f)238.915 712.354 R .916(air polic) -.12 F 3.916(yf)-.18 G .916(or e)517.916 712.354 R -.18(ve)-.3 G(ry).18 E 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 26)-.4 E EP %%Page: 27 27 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Times-Roman at 0 SF 1.481(local IR with respect to allocations.)185.385 87.954 R 1.482(Although the mechanism is similar to)7.482 F 2.362 (the assignment windo)185.385 101.954 R 5.362(wm)-.3 G 2.362 (echanism described in the pre)317.835 101.954 R 2.361(vious section, the)-.3 F (polic)185.385 115.954 Q 5.381(yi)-.18 G 5.381(ti)223.922 115.954 S 2.381 (mplements is dif)235.975 115.954 R 5.381(ferent. The)-.3 F 2.381 (size of further allocations depends)5.381 F -.18(ex)185.385 129.954 S(clusi) .18 E -.18(ve)-.3 G 3.304 (ly on the assignment rate of the local IR concerned while the).18 F .851 (assignment windo)185.385 143.954 R 3.851(wd)-.3 G .851 (epends on the demonstrated pro\214cienc)291.451 143.954 R 3.851(yo)-.18 G 3.851(ft)495.158 143.954 S .851(he re)506.341 143.954 R(gistry)-.18 E(staf) 185.385 157.954 Q 3(fi)-.3 G 3(ne)212.745 157.954 S -.3(va)226.773 157.954 S (luating requests and processing assignments.).3 E/F2 12/Helvetica at 0 SF 3.336 (4.2. First)72 199.954 R(Allocation)3.336 E F1 1.133(When a ne)185.385 218.154 R 4.133(wl)-.3 G 1.132 (ocal IR starts up, it has no address space allocated to it.)254.796 218.154 R (The)7.132 E .3 (\214rst allocation will be made automatically by the RIPE NCC, generally upon) 185.385 232.154 R .668(receipt of the \214rst assignment request from the loca\ l IR. Because there is no)185.385 246.154 R .285 (information about the rate at which a ne)185.385 260.154 R 3.285(wI)-.3 G 3.285(Rw)394.653 260.154 S .286(ill mak)414.606 260.154 R 3.286(ea)-.12 G .286 (ddress assignments,)462.386 260.154 R (the size of the \214rst allocation is al)185.385 274.154 Q -.12(wa)-.12 G (ys set at the minimum.).12 E .557 (Remember that the amount of space allocated does not determine the size of) 185.385 302.154 R 1.545(assignments a local IR can mak)185.385 316.154 R 4.545 (e. As)-.12 F 1.546(discussed at the end of the pre)4.545 F(vious)-.3 E 1.381 (section, a ne)185.385 330.154 R 4.381(wl)-.3 G 1.38(ocal IR must ha)263.88 330.154 R 1.74 -.18(ve e)-.24 H -.18(ve)-.12 G 1.38(ry assignment appro).18 F -.18(ve)-.18 G 4.38(db).18 G 4.38(yt)502.572 330.154 S 1.38(he RIPE)516.288 330.154 R(NCC until its assignment windo)185.385 344.154 Q 3(wi)-.3 G 3(si) 354.105 344.154 S(ncreased.)365.109 344.154 Q F2 3.336(4.3. Fur)72 386.154 R (ther Allocations).48 E F1 3.528(Al)185.385 404.354 S .528 (ocal IR can obtain additional allocations as required. A request should be) 200.913 404.354 R 1.787 (submitted to the RIPE NCC when the currently allocated address space is) 185.385 418.354 R .185(nearly used up, or if a single request requires a lar) 185.385 432.354 R .186(ger block of addresses than)-.216 F 1.135 (can be satis\214ed with the currently allocated address space. T)185.385 446.354 R 4.135(oo)-.96 G 1.135(btain a ne)500.71 446.354 R(w)-.3 E 3.08 (allocation, a local IR should submit a request to the RIPE NCC which)185.385 460.354 R .082(includes a complete list of the assignments made from all of th\ eir allocations.)185.385 474.354 R 2.163 (The RIPE NCC will check this information, compare it with assignments)185.385 488.354 R(re)185.385 502.354 Q 1.088 (gistered in the database and may request further information to determine)-.18 F .056(the need for a ne)185.385 516.354 R 3.056(wa)-.3 G .056 (llocation. Additional address space will be allocated after)282.325 516.354 R .666(the information deli)185.385 530.354 R -.18(ve)-.3 G .665 (red with the request has been v).18 F .665(eri\214ed, and a ne)-.18 F 3.665 (wa)-.3 G(llo-)541.332 530.354 Q(cation has been deemed necessary)185.385 544.354 Q(.)-.78 E(Unfortunately)185.385 586.354 Q 4.296(,t)-.78 G 1.296 (here is a tradeof)262.557 586.354 R 4.296(fb)-.3 G 1.296(etween the aggre) 357.405 586.354 R -.06(ga)-.18 G 1.297(tion and conserv).06 F(ation)-.3 E 1.107 (goals in making allocations. T)185.385 600.354 R 4.107(of)-.96 G 1.106 (urther aggre)347.952 600.354 R -.06(ga)-.18 G 1.106 (tion, the RIPE NCC aims to).06 F .228 (allocate contiguous address ranges to a local IR. Ho)185.385 614.354 R(we)-.3 E -.18(ve)-.3 G 1.189 -.48(r, b).18 H .229(ecause conserv).48 F(a-)-.3 E .43 (tion of address space must also be tak)185.385 628.354 R .429 (en into account, this is not al)-.12 F -.12(wa)-.12 G .429(ys pos-).12 F 3.288 (sible. A)185.385 642.354 R(ne)3.288 E 3.288(wa)-.3 G .288(llocation to a re) 257.601 642.354 R .288(gistry can therefore not be e)-.18 F .289 (xpected to be con-)-.18 F 1.473 (tiguous with past allocations. While the RIPE NCC al)185.385 656.354 R -.12 (wa)-.12 G 1.473(ys aims to further).12 F 1.76(the aggre)185.385 670.354 R -.06 (ga)-.18 G 1.761(tion goal, and therefore to allocate contiguous space,).06 F /F3 12/Times-Italic at 0 SF 1.761(the RIPE)4.761 F 1.563 (policy is that under no cir)185.385 684.354 R 1.562(cumstances ar)-.444 F 4.562(em)-.444 G 1.562(ultiple allocations made to the)405.748 684.354 R (same local IR guar)185.385 698.354 Q(anteed to be contiguous.)-.18 E 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 27)-.4 E EP %%Page: 28 28 %%BeginPageSetup BP %%EndPageSetup 6 699 72 122 -50.754 86 72 64.754 PBEGIN %%BeginDocument: /home/dfk/tgif/ripe-ncc.eps %%BoundingBox: 6 699 128 785 %%Title: ripe-ncc %%CreationDate: Wed Apr 26 16:57:17 1995 %%Creator: Tgif-2.14-p9 by William Chia-Wei Cheng (william at cs.UCLA.edu) %%Pages: 1 %%DocumentFonts: (atend) %%EndComments %%BeginProlog % /tgifdict 132 dict def tgifdict begin % % Using a zero value radius for an ellipse or an arc would result % in a non-invertible CTM matrix which causes problem when this % when this PostScript is wrapped inside other routines, such as % the multi.ps package from % ftp.ucc.su.oz.au:/pub/ps_printing/multi. You can overcome such % error by uncommenting the sole line of the procedure below: % /tgif_min_radius { % dup 0.01 lt { pop 0.01 } if } bind def /tgifellipsedict 6 dict def tgifellipsedict /mtrx matrix put /tgifellipse { tgifellipsedict begin /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 0 360 arc savematrix setmatrix end } def /tgifarrowtipdict 8 dict def tgifarrowtipdict /mtrx matrix put /tgifarrowtip { tgifarrowtipdict begin /dy exch def /dx exch def /h exch def /w exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate dy dx atan rotate 0 0 moveto w neg h lineto w neg h neg lineto savematrix setmatrix end } def /tgifarcdict 8 dict def tgifarcdict /mtrx matrix put /tgifarcn { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arc savematrix setmatrix end } def /tgifarc { tgifarcdict begin /endangle exch def /startangle exch def /yrad exch def /xrad exch def /y exch def /x exch def /savematrix mtrx currentmatrix def x y translate xrad yrad scale 0 0 1 startangle endangle arcn savematrix setmatrix end } def /tgifsetuserscreendict 22 dict def tgifsetuserscreendict begin /tempctm matrix def /temprot matrix def /tempscale matrix def /concatprocs { /proc2 exch cvlit def /proc1 exch cvlit def /newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx } def /resmatrix matrix def /findresolution { 72 0 resmatrix defaultmatrix dtransform /yres exch def /xres exch def xres dup mul yres dup mul add sqrt } def end /tgifsetuserscreen { tgifsetuserscreendict begin /spotfunction exch def /screenangle exch def /cellsize exch def /m tempctm currentmatrix def /rm screenangle temprot rotate def /sm cellsize dup tempscale scale def sm rm m m concatmatrix m concatmatrix pop 1 0 m dtransform /y1 exch def /x1 exch def /veclength x1 dup mul y1 dup mul add sqrt def /frequency findresolution veclength div def /newscreenangle y1 x1 atan def m 2 get m 1 get mul m 0 get m 3 get mul sub 0 gt {{neg} /spotfunction load concatprocs /spotfunction exch def } if frequency newscreenangle /spotfunction load setscreen end } def /tgifsetpatterndict 18 dict def tgifsetpatterndict begin /bitison { /ybit exch def /xbit exch def /bytevalue bstring ybit bwidth mul xbit 8 idiv add get def /mask 1 7 xbit 8 mod sub bitshift def bytevalue mask and 0 ne } def end /tgifbitpatternspotfunction { tgifsetpatterndict begin /y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def xindex yindex bitison { /onbits onbits 1 add def 1 } { /offbits offbits 1 add def 0 } ifelse end } def /tgifsetpattern { tgifsetpatterndict begin /cellsz exch def /angle exch def /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def cellsz angle /tgifbitpatternspotfunction load tgifsetuserscreen {} settransfer offbits offbits onbits add div setgray end } def /tgifxpmdict 4 dict def /tgifbwpicstr 1 string def /tgifcolorpicstr 3 string def /tgifsetpixels { tgifxpmdict begin /pixels exch def end } def /tgifsetpix { tgifxpmdict begin pixels 3 1 roll putinterval end } def /tgifbwspot { tgifxpmdict begin /index exch def tgifbwpicstr 0 pixels index 3 mul 3 getinterval aload pop 255 mul .114 mul exch 255 mul .587 mul add exch 255 mul .299 mul add cvi put tgifbwpicstr end } def /tgifcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop 255 mul cvi tgifcolorpicstr 2 3 -1 roll put 255 mul cvi tgifcolorpicstr 1 3 -1 roll put 255 mul cvi tgifcolorpicstr 0 3 -1 roll put tgifcolorpicstr end } def /tgifnewcolorspot { tgifxpmdict begin /index exch def pixels index 3 mul 3 getinterval aload pop setrgbcolor end } def /tgifcolordict 4 dict def /colorimage where { pop } { /colorimage { tgifcolordict begin pop pop pop pop pop /ih exch def /iw exch def /x 0 def /y 0 def 1 1 ih { pop 1 1 iw { pop currentfile tgifbwpicstr readhexstring pop 0 get tgifnewcolorspot x y moveto 1 0 rlineto 0 1 rlineto -1 0 rlineto closepath fill /x x 1 add def } for /y y 1 add def /x 0 def } for end } def } ifelse /tgifpatdict 10 dict def /tgifpatbyte { currentdict /retstr get exch pat i cellsz mod get put } def /tgifpatproc { 0 1 widthlim {tgifpatbyte} for retstr /i i 1 add def } def /tgifpatfill { tgifpatdict begin /h exch def /w exch def /lty exch def /ltx exch def /cellsz exch def /pat exch def /widthlim w cellsz div cvi 1 sub def /retstr widthlim 1 add string def /i 0 def ltx lty translate w h true [1 0 0 1 0 0] {tgifpatproc} imagemask ltx neg lty neg translate end } def /pat1 def /pat2 <0000000000000000> def /pat3 <8000000008000000> def /pat4 <8800000022000000> def /pat5 <8800220088002200> def /pat6 <8822882288228822> def /pat7 def /pat8 <77dd77dd77dd77dd> def /pat9 <77ffddff77ffddff> def /pat10 <77ffffff77ffffff> def /pat11 <7fffffff7fffffff> def /pat12 <8040200002040800> def /pat13 <40a00000040a0000> def /pat14 def /pat15 def /pat16 def /pat17 <038448300c020101> def /pat18 <081c22c180010204> def /pat19 <8080413e080814e3> def /pat20 <8040201008040201> def /pat21 <8844221188442211> def /pat22 <77bbddee77bbddee> def /pat23 def /pat24 <7fbfdfeff7fbfdfe> def /pat25 <3e1f8fc7e3f1f87c> def /pat26 <0102040810204080> def /pat27 <1122448811224488> def /pat28 def /pat29 <83070e1c3870e0c1> def /pat30 def /pat31 <7cf8f1e3c78f1f3e> def /tgifcentertext { dup stringwidth pop 2 div neg 0 rmoveto } def /tgifrighttext { dup stringwidth pop neg 0 rmoveto } def /tgifreencsmalldict 12 dict def /tgifReEncodeSmall { tgifreencsmalldict begin /newcodesandnames exch def /newfontname exch def /basefontname exch def /basefontdict basefontname findfont def /newfont basefontdict maxlength dict def basefontdict { exch dup /FID ne { dup /Encoding eq { exch dup length array copy newfont 3 1 roll put } { exch newfont 3 1 roll put } ifelse } { pop pop } ifelse } forall newfont /FontName newfontname put newcodesandnames aload pop newcodesandnames length 2 idiv { newfont /Encoding get 3 1 roll put} repeat newfontname newfont definefont pop end } def /tgifgray { 8 1 0 72 300 32 div div tgifsetpattern } bind def /tgifboxdict 6 dict def /tgifboxstroke { tgifboxdict begin /pat def /w def /y2 exch def /x2 exch def /y1 exch def /x1 exch def 1.415 setmiterlimit w 1 eq { w setlinewidth } if pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray stroke 0 setgray } { stroke } ifelse pat pat1 ne pat pat2 ne and { grestore } if w 1 eq { 1 setlinewidth } if 1 setmiterlimit end } def /tgifboxfill { tgifboxdict begin /pat def /y2 exch def /x2 exch def /y1 exch def /x1 exch def pat pat1 ne pat pat2 ne and { gsave pat tgifgray } if newpath x1 y1 moveto x2 y1 lineto x2 y2 lineto x1 y2 lineto closepath pat pat2 eq { 1 setgray fill 0 setgray } { fill } ifelse pat pat1 ne pat pat2 ne and { grestore } if end } def end %%PageBoundingBox: 6 699 128 785 tgifdict begin /tgifsavedpage save def 1 setmiterlimit 1 setlinewidth 72 0 mul 72 11 mul translate 72 128 div 100 mul 100 div dup neg scale gsave % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 16 63 moveto (RIPE) show grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 112 16 moveto 112 144 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 16 80 moveto 208 80 lineto stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 128 32 moveto 128 160 lineto pat6 8 1 0 72 300 32 div div tgifsetpattern stroke 1 setlinewidth grestore % POLY/OPEN-SPLINE gsave 7 setlinewidth newpath 32 96 moveto 224 96 lineto stroke 1 setlinewidth grestore % TEXT 0 setgray /Helvetica-Bold findfont [34 0 0 -34 0 0] makefont setfont gsave 182 139 moveto (ncc) tgifcentertext show grestore grestore tgifsavedpage restore end %MatchingCreationDate: Wed Apr 26 16:57:17 1995 %%DocumentFonts: Helvetica-Bold %%EOF %%EndDocument end PEND 72 64.754 EBEGIN gsave newpath EEND 72 64.754 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF(European IR - P)326.98 34.754 Q (olicies and Procedures - V)-.5 E(ersion 0.1)-.8 E(Or)429.74 46.754 Q(ange)-.1 E 2.78(,K)-.15 G(uehne)474.77 46.754 Q 2.78(,K)-.15 G(arrenberg)514.65 46.754 Q /F1 12/Helvetica at 0 SF 3.336(4.4. Allocation)72 87.954 R(Registr)3.336 E(ation) -.12 E/F2 12/Times-Roman at 0 SF 1.137(Allocations are re)185.385 106.154 R 1.137 (gistered in the RIPE Database by the NCC using)-.18 F/F3 12/Times-Italic at 0 SF (inetnum)4.137 E F2 4.23(objects. Information)185.385 120.154 R 1.23 (about the local IR, which is similar to that for an end)4.23 F 1.574 (user recei)185.385 134.154 R 1.574 (ving an assignment is stored together with the range of allocated)-.3 F 1.105 (address space and its type.)185.385 148.154 R 1.104 (The range of addresses is stored in the)7.104 F F3(inetnum)4.104 E F2 .264 (\214eld in dotted quad notation, and the type is stored in the)185.385 162.154 R F3(status)3.264 E F2 .265(\214eld and can)3.265 F(ha)185.385 176.154 Q .36 -.18(ve o)-.24 H(ne of the follo).18 E(wing v)-.3 E(alues:)-.3 E(ALLOCA)185.385 208.354 Q(TED P)-1.332 E(A)-1.104 E 1.819 (This address space has been allocated to an IR, and all assignments)215.385 222.354 R .28(made from it are pro)215.385 236.354 R .281(vider aggre)-.18 F -.06(ga)-.18 G .281(table. This is the most common allo-).06 F (cation type for local IRs.)215.385 250.354 Q(ALLOCA)185.385 282.554 Q(TED PI) -1.332 E 1.819 (This address space has been allocated to an IR, and all assignments)215.385 296.554 R(made from it are pro)215.385 310.554 Q(vider independent.)-.18 E (ALLOCA)185.385 342.754 Q(TED UNSPECIFIED)-1.332 E .547 (This address space has been allocated to an IR, and assignments made)215.385 356.754 R 1.403(from it may be either pro)215.385 370.754 R 1.403(vider aggre) -.18 F -.06(ga)-.18 G 1.403(table or pro).06 F 1.403(vider independent.)-.18 F F3 1.735(This type of allocation is obsolete)215.385 384.754 R 4.735(,a)-.12 G 1.735(nd will not be applied to futur)399.351 384.754 R(e)-.444 E .277 (allocations. Some older allocations have been used for both P)215.385 398.754 R 3.277(Aa)-1.08 G .277(nd PI)531.395 398.754 R(assignments, and as suc)215.385 412.754 Q 3(hr)-.18 G(eceive this allocation type)343.761 412.754 Q(.)-.18 E F2 1.569(These objects are maintained by the RIPE NCC. When hierarchical autho-) 185.385 444.954 R 2.075 (rization is implemented, authorization can be implemented for creation of) 185.385 458.954 R(inetnum objects "under" the allocation objects.)185.385 472.954 Q 72 718.2 EBEGIN gsave newpath EEND 72 718.2 EBEGIN 113385 u 0 rmoveto 372615 u 0 rlineto 0 5669 u rlineto -372615 u 0 rlineto 0 -5669 u rlineto closepath fill grestore EEND/F0 10/Helvetica at 0 SF .15(ri)185.385 737.869 S 271.135(pe-104++.ps P)-.15 F (age 28)-.4 E EP %%Trailer end %%EOF From erik-jan.bos at surfnet.nl Mon Jan 22 22:23:19 1996 From: erik-jan.bos at surfnet.nl (Erik-Jan Bos) Date: Mon, 22 Jan 1996 22:23:19 +0100 Subject: Question on "Network Number Usage Survey" Message-ID: <9148.822345799@SURFnet.nl> PIER, as contact person for a block of addresses, registered in the data bases of The InterNIC, I get many many "Network Number Usage Survey"s. The first ten-or-so I answered. However, I just received another dozen or so. When I would have been the official contact for all of these networks I surely would have answered all individual messages. However, all of these networks are in use in Europe, hence the data in the InterNIC data bases is not authoritative IMHO. For Europe, this information should be gathered from the RIPE data bases (whois.ripe.net). In the RIPE data base, in which SURFnet stores *all* of its information regarding networks, all correct contact persons can be found. Could you please query the RIPE data base as well, for networks in use in Europe?! Thanks. __ Erik-Jan. From bmanning at ISI.EDU Tue Jan 23 10:01:29 1996 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 23 Jan 1996 01:01:29 -0800 (PST) Subject: Question on "Network Number Usage Survey" In-Reply-To: <9148.822345799@SURFnet.nl> from "Erik-Jan Bos" at Jan 22, 96 10:23:19 pm Message-ID: <199601230901.AA06219@zed.isi.edu> > > PIER, > > as contact person for a block of addresses, registered in the data > bases of The InterNIC, I get many many "Network Number Usage Survey"s. > The first ten-or-so I answered. However, I just received another dozen > or so. > > When I would have been the official contact for all of these networks I > surely would have answered all individual messages. However, all of > these networks are in use in Europe, hence the data in the InterNIC > data bases is not authoritative IMHO. For Europe, this information > should be gathered from the RIPE data bases (whois.ripe.net). > > In the RIPE data base, in which SURFnet stores *all* of its information > regarding networks, all correct contact persons can be found. > > Could you please query the RIPE data base as well, for networks in use in > Europe?! Thanks. > > Erik-Jan. > Hi, It's just me, Suzane, and the robot. The robot took a snapshot of the InterNic database of delegated blocks and sent/is sending the can'ed email to the listed coordinator for every delegated prefix in the 192.x.x.x range. Note that this is only being done for prefixes in the 192/8 range. As far as I can tell, RIPE NCC was never delegated this block. People are, of course, free to register their delegations, from what ever source, into their routing registry of choice. The intent was to use the authoritative delegation registry to verify use. Now this points out a couple of interesting things: - The InterNic data could be better organized. For those organiziations which have been delegated consecutive /24s, an effort could/should be made to have the InterNic recast these delegations as a single CIDR entry instead of the component parts. This is being followed up on with the InterNic. (Reduces the number of queries that you see) - If the idea of using the same delegation and routing registry appeals to you, you may want to consider how to return those old, nasty 192 delegations and use the clean blocks from the RIPE NCC. (Here is where PIER might be of help) --bill From woeber at cc.univie.ac.at Tue Jan 23 11:01:22 1996 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 23 Jan 1996 11:01:22 MET Subject: Question on "Network Number Usage Survey" Message-ID: <0099CD0A.9848103E.3@cc.univie.ac.at> Hi Bill (and Suzane and the robot :-)! > As far as I can tell, RIPE NCC was never delegated this block. I think that's not *completely* true. At least (a small) part of 192 addresses was allocated in Europe by way of the RIPE-NCC and the Local Internet Registries. Quoting from an old RIPE NCC Quarterly Report (Issue 8, March 1994, ripe-116), this involves at least - 192.162/16 "Various assignments" 192.164/16 "EUnet/AT" (Austria) 192.165/16 "NORDUnet" (Scandinavia) 192.166/16 "DE-NIC" (Germany) 192.167/16 "GARR NIS" (Italy) ( 192.168/16 "RIPE NCC - RFC 1597" ) > People are, of course, free to register their delegations, from > what ever source, into their routing registry of choice. The intent > was to use the authoritative delegation registry to verify use. Formally, I agree. Although, in real life, people tend to update registry information at the "nearby" database where the networks are used. In Europe that's even more intuitive, because the same database is used to register address allocations/assignments, routing policy and domains... What hits us here is the fact that we still don't have regular updates performed between the "major" rgistries. While we (the RIPE Databse WG and the NCC) are still trying to get this sorted out, progress in the past was much slower than desirable. You might even be able to promote that idea... > Now this points out a couple of interesting things: > > - The InterNic data could be better organized. For those organiziations > which have been delegated consecutive /24s, an effort could/should > be made to have the InterNic recast these delegations as a single > CIDR entry instead of the component parts. This is being followed > up on with the InterNic. (Reduces the number of queries that > you see) > > - If the idea of using the same delegation and routing registry > appeals to you, you may want to consider how to return those old, > nasty 192 delegations and use the clean blocks from the RIPE NCC. > (Here is where PIER might be of help) Wearing my hat as the RIPE Database WG coordinator, could you please point me to the proper place (and procedures) to participate in that effort(s). Thanks Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at 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 -------------------------------------------------------------------------- From bmanning at ISI.EDU Tue Jan 23 11:26:37 1996 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 23 Jan 1996 02:26:37 -0800 (PST) Subject: Question on "Network Number Usage Survey" In-Reply-To: <0099CD0A.9848103E.3@cc.univie.ac.at> from "Wilfried Woeber, UniVie/ACOnet" at Jan 23, 96 11:01:22 am Message-ID: <199601231026.AA06360@zed.isi.edu> > > Hi Bill (and Suzane and the robot :-)! Howdy... :) > > As far as I can tell, RIPE NCC was never delegated this block. > > I think that's not *completely* true. > At least (a small) part of 192 addresses was allocated in Europe by way > of the RIPE-NCC and the Local Internet Registries. > True, and the contacts for the folks will be getting the can'ed email. This points out a minor problem with the earlier SWIP efforts: Taking the first block on your list: 192.162/16 "Various assignments" 36% whois 192.162 RIPE NCC (NETBLK-EUNET-C) EUNET-C 192.162.0.0 - 192.162.255.0 Research Institute for Informatics (NET-RO-EARN) RO-EARN 192.162.16.0 Universidade do Minho (NET-CCDINET-C5-1) CCDINET-C5-1 192.162.128.0 Universidade do Minho (NET-CCDINET-C5-2) CCDINET-C5-2 192.162.129.0 Universidade do Minho (NET-CCDINET-C5-3) CCDINET-C5-3 192.162.130.0 Universidade do Minho (NET-CCDINET-C5-4) CCDINET-C5-4 192.162.131.0 Universidade do Minho (NET-CCDINET-C5-5) CCDINET-C5-5 192.162.132.0 Thats seven queries. The last five could/should be consolidated into a cidr entries, like the first one. 192.167/16 "GARR NIS" (Italy) This one is even worse.... :-( ( 192.168/16 "RIPE NCC - RFC 1597" ) And this is one simply appears to be a marker 38% whois 192.168 IANA (IANA-CBLK-RESERVED) Internet Assigned Numbers Authority Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 Netname: IANA-CBLK1 Netblock: 192.168.0.0 - 192.168.255.0 > > was to use the authoritative delegation registry to verify use. > > Formally, I agree. > > What hits us here is the fact that we still don't have regular updates > performed between the "major" rgistries. > You might even be able to promote that idea... Interesting point. This is being hashed out with the folks doing routing registries as well. (there are a few more of them :-) At least there is a syncronization method (albeit a poor one) in that venue. Perhaps there should be a strict rule on each IR (delegation registry) only recording data that it is authoritative for? We then raise the pointy questions of authority transfer, granularity of update, validation of "guardian/maintainer", and a host of others. And life is harder when we have multiple models on support of the delegation and announcement registries. > > - If the idea of using the same delegation and routing registry > > appeals to you, you may want to consider how to return those old, > > nasty 192 delegations and use the clean blocks from the RIPE NCC. > > (Here is where PIER might be of help) > > Wearing my hat as the RIPE Database WG coordinator, > could you please point me to the proper place (and procedures) > to participate in that effort(s). > > Thanks > Wilfried. Sure. PIER is an IETF WG. See http://www.isi.edu:80/div7/pier/ for more details. --bill From woeber at cc.univie.ac.at Tue Jan 23 11:53:24 1996 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 23 Jan 1996 11:53:24 MET Subject: 1st draft: proposed agenda - DB-WG at RIPE 23, Amsterdam Message-ID: <0099CD11.DD020A8E.8@cc.univie.ac.at> 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From David.Ponzone at NetSurf.Org Tue Jan 23 14:27:37 1996 From: David.Ponzone at NetSurf.Org (David Ponzone) Date: Tue, 23 Jan 1996 14:27:37 +0100 (MET) Subject: help Message-ID: <199601231327.OAA26932@netsurf.org> From David.Ponzone at NetSurf.Org Tue Jan 23 17:09:19 1996 From: David.Ponzone at NetSurf.Org (David Ponzone) Date: Tue, 23 Jan 1996 17:09:19 +0100 (MET) Subject: sorry Message-ID: <199601231609.RAA29582@netsurf.org> I apologize for my last message. This was a mistake. Sorry again. -- //////////////////////////////////////////////////////////// David Ponzone Work tel: 33-1-39 26 50 00 Email: david at netsurf.org /////////////////// From alain at NetVision.net.il Wed Jan 24 04:27:25 1996 From: alain at NetVision.net.il (Alain Golan) Date: Tue, 23 Jan 1996 21:27:25 -0600 (CST) Subject: ripe-104++ In-Reply-To: <9601221753.AA26424@ncc.ripe.net> Message-ID: 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. From saliba at inco.com.lb Wed Jan 24 12:12:00 1996 From: saliba at inco.com.lb (Therese Saliba) Date: Wed, 24 Jan 96 11:12 GMT Subject: ripe-104++ Message-ID: 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 > To: Carol Orange > Cc: local-ir at 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. > > > > From woeber at cc.univie.ac.at Wed Jan 24 11:31:09 1996 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 24 Jan 1996 11:31:09 MET Subject: ripe-104++ Message-ID: <0099CDD7.EC17AA4E.19@cc.univie.ac.at> >- 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 at 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 -------------------------------------------------------------------------- From orange at ripe.net Wed Jan 24 19:26:28 1996 From: orange at ripe.net (Carol Orange) Date: Wed, 24 Jan 1996 19:26:28 +0100 Subject: ripe-104++ too big! Message-ID: <9601241826.AA04831@ncc.ripe.net> 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 at ripe.net). I look forward to meeting you all next week. -- Carol From alain at NetVision.net.il Thu Jan 25 06:05:37 1996 From: alain at NetVision.net.il (Alain Golan) Date: Wed, 24 Jan 1996 23:05:37 -0600 (CST) Subject: ripe-104++ In-Reply-To: <0099CDD7.EC17AA4E.19@cc.univie.ac.at> Message-ID: I am not sure that I am understanding You correctly, or perhaps I didn't understood ripe-104++, I really think that i am not understanding something. On Wed, 24 Jan 1996, Wilfried Woeber, UniVie/ACOnet wrote: > >- 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. I think it is a wrong assumption, the customer wants to manage his stuff, if a customer wanted the ISP to manage it, than it could be on the ISP site, with an ISP address, it would be a lot more cheaper. this is not the case I was talking about. > 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.... During the last months, I have noticed a serious increase in requests for the following setup: [ISP]-------/_______(WAN connection)_____[Customer] | | ------------- Customer External LAN ---------- | | | | | | [Web host] [1 or 2 PC's] [Firewall+Proxy] | | --------------- Internal LAN ------------(Private Address space) This is typical for a company running a Web-Server, that doesn't want to renumber, or to expose the internal network. The number of those companies connecting to the Internet is growing everyday. This company will want to manage her DNS, such that some formal network assignment is a must. (Of course an LIR/ISP can fool the system, but I don't think that it's the goal of ripe-104++, nor in the mid to long range the interest of the ISP's. IHMO we are looking for a good, and viable solution.) > > 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. I didn't see an opening in RIPE-104++ for a provider LIR, to assign himself networks as belonging to him, and to assign it to a customer unformally. If it is the case, and if it is done without limitations, then there will be no control on address space. Perhaps it could be the way to do what implement what I proposed, as long as it is limited to 8 or 16 IP addresses per customer. But if one LIR can distribute address space "under his name" without any limitation, how are we going to achieve the goal of address space preservation. Do You think that an ISP LIR will be able to drop a big deal, because the customer ask for 16 class C's, while only one or two would be justified, and the LIR can reassign from his "own" pool as much as he want ? > > 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... I doubt that a network with 8 ip addresses would like to be dual homed, but if there is such a case, I would definatly go fo a carefull planning, and follow all the current ripe-104++ procedures, and even more !! So I really think that I am misunderstanding You, or missing something. Regards, Alain . BGP-OSPF-IGRP-EIGRP-UDP-TCP-IP-FR-NOC-NIC-SENDMAIL-DNS-FTP-HTTP-RIPE MAC-CISCO-UNIX FREE-BSD-LINUX ROUTING-NAMED Alain Golan-Goldberg SUPPORT-PSION CIX USENET PPP NetVision - Commercial Israeli Internet Provider IOS SLIP PVC fax://+972-4-550345;http://www.netvision.net.il;vox://+972-4-550330 From Daniel.Karrenberg at ripe.net Thu Jan 25 11:47:36 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 25 Jan 1996 11:47:36 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Wed, 24 Jan 1996 23:30:19 PST. <199601250730.XAA13024@greatdane.cisco.com> References: <199601250730.XAA13024@greatdane.cisco.com> Message-ID: <9601251047.AA17832@ncc.ripe.net> > Tony Li 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 From Daniel.Karrenberg at ripe.net Thu Jan 25 11:51:43 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 25 Jan 1996 11:51:43 +0100 Subject: Policy Statement on Address Space Allocations Message-ID: <9601251051.AA17917@ncc.ripe.net> ------- Forwarded Message Date: Wed, 24 Jan 1996 15:46:05 -0800 From: postel at ISI.EDU To: nanog at merit.edu, cidrd at IEPG.ORG, iepg at IEPG.ORG, iab at ISI.EDU, iesg at ISI .EDU cc: iana at ISI.EDU, netreg at internic.net, ncc at ripe.net, hostmaster at 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 From tli at cisco.com Thu Jan 25 12:00:38 1996 From: tli at cisco.com (Tony Li) Date: Thu, 25 Jan 1996 03:00:38 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: <9601251047.AA17832@ncc.ripe.net> (message from Daniel Karrenberg on Thu, 25 Jan 1996 11:47:36 +0100) Message-ID: <199601251100.DAA26845@greatdane.cisco.com> 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. My apologies. I plead failing neurons.... Sigh. Tony From mnorris at dalkey.hea.ie Thu Jan 25 13:12:25 1996 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Thu, 25 Jan 1996 12:12:25 GMT Subject: ripe-104++ - Summary of Policy Changes Message-ID: <9601251212.AA06629@dalkey.hea.ie> 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. From smd at sprint.net Thu Jan 25 14:20:23 1996 From: smd at sprint.net (Sean Doran) Date: Thu, 25 Jan 1996 08:20:23 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: Daniel Karrenberg's message of Thu, 25 Jan 1996 11:47:36 +0100 References: <199601250730.XAA13024@greatdane.cisco.com> <9601251047.AA17832@ncc.ripe.net> Message-ID: <96Jan25.082047-0000_est.20608+303@chops.icp.net> > 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. From poole at eunet.ch Thu Jan 25 17:58:18 1996 From: poole at eunet.ch (poole at eunet.ch) Date: Thu, 25 Jan 1996 17:58:18 +0100 (MET) Subject: 1st draft: proposed agenda - DB-WG at RIPE 23, Amsterdam In-Reply-To: <0099CD11.DD020A8E.8@cc.univie.ac.at> from "Wilfried Woeber, UniVie/ACOnet" at Jan 23, 96 11:53:24 am Message-ID: <199601251658.RAA21892@eunet.ch> Before too much work occurs here (and has to be financed), I would like to see a report on if there actually is continued interest in supporting a common database infrastructure in the first place. And if yes, what has to be done to satisfy the requirements of the organisations that have stopped using the Ripe database. Background: SWITCH has stopped updating the Ripe database with domains and various other NICs have obviously indicated that will not be doing this anymore either. I do not wish to speculate on the motives, however it -is- clear that this undesirable for the community as a whole. The question is: can this be fixed and what has to be done to accomadte whatever special features these registries need? -- ===== ______ __ __ == Simon Poole ==== / __/ / / /__ ___ / /_ === poole at eunet.ch === / _// /_/ / _ \/ -_) __/ ==== EUnet AG, Zweierstr. 35, CH-8004 Zuerich == /___/\____/_//_/\__/\__/ ===== Tel: +41 1 291 45 80 Fax: +41 1 291 46 42 From hh at tip.net Thu Jan 25 17:59:56 1996 From: hh at tip.net (Hakan Hansson) Date: Thu, 25 Jan 1996 17:59:56 +0100 Subject: Policy Statement on Address Space Allocations Message-ID: <2.2.32.19960125165956.0068a988@mailbox.tip.net> 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 From amb at Xara.NET Thu Jan 25 18:15:21 1996 From: amb at Xara.NET (Alex.Bligh) Date: Thu, 25 Jan 1996 17:15:21 +0000 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 25 Jan 1996 08:20:23 EST." <96Jan25.082047-0000_est.20608+303@chops.icp.net> Message-ID: <199601251715.RAA08929@diamond.xara.net> Please excuse me for butting in on a argument the political background of which I know very little, but this was directed at local-ir so: > 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 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. Problem 1: Smaller local-ir's with their own AS's cannot get windows larger than /19 from RIPE. If they need more than a /19 and request them non-simultaneously the /19s are not likely to be adjacent and hence aggregatable. If Sprint or anyone else refuse to accept /19 announcements, there is no way such local-IR's can get their IP numbers routed. For instance our announcement contains a /19 which is adjacent only to allocations nothing to do with us. Problem 2: Historically the breaking up of RIPE windows/allocations between different AS's has lead to a multitude of tiny announcements. Problem 3: Some ISPs have been lazy in the aggregation of routes on their router. How about: Each window that RIPE dish out (currently never smaller than /19) must have an AS number associated with it in the RIPE database before any allocations from that window are 'legal'. All announcements of address within that window must be made a single aggregated announcement covering the entire window (or more if there happens to be an adjacent allocation) which originate in the associated address. This fixes the PA addresses issue (with the slight complication that providers could theoretically need one window per AS, but this would help aggregation anyway). New PI addresses I couldn't really care less if Sprint etc. don't carry them, but essentially as long as they fall in an entire /19 with associated AS object they culd fall under the same scheme. The only legitimate reason for new PI addresses as far as I am concerned is to issue to small-ish organizations who are not local-ir's and are not multihomed, and will want /19 or thereabouts. Solves problem 1 IMHO. A time limit could be proposed where the above could be enforced for the rest of 193.* & 194.*, with RIPE cooperating to help existing providers renumber. Solves problem 3. Which just leaves (2) (historical - like most of 192.*). Well at least this problem won't grow. Alex Bligh Xara Networks From nanog at dune.silkroad.com Thu Jan 25 18:27:16 1996 From: nanog at dune.silkroad.com (Tim Bass (@NANOG-LIST)) Date: Thu, 25 Jan 1996 12:27:16 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <96Jan25.082047-0000_est.20608+303@chops.icp.net> from "Sean Doran" at Jan 25, 96 08:20:23 am Message-ID: <199601251727.MAA21204@dune.silkroad.com> Sean Doran says: > Yah, yah, Daniel, it's a giant conspiracy against you and Tim Bass. Since my name was mentioned by Sean without provocation, please allow me to respond briefly: ------------------ the kind and compassionate reply ------------------ It interesting that as technologists and engineers, the current climate in internetworking works with undertones of "don't ask questions, because to do so is a form of heresy" against the Internet. I have spent (a few, not enough) days in the archives of Computer Networks, the IEEE journals, and other peer reviewed papers on hierarchical routing; and I have seen *zero* technical justification for "turning a blind-eye" to other less problematic hierarchical routing architectures ( the CIRD, BGP4 paradigm is problematic.... that is why this discussion is taking place as we know) In fact, I have not found one reviewed paper in a journal that compares and contrasts, stochastically, the pros and cons of different hierarchical routing models. Instead of emotional overtones and name calling, isn't it prudent to examine all hierarchical routing paradigms, generate stochastic models, and determine the optimal way to perform hierarchical routing (and try to avoid problematic practical issues as well, which BTW are important ). Hierarchical routing *does not* necessarily translate to "the BGP4, CIDR development path forever"; but for some reason that I cannot explain (and that Sean quips to be "the conspiracy theory" by us engineering skeptics and CIDR heretics) the "world" refuses to take any other hierarchical routing architectures seriously (and many are plausible and feasible if implemented, someone just kindly faxed me another one, BTW). CIDR aggregation is a flawed paradigm for long term growth of the global infrastructure (and most of the engineers seem to roughly agree, IMO); yet we, as technologists, are driven by the forces of commerce to "expand the Internet as fast as possible, keep the growth curve high, grow, grow, grow" mantra; and accept that "we'll just have to be satisfied with band-aid, "change the wings in flight" engineering. .... ladies and gentlemen, we have exactly what we want..... high uncontrollable growth, backwards compatibility problems, forward scaling problems, and the same old protocol development track and engineers and technologist in disharmony. If you study the technical development of the current track, there is a "missing link" that begs to be explored. It would be kind of "those in the CIRD camp" not to label us engineering skeptics who seek to understand "why" as 'heretics and conspiracy theorists'. Personally, I am just interested in answering the question "why?" without throwing stones or casting blame. Thank you and kind regards, Tim postscript: When this thead started, I was determined to stay on the sidelines, and avoid such a wide audience; but since I was mentioned directly in a reply, it seems appropriate to post a short clarifiation, thank your for understanding. +------------------------------------------------------------------------+ | Tim Bass | | | Principal Network Systems Engineer | "Every decoding is another | | The Silk Road Group, Ltd. | encoding.." | | | | | http://www.silkroad.com/ | David Lodge | | | | +------------------------------------------------------------------------+ From bmanning at ISI.EDU Thu Jan 25 20:00:04 1996 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Thu, 25 Jan 1996 11:00:04 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <2.2.32.19960125165956.0068a988@mailbox.tip.net> from "Hakan Hansson" at Jan 25, 96 05:59:56 pm Message-ID: <199601251900.AA13178@zed.isi.edu> > > 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 > Egads! Beleivers in the "hidden" PIER agenda of global, periodic renumbering! (Note that the One Prefix/One AS is the absurd reduction that both P.Lothburg and I argued (unsuccessfully) in trying to get some sanity in draft "draft-ietf-idr-autosys-guide-04.txt") -- --bill From iljitsch at unix1.bart.nl Thu Jan 25 22:03:36 1996 From: iljitsch at unix1.bart.nl (Iljitsch van Beijnum) Date: Thu, 25 Jan 1996 22:03:36 +0100 (MET) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601251715.RAA08929@diamond.xara.net> from "Alex.Bligh" at Jan 25, 96 05:15:21 pm Message-ID: <199601252103.WAA08714@unix1.bart.nl> > aggregatable. If Sprint or anyone else refuse to accept /19 announcements, > there is no way such local-IR's can get their IP numbers routed. For So Sprint should abandon their ridiculous policy. We only announce a /22 and are proud of it! I obviously missed something. Can someone please inform me as to the purpose of not accepting /19 announcements? Iljitsch van Beijnum bART Internet Services From iljitsch at unix1.bart.nl Thu Jan 25 22:29:46 1996 From: iljitsch at unix1.bart.nl (Iljitsch van Beijnum) Date: Thu, 25 Jan 1996 22:29:46 +0100 (MET) Subject: Policy Statement on Address Space Allocations In-Reply-To: <96Jan25.082047-0000_est.20608+303@chops.icp.net> from "Sean Doran" at Jan 25, 96 08:20:23 am Message-ID: <199601252129.WAA10829@unix1.bart.nl> > Sure, there is no filtering in 193/8 and 194/8, > and as a result we have VERY poor aggregation. Get used to it. This is the Internet. People will not always do what _you_ want. > 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 > 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. 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. There are many legitimate reasons why people may announce very long prefixes. I don't see a problem with that, as long as people aren't announcing more routes than they have to. 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! Iljitsch van Beijnum bART Internet Services From miguel.sanz at rediris.es Thu Jan 25 23:22:49 1996 From: miguel.sanz at rediris.es (Miguel A. Sanz. RedIRIS/CSIC) Date: Thu, 25 Jan 1996 23:22:49 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Sean Doran "Re: Policy Statement on Address Space Allocations" (Jan 25, 8:20) References: <199601250730.XAA13024@greatdane.cisco.com> <9601251047.AA17832@ncc.ripe.net> <96Jan25.082047-0000_est.20608+303@chops.icp.net> Message-ID: <9601252322.ZM15338@rediris.es> 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 at 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 ___________________________ From yakov at cisco.com Thu Jan 25 23:46:29 1996 From: yakov at cisco.com (Yakov Rekhter) Date: Thu, 25 Jan 96 14:46:29 PST Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 25 Jan 96 23:22:49 +0100." <9601252322.ZM15338@rediris.es> Message-ID: <199601252246.OAA23511@hubbub.cisco.com> Miguel, > 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. 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 ? Yakov. From gherbert at crl.com Fri Jan 26 00:21:25 1996 From: gherbert at crl.com (George Herbert) Date: Thu, 25 Jan 1996 15:21:25 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 25 Jan 1996 23:22:49 +0100." <9601252322.ZM15338@rediris.es> Message-ID: <199601252321.AA08552@mail.crl.com> >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... That assumes that Sprint is, in fact, the root problem here. The root problem is that lots of routers will be running out of space to store routes soon, and that *everyone* soon will be seeing the problems. Sprint perhaps a little earlier than the rest, hence them leading the effort to correct policies, but they are not alone. We are now closer to running out of Router capability than IP numbers to hand out. A rational solution to that would be to allocate IP space in a manner such that we don't run out of Router capability before we run out of IP space, by assigning easier-to-route, larger CIDR blocks to large providers, and allowing growth space in allocations so that small allocations can grow without having to add more announcements. If the allocating agencies continue to insist on being as sparing as possible with block allocations, which is noticably increasing routing problems, then we are going to face Internet partitions sooner rather than later, based on router load rather than running out of IP space. This is, in my opinion, a poor choice for overall growth. -george william herbert gherbert at crl.com From miguel.sanz at rediris.es Fri Jan 26 00:45:46 1996 From: miguel.sanz at rediris.es (Miguel A. Sanz. RedIRIS/CSIC) Date: Fri, 26 Jan 1996 00:45:46 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Yakov Rekhter "Re: Policy Statement on Address Space Allocations" (Jan 25, 14:46) References: <199601252246.OAA23511@hubbub.cisco.com> Message-ID: <9601260045.ZM16613@rediris.es> 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 at 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 ___________________________ From dennis at Ipsilon.COM Fri Jan 26 01:49:48 1996 From: dennis at Ipsilon.COM (Dennis Ferguson) Date: Thu, 25 Jan 1996 16:49:48 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 25 Jan 1996 14:46:29 PST." <199601252246.OAA23511@hubbub.cisco.com> Message-ID: <199601260049.QAA13335@mailhost.Ipsilon.COM> Yakov, >> 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 ? It is pretty hard to guarantee 100% of anything, but my guess is that "IANA/InterNIC/RIPE NCC/AP-NIC" would be willing to follow any sort of guidelines for how they should allocate address space such that ISPs would endeavour to do their best to route the resulting address topology. Even if this means always allocating in /17 units. The problem is that no one has ever bothered to set meaningful engineering goals for maximizing the life of IPv4. As far as I know the only targets we have are the entirely qualitative, warm-and-fuzzy ones of "smaller" forwarding tables and "better" efficiency of address utilization. So everyone goes off and implements their own policies to make things "smaller" and "better", and we make proposals for making things even "smaller" and "better" still, without the faintest idea of how to quantify "smaller" and "better" in a consistent fashion. So what end result could we have other than what what we got, which is people doing conflicting things, but perfectly justifiable things based on their own notions of "smaller" or "better", and then pointing fingers of blame at each other when the end result is broken, or doesn't conform to their own personal notions of "smaller" and "better"? And I don't think the inability to guarantee 100% of anything justifies ignoring the problem, or not dealing with it as the operational engineering issue that it is. It is broken, and an inability to make 100% guarantees doesn't constrain one from making an attempt to engineer a fix, where "engineer" should mean you have some ability to quantitatively evaluate the outcome. 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: (1) Let's try to make a realistic estimate of what the end state for the IPv4 address space should be. I.e. how many (or few) routes should we be aiming at being able to carry by the time the address space is entirely allocated. Let's come to some consensus about what this number should be (call it 200,000 routes for the sake of current argument), document it, and have everyone include it in RFI's for future routers so that the goal, whatever it is, is clearly defined for hardware vendors (who can then complain if the target is unreasonable, so one can adjust it down accordingly). (2) Let's then look at the amount of extant global routing information from each class-A-sized space, keeping each one to the average required to meet the end-state estimate (about 900 routes per class-A to hit the 200,000 mark). We then squeeze down on existing blocks to fit into this (by imposing filtering, or whatever, if necessary). We also suggest that when any new block a registry is allocating from hits the magic route limit they quit trying to fill in spaces and go on to another class-A sized block (getting more efficiency out of the current block is useless anyway if we're not going to be able to route it). We don't worry about the length of individual prefixes, just the total routes for the block, as this gives registries some flexibility in accomodating both small and large providers and sites. (3) Then we can spend IETF meetings looking at charts with numbers which have real targets to compare them to, and bashing those with measureably bad numbers, and applauding those with measureably good numbers, and figuring out what to do if the numbers we picked look unachievable, or if we need new technology to do better. And otherwise actually engineering the problem, rather than just talking about how to get it "better" and "smaller". And I mostly think that the IETF group into which this issue fits is not doing its job unless it can get us to a point where address allocation people and ISPs aren't issuing disclaimers about each other's behaviour, and instead have got some mutually agreed upon, and verifiable, goals and targets which everyone works towards. Dennis Ferguson From yakov at cisco.com Fri Jan 26 02:10:05 1996 From: yakov at cisco.com (Yakov Rekhter) Date: Thu, 25 Jan 96 17:10:05 PST Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 26 Jan 96 00:45:46 +0100." <9601260045.ZM16613@rediris.es> Message-ID: <199601260110.RAA05223@hubbub.cisco.com> Miguel, > > 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'. IANA is the *Naming and Addressing* Authority. But to the best of my knowledge the IANA's authority is not sufficient to guarantee Internet-wide connectivity. > 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. What do you think should be covered by the "common rules everybody should follow", and who should be setting these rules ? Yakov. From dennis at Ipsilon.COM Fri Jan 26 02:16:00 1996 From: dennis at Ipsilon.COM (Dennis Ferguson) Date: Thu, 25 Jan 1996 17:16:00 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 25 Jan 1996 15:21:25 PST." <199601252321.AA08552@mail.crl.com> Message-ID: <199601260116.RAA14017@mailhost.Ipsilon.COM> > We are now closer to running out of Router capability than IP numbers > to hand out. A rational solution to that would be to allocate IP > space in a manner such that we don't run out of Router capability > before we run out of IP space, by assigning easier-to-route, > larger CIDR blocks to large providers, and allowing growth space > in allocations so that small allocations can grow without having > to add more announcements. If the allocating agencies continue to > insist on being as sparing as possible with block allocations, which > is noticably increasing routing problems, then we are going to face > Internet partitions sooner rather than later, based on router load > rather than running out of IP space. This is, in my opinion, a poor > choice for overall growth. But note well that current routers can't last forever (if you want them to we might as well give the next 120 requestors a class A chunk and then forget about address allocation altogether), and if you're looking for short-term relief address allocation policy is not the place to get it. Because the current forwarding table size is a result of the integral of all past allocation policies, it takes a while (a year or two, certainly, a lifetime in this industry) for any current address allocation changes to have any measureable effect. 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. Dennis Ferguson From hal9001 at panix.com Fri Jan 26 07:17:32 1996 From: hal9001 at panix.com (Robert A. Rosenberg) Date: Fri, 26 Jan 1996 01:17:32 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: 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). From HANK at VM.TAU.AC.IL Fri Jan 26 08:34:25 1996 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Fri, 26 Jan 96 08:34:25 IST Subject: Policy Statement on Address Space Allocations In-Reply-To: Message of Thu, 25 Jan 1996 16:49:48 -0800 from Message-ID: <9601260638.HA22904@nikhefh.nikhef.nl> 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 From kre at munnari.OZ.AU Fri Jan 26 08:22:08 1996 From: kre at munnari.OZ.AU (Robert Elz) Date: Fri, 26 Jan 1996 18:22:08 +1100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 25 Jan 1996 14:46:29 PST." <199601252246.OAA23511@hubbub.cisco.com> Message-ID: <8623.822640928@munnari.OZ.AU> Date: Thu, 25 Jan 96 14:46:29 PST From: Yakov Rekhter Message-ID: <199601252246.OAA23511 at hubbub.cisco.com> I have deleted almost everyone form the cc list (as have others) except I went further and deleted the IAB, IANA, etc as well... 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 ? Yakov, this is a patently silly question, as the answer is either obviously yes by definition, or obviously no by demonstration. That is, one can define "the Internet" as being that set of IP reachable nodes which has connectivity to all of the other nodes in the set (and probably includes one specific node, say a.root-servers.net, just to distinguish this one particular set from other similar ones). In that case, by definition, if you are part of the Internet you are guaranteed 100% Internet connectivity - anyone you can't reach isn't part of the Internet. On the other hand, if we avoid precise definitions of what is the Internet exactly, then I can clearly show you nodes that generally consider themselves to be part of the Internet, which no-one (but a very limited number of nodes) can reach, and I expect many others can too, which easily shows that no-one, anywhere, gets 100% Internet connecivity. And I think you can see that address allocation policies actually have nothing whatever to do with this. However, Miguel does have a point, if Sprint choose to filter routes so that an advertismennt of mine is not visible to Sprint customers, then it is Sprint customers who are missing connectivity to me. I would only care on the assumption that I really wanted to communicate with someone silly enough to connect to a provider who would deliberately reduce their connectivity. We should also note however that filtering at /18 does not necessarily need to reduce connectivity, Sean has said he has that filter often enough, but he hasn't said that he doesn't also have a few other (perhaps static) routes of the form (say) 203.0/14 aimed at (say) MCI, so that while MCI (for example) may want to be sending 203.0.x/24 routes towards Sprint, Sprint can ignore them, and still retain connectivity to everyone. Connectivity remains that way, with some planning, though routing optimailty perhaps suffers, if MCI then had to hand off packets for some 203.0.z to some other provider that Sprint would (with full routing) have been able to reach directly. With a little application, the large ISPs could actually agree amongst themselves to divide up the routing table space this way - each agreeing to accept routes of "longer than optimal" prefix lengths for some subset of the entire table space, accept routes from all the others for lengthy prefixes and advertise only a short prefix route to all of them. While not a long term solution to anything, this would allow the current routing tables to to significantly reduced in all of the default free routers, which would also reduce the need to install draconian route filters throughout the net. Some routes would be longer, however it seems (to me at least, and certainly from imperfect knowledge) that this could largely be restricted to an extra high speed hop at (or near) the NAPs or other exchange points. That is, if implemented rationally this wouldn't require the providers maintaining longer prefix routes that are otherwise filtered in other providers to actually provide any long haul transit, just in and out of a single router. And last, as long as the routing tables continue to fit, anyone who wanted could continue accepting all the routes from everyone - the effect would be that when a provider was forced to filter to keep the routing system running that connectivity need not be sacrificed. kre From kozowski at structured.net Fri Jan 26 08:41:40 1996 From: kozowski at structured.net (Eric Kozowski) Date: Thu, 25 Jan 1996 23:41:40 -0800 Subject: Policy Statement on Address Space Allocations Message-ID: <199601260741.XAA02347@chaos.structured.net> >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 at 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 From forrestc at imach.com Fri Jan 26 09:21:16 1996 From: forrestc at imach.com (Forrest W. Christian) Date: Fri, 26 Jan 1996 01:21:16 -0700 (MST) Subject: Policy Statement on Address Space Allocations In-Reply-To: Message-ID: Here's an interesting thought on the whole thing... I've sort of noticed that the opinion of several people is that the way that the internic allocates IP numbers is "space efficient". CIDR routing on the other hand is considered "routing table efficient". I felt like digging through 205.* and 206.*, at least at the start. I did a whois on 205.0.0.0 and then looked at the last used # in the allocated block, and then did a whois on that #. For CIDR blocks, I was jumping over the entire block, as listed in the whois. >From this it looks like the internic is allocating a large number of prefixes longer than /18. Am I wrong in stating that (assuming that Sprint's policy is unchangable) any IP numbers allocated with a prefix longer than /19 in 205 and /18 in 206 is essentially wasted space, which is unusable, at least if you want connectivity with sprint? If this is the case, then I'd imagine that the allocation policies of certain registries (most notably the internic) of netblocks smaller than /18 is very address space inefficient. -forrestc at imach.com From Daniel.Karrenberg at ripe.net Fri Jan 26 10:16:07 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 Jan 1996 10:16:07 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Thu, 25 Jan 1996 16:49:48 PST. <199601260049.QAA13335@mailhost.Ipsilon.COM> References: <199601260049.QAA13335@mailhost.Ipsilon.COM> Message-ID: <9601260916.AA08359@ncc.ripe.net> > Dennis Ferguson writes: > > ... > > And I mostly think that the IETF group into which this issue fits is not > doing its job unless it can get us to a point where address allocation > people and ISPs aren't issuing disclaimers about each other's behaviour, > and instead have got some mutually agreed upon, and verifiable, goals > and targets which everyone works towards. Seconded, thirded and fourthed. Daniel From ronald at office.demon.net Fri Jan 26 10:31:10 1996 From: ronald at office.demon.net (Ronald Khoo) Date: Fri, 26 Jan 1996 09:31:10 +0000 Subject: Policy Statement on Address Space Allocations In-Reply-To: <9601260638.HA22904@nikhefh.nikhef.nl> (from Hank Nussbacher) Message-ID: <9601260931.aa08211@office.demon.net> That's too simplistic. A /19 in the Netherlands may well make sense. In the UK it would be far too small, for ANY of our registries. We can't argue for non-uniform policies ("Uganda has far smaller requirement than the Netherlands") on the one hand and uniform ones ("we have to be seen to be even handed") on the other hand simultaneously. Driving the argument from more than one set of conflicting goals at once is obviously going to lead to difficulties. If the overriding goal is to eke out IPv4's useful lifespan, a fuzzy goal, that's sure to result in fuzzy guidelines rather than strict rules. Here's a suggestion for one simple rule. "Where delegating address space to a provider registry, a) never delegate a block smaller than any existing PA block already delegated, and b) once 3 such blocks are delegated, always delegate a block at least 4 times bigger". This will allow Uganda to grow to the size of the Netherlands, and the Netherlands to grow to the size of the UK, and the UK to grow to the size of the USA without changing the guidelines and without requiring all registries under one delegating registry to be at the same level of Internet size and growth rate. On Jan 26, 8:34am, Hank Nussbacher wrote: } Subject: Re: Policy Statement on Address Space Allocations } 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 }-- End of excerpt from Hank Nussbacher -- Ronald Khoo +44-181-371-1000 FAX +44-181-371-3750 From Daniel.Karrenberg at ripe.net Fri Jan 26 10:50:59 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 Jan 1996 10:50:59 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Fri, 26 Jan 1996 01:17:32 EST. References: Message-ID: <9601260951.AA09100@ncc.ripe.net> > "Robert A. Rosenberg" writes: > > 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 .... Of course we do that. That's why I wrote: 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. However it is our policy not to make any guarantees about this happening. Daniel From Daniel.Karrenberg at ripe.net Fri Jan 26 11:04:56 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 Jan 1996 11:04:56 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Fri, 26 Jan 1996 08:34:25 +0700. <9601260638.HA22904@nikhefh.nikhef.nl> References: <9601260638.HA22904@nikhefh.nikhef.nl> Message-ID: <9601261004.AA09368@ncc.ripe.net> > Hank Nussbacher writes: > > 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, you miss the point. It is *untenable* for the regional registry to get into discussions about the size of the *initial* allocation. Therefore a local IR in Uganda choosing to be served by the NCC will be allocated a /19, no questions asked. The expectation is that they will not need further allocations for a long time. But we have wasted a maximum of 8K addresses. Once they need another allocation we will know their usage rate, i.e. how long it took them to assign the first /19 and hence will have a much more objective means to determine the size of their next allocation. For clarification: One *big* difference between the ItnerNIC and us is that we ask a fee for registration services which discourages spurious requests from individuals and/or very small providers. Daniel From training at ripe.net Fri Jan 26 11:36:44 1996 From: training at ripe.net (RIPE NCC Training) Date: Fri, 26 Jan 1996 11:36:44 +0100 Subject: Announcement for Local IR Training Course in Paris Message-ID: <9601261036.AA10116@ncc.ripe.net> * * * Announcement * * * Local Internet Registries Training Course Date: Monday, 26th February 1996 Time: 0900 - 1700 Venue: Hyatt Hotel Airport Charles de Gaulle Paris France -------------- next part -------------- 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 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 ;-). -------------- next part -------------- %%%%%%%%%%% 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 . 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 . 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.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END From training at ripe.net Fri Jan 26 11:41:36 1996 From: training at ripe.net (RIPE NCC Training) Date: Fri, 26 Jan 1996 11:41:36 +0100 Subject: Announcement for Local IR Training Course in Lisbon Message-ID: <9601261041.AA10314@ncc.ripe.net> * * * 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 -------------- next part -------------- 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 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 ;-). -------------- next part -------------- %%%%%%%%%%% 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 . 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 . 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.) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END From Daniel.Karrenberg at ripe.net Fri Jan 26 11:58:22 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 Jan 1996 11:58:22 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Thu, 25 Jan 1996 08:20:23 EST. <96Jan25.082047-0000_est.20608+303@chops.icp.net> References: <96Jan25.082047-0000_est.20608+303@chops.icp.net> Message-ID: <9601261058.AA10837@ncc.ripe.net> 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 Detailed comments follow (can be skipped by people intersted in the real issues). > Sean Doran writes: > > > 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. ... You conveniently ignored the stats in my message. I repeat them here sorted by "hosts addressed/route". You will note that 193/8 and 194/8 have anything but "VERY poor" aggregation. They are both within a factor 2 of your goal of 1024 routes. 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 207.0.0.0 1019136 37 27544 203.0.0.0 5831424 780 7476 200.0.0.0 4660736 697 6686 206.0.0.0 10967808 1649 6651 193.0.0.0 9264640 2019 4588 194.0.0.0 7665920 1849 4145 205.0.0.0 6019584 1793 3357 202.0.0.0 4258496 1460 2916 204.0.0.0 10499072 3660 2868 199.0.0.0 8838144 3338 2647 196.0.0.0 731648 329 2223 198.0.0.0 7488000 3705 2021 192.0.0.0 4981504 6551 760 201.0.0.0 256 1 256 197.0.0.0 256 1 256 195.0.0.0 256 1 256 C Space 82226880 27870 2950 > 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. You should be careful calling things b.s. before checking why they are done. > 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. Here we disagree about how to achieve goals. I tend to favour compromise/consensus achieved by discussion to unilateral action. > 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 have told you before that as regional registry I have absolutely no control about routing policies of any provider whatsoever. I can only try to have influence and, again, I think we are doing quite well compared to others. > > 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. I guess we have a language communications problem here. What is wrong with someone authoritative about something to say what it 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. > > 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? You should have read further: (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.) I am getting the impression that you are not really listening. What I was saying is that "everyone gets the *same* *initial* allocation" was something I am not willing to compromise on. If you had to sift through all the bullsit (marketing predictions, solicitor's letters, hurt egos, diplomatic notes(!) ...) which any other policy generates or (beware) to pay someone to handle those, I am sure you would agree. > Not that I care; I'm not prone to compromise myself, > frankly. Good that you say so, I didn't notice ;-). > 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 you care to read ripe-127 and the policy statement which caused this whole discussion you will notice that this is being done in no uncertain but less Sprint centric terms. This does not prevent me from arguing with you about better soloutions. > 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. Fine and I have this neat archive of warnings I put out too including the documents cited above. Now can we try to make things work rather than point fingers! > 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!". They would be dead wrong. > 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. About which I have no *control* but some influence. See the proposal above. > 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. We have no problem with that. Any way to reduce the work we have to spend on registration services is welcome. ;-). However what you are asking is for us to make and enforce policies that favour a certain type of provider more than technically necessary. This we will not do. If one of these providers chooses to cut itself and its customers off from some parts of the Internet that is fine. Daniel From peter at demon.net Fri Jan 26 12:17:43 1996 From: peter at demon.net (Peter Galbavy) Date: Fri, 26 Jan 1996 11:17:43 +0000 (GMT) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601251727.MAA21204@dune.silkroad.com> from "Tim Bass" at Jan 25, 96 12:27:16 pm Message-ID: <9601261117.aa11700@office.demon.net> > Since my name was mentioned by Sean without provocation, please allow > me to respond briefly: And I don't know you - so don't take this one personally either :-) > Instead of emotional overtones and name calling, > isn't it prudent to examine all hierarchical routing paradigms, > generate stochastic models, and determine the optimal way to > perform hierarchical routing (and try to avoid problematic practical > issues as well, which BTW are important ). > > Hierarchical routing *does not* necessarily translate to "the BGP4, > CIDR development path forever"; but for some reason that I cannot > explain (and that Sean quips to be "the conspiracy theory" by us > engineering skeptics and CIDR heretics) the "world" refuses to take any > other hierarchical routing architectures seriously (and many > are plausible and feasible if implemented, someone just kindly > faxed me another one, BTW). > > CIDR aggregation is a flawed paradigm for long term growth of > the global infrastructure (and most of the engineers seem to > roughly agree, IMO); yet we, as technologists, are driven by the > forces of commerce to "expand the Internet as fast as possible, > keep the growth curve high, grow, grow, grow" mantra; and > accept that "we'll just have to be satisfied with band-aid, > "change the wings in flight" engineering. Hierarchical routeing is a flawed paradigm as well. CIDR is even more flawed, but it works at the moment. CIDR really only works if the block allocated are actually routed geographically. As a provider our primary Internet links outside of the UK are all the the USA. We, however, *have* to come to RIPE for "European" address space. When RIPE starts offering *free* routeing to the world using the top level CIDR blocks, then I will agree that CIDR works. 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. Back to the "technical" discussion: 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... > When this thead started, I was determined to stay on the sidelines, > and avoid such a wide audience; but since I was mentioned directly > in a reply, it seems appropriate to post a short clarifiation, > thank your for understanding. Hard to do, staying in the background when discussing quite emotive "religious" issues. Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From iljitsch at daisy.bART.nl Fri Jan 26 11:24:59 1996 From: iljitsch at daisy.bART.nl (Iljitsch van Beijnum) Date: Fri, 26 Jan 96 11:24:59 Subject: Policy Statement on Address Space Allocations In-Reply-To: (from randy@psg.com (Randy Bush)) (at Thu, 25 Jan 96 14:20 PST) Message-ID: <21fc7b04.271f-iljitsch@daisy.bART.nl> 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 From Daniel.Karrenberg at ripe.net Fri Jan 26 12:59:53 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 Jan 1996 12:59:53 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Fri, 26 Jan 1996 09:31:10 GMT. <9601260931.aa08211@office.demon.net> References: <9601260931.aa08211@office.demon.net> Message-ID: <9601261159.AA11992@ncc.ripe.net> > Ronald Khoo writes: > Here's a suggestion for one simple rule. "Where delegating address space > to a provider registry, a) never delegate a block smaller than any > existing PA block already delegated, and b) once 3 such blocks are > delegated, always delegate a block at least 4 times bigger". While sounding fine in general, this assumes ever increasing growth of ISPs. An assumption easily proven invalid by counterexample. Daniel From paul at vix.com Fri Jan 26 13:00:48 1996 From: paul at vix.com (Paul A Vixie) Date: Fri, 26 Jan 1996 04:00:48 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 26 Jan 1996 01:21:16 MST." Message-ID: <9601261200.AA02330@wisdom.home.vix.com> While I'm still trying to puzzle out why a message sent to this particular list of exploders is different in any way from "spam," I'll jump in here: > [...] Sprint's policy is unchangable) any IP numbers allocated with a prefix > longer than /19 in 205 and /18 in 206 is essentially wasted space, which > is unusable, at least if you want connectivity with sprint? I've always assumed that Sprint's policy in this regard means that they do not want to have complete connectivity. Why, in this day and age, anyone in the transit business would not want to be able to resell 100% connectivity to their customers, I do not know. But it's Sprint's error and Sprint's problem. One assumes that after enough "unrouteable" (by Sprint and only Sprint) prefixes are allocated, Sprint will receive enough negative feedback from their customers that they (Sprint) will have to revise this foolish policy. Meanwhile let's not put the tail before the donkey -- this is Sprint's problem and the wound, good doctors, was self inflicted. How many times will you let the fact that Sprint is jumping in front of your car lead you to swerve to avoid hitting them? Heck, if that's what they want, do it and get it over with. Don't anybody change their routing or allocation policies just because Sprint has odd routing policies. Sprint != Internet. Fortunately. From Daniel.Karrenberg at ripe.net Fri Jan 26 13:36:35 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 Jan 1996 13:36:35 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Fri, 26 Jan 1996 11:17:43 GMT. <9601261117.aa11700@office.demon.net> References: <9601261117.aa11700@office.demon.net> Message-ID: <9601261236.AA12593@ncc.ripe.net> > Peter Galbavy writes: > Hierarchical routeing is a flawed paradigm as well. CIDR is even more > flawed, but it works at the moment. Thanks for amitting at least that much ;-). Would you care to share your thoughts on less flawed paradigms that will work with current or near-future kit ({hard,firm,soft}ware for the non-british)? > CIDR really only works if the > block allocated are actually routed geographically. Yes, CIDR works if addresses are allocated *somewhat* topologically. > As a provider > our primary Internet links outside of the UK are all the the USA. > We, however, *have* to come to RIPE for "European" address space. The continental component in address space allocation is pure policy and has little to do with CIDR. The policy only seems unreasonable when considering only the issue you raise. Personally I believe that even this issue is irrelevant for providers of the size of Demon. It makes no difference where you get a /16 from. The real issues here are ones of control and attribution of cost. > 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 know that you object against allocation and assignments policies we apply to you as to any other local registry (provider) we serve. Yet the particular policies you object to, are the ones set by IANA and applicable globally. You mistakenly assume that these policies would not be applied if you were dealing with the InterNIC. > 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. Thank you for the public ad hominem. :-(. I consider this bad style. I suggest you examine my personal track record more closely before repeating such attacks. RIPE is not a bureaucrazy. It is about as lightweight as an organisation can get. The RIPE NCC is also not a bureaucrazy. I can assure you that *everyone* here would rather do *any* of the other activities that we are supposed to do but registration services. Yet this job has to be done and done fairly. We also consider *very carefully* what the people that pay for our very existance want. We have well documented and working meachanisms for that. We have a contributors committee where each local registry in good standing (yourselves incluided) is represented which decides on our activites and charges. We have RIPE to direct our activities technically. All these processes are open and well documented. I am quite happy that you plan to get involved in these processes. What we do *not* do is consider *individual* interests of some over the ones of others. If we would do that we would eliminate our "raison d'etre". If you do not like the RIPE NCC model, consider the alternatives. You seem to be keen to have the US government set the policies. Or maybe you want governmental regulation closer to home? > 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 ? You have hit the nail on the head. There are conflicting goals here and engineering needs to be done. > Maybe I have > misunderstood the way IPv6 addressing works... No you have not. IPv6 routing basically is IPv4 routing with biger addresses. Read the archives for proposals like PIP enabling really interesting routing architectures and why they didn't make it. Daniel From bmanning at ISI.EDU Fri Jan 26 14:08:59 1996 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Fri, 26 Jan 1996 05:08:59 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601260116.RAA14017@mailhost.Ipsilon.COM> from "Dennis Ferguson" at Jan 25, 96 05:16:00 pm Message-ID: <199601261308.AA13827@zed.isi.edu> > 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. > Already underway as part of the PIER efforts. Updates at NANOG and IETF. -- --bill From mnorris at dalkey.hea.ie Fri Jan 26 14:17:06 1996 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Fri, 26 Jan 96 13:17:06 +0000 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 26 Jan 96 11:17:43 GMT." <9601261117.aa11700@office.demon.net> Message-ID: <9601261317.AA08657@dalkey.hea.ie> >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. As you imply, Peter, you haven't been to a RIPE meeting yet. At RIPE 23 next week, you'll get to meet the "bureaucracy" - they're not of the 'faceless' variety ;-) - and lots of the members of RIPE. You'll also see how RIPE and its groups work, always by consensus within the membership, with expert guidance from all over Europe and the wider Internet, and with concern for the maintenance and growth of IP networking everywhere. Despite the weather forecast, I'm sure you'll warm to RIPE, its members and even its "bureaucracy", and perhaps revise your opinion in the light of an enjoyable experience. Looking forward to meeting you in Amsterdam. Mike Norris From jcurran at bbnplanet.com Fri Jan 26 14:30:52 1996 From: jcurran at bbnplanet.com (John Curran) Date: Fri, 26 Jan 1996 08:30:52 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: 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 >... From peter at demon.net Fri Jan 26 14:59:32 1996 From: peter at demon.net (Peter Galbavy) Date: Fri, 26 Jan 1996 13:59:32 +0000 (GMT) Subject: Policy Statement on Address Space Allocations In-Reply-To: <9601261236.AA12593@ncc.ripe.net> from "Daniel Karrenberg" at Jan 26, 96 01:36:35 pm Message-ID: <9601261359.aa01854@office.demon.net> > > Peter Galbavy writes: > > Hierarchical routeing is a flawed paradigm as well. CIDR is even more > > flawed, but it works at the moment. > > Thanks for amitting at least that much ;-). > Would you care to share your thoughts on less flawed paradigms > that will work with current or near-future kit ({hard,firm,soft}ware for > the non-british)? I wish I knew. In this I am the worst type of couch potato. I can identify the problem but I am very unlikely to provide the solution. Not in this case at least. I suspect it is because I have not spent enough time involed with the politics of the 'net as maybe I should have. This is much more of a political problem than a technical one. Just to spend a few minutes thinking about it, what do the phone companies do ? They are the nearest thing with a large installed base that the Internet even begins to map onto. There are however some fundemental differences - primarily the fragmentation of Europe (which is not the case in the US). We have a 2Mb line from London to Amsterdam which costs us very much the same as a T1 from London to Washington. As I understand it, this "milk them for all they are worth" pricing of the telcos applies to cross-border land lines in Europe also. All this impacts very severely on the commercial decisions taken as to the routeing of traffic. I would much rather buy more lines to the US and let the traffics flow back to Europe then to just buy lines to Europe. Luckily, commercial concerns are not the only contraints within which we have to work. > > CIDR really only works if the > > block allocated are actually routed geographically. > > Yes, CIDR works if addresses are allocated *somewhat* topologically. And in the case of (I am guessing) > 70% of RIPE NCC allocated addresses are not. This is no ones "fault", just the way the policy is. Therefore I say the policy is WRONG. > > As a provider > > our primary Internet links outside of the UK are all the the USA. > > We, however, *have* to come to RIPE for "European" address space. > > The continental component in address space allocation is pure policy and > has little to do with CIDR. The policy only seems unreasonable when > considering only the issue you raise. But it is the *primary* issue. What else is there that influences how addresses are allocated in a CIDR or hierarchical way ? Timezones ? We have e-mail for admin - it is timezone orthoganal. The existance of the RIPE NCC should just be remote, local staff for the InterNIC. If the RIPE NCC applies a "local model" then it is not conforming to the policies of IANA and the IAB that you keep referring to. > Personally I believe that even this issue is irrelevant for providers of > the size of Demon. It makes no difference where you get a /16 from. Except you will not, even with correct justifications, give us one for our dial up services. To wash some dirty laundry here, we as a provider have been trying to get new address space for our dial up customers from RIPE NCC for almost 6 months now. We allocate *each* dialup customer *1* IP address from a block and dynamically route them based on where they log in to the service (including RSN Amsterdam). The RIPE NCC has >effectively< refused us space because they believe that we should change the product we sell and use dynamic IP for dialups. We are the largest dialup ISP in Europe. We are not the largest provider in Europe because we follow the rest of the ISPs like sheep, buying Ciscos and installing off the shelf terminal servers. We provide a product which our customers understand gives them *more* for their money. We do something different, and the customers like it. Tough fact of business life that. Eventually, Daniel has very kindly allocated a /19 of space... which is vastly too small for our growth. We started using this space about 8 days ago and have used > 15% of it. Ouch. We are doubling in size between every 5 and 8 months. Within the guildlines for address allocation we can easily demonstrate filling a /16 in this sort of timescale. The RIPE NCC believes it can dicate the business model we use, which has been established for > 3.5 years. This is unlikely to happen. I will not discuss in a public forum the odd schemes that Daniel suggested for "verifying" our use of the address space. But they were odd. It is not the NCC's job to doubt us when we say we have filled the address space. Does the NCC go and visit ACME Ltd to see that it really has all the PCs and server before allocating some more address space ? Didn't think so. > The real issues here are ones of control and attribution of cost. Yes. You collect the RIPE NCC contributions and remain in control. Simple. I am considering my personal view on making this not the case. > > 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 know that you object against allocation and assignments policies we > apply to you as to any other local registry (provider) we serve. > Yet the particular policies you object to, are the ones set by IANA > and applicable globally. You mistakenly assume that these policies > would not be applied if you were dealing with the InterNIC. Please read the policies again. You policy uses words like "strongly discouraged" for static IP allocation, not "disallowed". You have attempted to strongly discourage us, we have not been so discouraged, and now give up and give us the address space we are *entitled* to. > > 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. > > Thank you for the public ad hominem. :-(. I consider this bad style. > I suggest you examine my personal track record more closely > before repeating such attacks. But this is all I have seen you do, therefore, how can I but believe that this is the case. Every private mail that has been sent to us as a company involves you acting as God and us as the grovelling peasants praying for a benidication of address space. I have all these mails in my various folders, as do you. > RIPE is not a bureaucrazy. It is about as lightweight as an organisation > can get. I did not say it was a heavy bureaucrazy (sic), but a bureaucracy is nevertheless harmful if it prevents those members it purport to represent from doing. > The RIPE NCC is also not a bureaucrazy. I can assure you that > *everyone* here would rather do *any* of the other activities that we > are supposed to do but registration services. Yet this job has to be > done and done fairly. We also consider *very carefully* what the people > that pay for our very existance want. We have well documented and > working meachanisms for that. We have a contributors committee where each > local registry in good standing (yourselves incluided) is represented > which decides on our activites and charges. We have RIPE to direct our > activities technically. All these processes are open and well documented. > I am quite happy that you plan to get involved in these processes. I wish I had the time, but it appears that we will have to make the time to get more involed. sigh. > What we do *not* do is consider *individual* interests of some over > the ones of others. If we would do that we would eliminate our > "raison d'etre". Why not. We are not a communist society are we ? Each individual member of RIPE have their own unique requirements in a commercial and academically challenging world. We have a USP (Unique Selling Point) of giving our paying customers there own IP address (OK - it is not unique, but close enough). We have built propretary technology that allows our users to use *any* of our dial in points and get the same service, with the same IP number etc etc, and as one of our primary USPs we cannot allow the RIPE NCC to try to change that. > If you do not like the RIPE NCC model, consider the alternatives. > You seem to be keen to have the US government set the policies. > Or maybe you want governmental regulation closer to home? The RIPE NCC model probably would work if it took into account that fact that its members are (on the whole) commercial organisations that sell differing products and services and have different requirements of the NCC. This does not appear to be the case. Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From HANK at VM.TAU.AC.IL Fri Jan 26 16:08:27 1996 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Fri, 26 Jan 96 16:08:27 IST Subject: Policy Statement on Address Space Allocations In-Reply-To: Message of Fri, 26 Jan 1996 11:17:43 +0000 (GMT) from Message-ID: <9601261413.AA15006@ncc.ripe.net> 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 at demon.net Hank Nussbacher From sob at newdev.harvard.edu Fri Jan 26 15:17:12 1996 From: sob at newdev.harvard.edu (Scott Bradner) Date: Fri, 26 Jan 1996 09:17:12 -0500 (EST) Subject: Policy Statement on Address Space Allocations Message-ID: <199601261417.JAA09870@newdev.harvard.edu> > 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 From peter at demon.net Fri Jan 26 15:01:03 1996 From: peter at demon.net (Peter Galbavy) Date: Fri, 26 Jan 1996 14:01:03 +0000 (GMT) Subject: Policy Statement on Address Space Allocations In-Reply-To: <9601261317.AA08657@dalkey.hea.ie> from "Mike Norris" at Jan 26, 96 01:17:06 pm Message-ID: <9601261401.aa03045@office.demon.net> > Despite the weather forecast, I'm sure you'll warm to RIPE, its > members and even its "bureaucracy", and perhaps revise your > opinion in the light of an enjoyable experience. > > Looking forward to meeting you in Amsterdam. Me too. See you all there... -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From ronald at office.demon.net Fri Jan 26 15:20:01 1996 From: ronald at office.demon.net (Ronald Khoo) Date: Fri, 26 Jan 1996 14:20:01 +0000 Subject: Policy Statement on Address Space Allocations In-Reply-To: <9601261159.AA11992@ncc.ripe.net> (from Daniel Karrenberg) Message-ID: <9601261420.ab08188@office.demon.net> You're trying to achieve a perfect policy that will work for all time when what we need is something to eke out IPv4 for the rest of its natural life. By the time enough of your postulated ISPs have grown big enough AND THEN shrunk enough for this to matter in any practical sense, IPv4 will have become mostly static, and all of us here will have retired from active Internet Politics. I hope. On Jan 26, 12:59pm, Daniel Karrenberg wrote: } Subject: Policy Statement on Address Space Allocations } } > Ronald Khoo writes: } } > Here's a suggestion for one simple rule. "Where delegating address space } > to a provider registry, a) never delegate a block smaller than any } > existing PA block already delegated, and b) once 3 such blocks are } > delegated, always delegate a block at least 4 times bigger". } } While sounding fine in general, this assumes ever increasing growth } of ISPs. An assumption easily proven invalid by counterexample. } } Daniel }-- End of excerpt from Daniel Karrenberg -- Ronald Khoo +44-181-371-1000 FAX +44-181-371-3750 From young at mci.net Fri Jan 26 16:05:05 1996 From: young at mci.net (Jeff Young) Date: Fri, 26 Jan 1996 10:05:05 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Thu, 25 Jan 1996 23:22:49 +0100." <9601252322.ZM15338@rediris.es> Message-ID: <199601261505.KAA10980@it.reston.mci.net> >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 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: it's everyone else's 206 customers who can't reach sprint's customers. even though it's the packets from sprint's customer's that can't make it back to everyone else. that's the beauty of it. sprint announces networks in the 206 space to us and to everyone else. we accept the announcements if they are larger than /24: *> 206.12.94.0 192.41.177.241 128 80 0 1239 3602 ? *> 206.12.187.0 192.41.177.241 128 80 0 1239 1794 ? *> 206.13.159.0 192.41.177.241 128 80 0 1239 1791 3064 i * 206.24.100.0/23 192.41.177.241 128 80 0 1239 1792 3563 i *> 206.40.99.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.100.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.101.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.102.0 192.41.177.241 128 80 0 1239 3663 i *> 206.40.103.0 192.41.177.241 128 80 0 1239 3663 i * 206.40.128.0/19 192.41.177.241 128 80 0 1239 4534 i so if i'm a customer of sprint in a 206+ network that is announced as a /24, i have a route to the world. 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). nobody said it would be boring. :-) Jeff Young young at mci.net From yakov at cisco.com Fri Jan 26 16:24:44 1996 From: yakov at cisco.com (Yakov Rekhter) Date: Fri, 26 Jan 96 07:24:44 PST Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 26 Jan 96 11:58:22 +0100." <9601261058.AA10837@ncc.ripe.net> Message-ID: <199601261524.HAA27147@hubbub.cisco.com> 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. From hwb at upeksa.sdsc.edu Fri Jan 26 16:46:39 1996 From: hwb at upeksa.sdsc.edu (Hans-Werner Braun) Date: Fri, 26 Jan 1996 07:46:39 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601260110.RAA05223@hubbub.cisco.com> from "Yakov Rekhter" at Jan 25, 96 05:10:05 pm Message-ID: <199601261546.HAA06263@upeksa.sdsc.edu> >IANA is the *Naming and Addressing* Authority. But to the >best of my knowledge the IANA's authority is not sufficient to >guarantee Internet-wide connectivity. There is no authority any more. May have been in the ARPAnet, *may* be in the NSFNET days. The IANA/InterNIC thing is essentially a coordination function that assumes that everyone plays and in result gives a good probability of global uniqueness in varieties of assignments. If the policies are not being accepted, the non-accepters will weight global interconnectivity against needing to provide services in a perhaps isolated environment. Many will choose global connectivity, some others may not. Example. A few weeks back or so I needed an AS number, but the InterNIC came back, after I filled out their form, with what I considered unreasonable additional requests, and I thought screw it, I don't need this, I just pick a number. The setup was semi-experimenal anyway (some routing research, but connected), and if someone complains I can fix it later, or send them after the InterNIC. So, the coordination function has failed there, and there was certainly no authority involved. I liked Dennis' note about picking reasonable targets, btw, and going for those somehow, may be doing "limits by declaration," so we find out what's reasonable, rather than dwelling in doom or no-doom about address spaces and so. That something that could be done at the NANOG meeting, with some email in advance and after? From Daniel.Karrenberg at ripe.net Fri Jan 26 17:34:03 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 Jan 1996 17:34:03 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Fri, 26 Jan 1996 14:20:01 GMT. <9601261420.ab08188@office.demon.net> References: <9601261420.ab08188@office.demon.net> Message-ID: <9601261634.AA18696@ncc.ripe.net> > Ronald Khoo writes: > You're trying to achieve a perfect policy that will work for all time > when what we need is something to eke out IPv4 for the rest of its > natural life. I am not trying to achieve a perfect policy. I am an engineer both by training and preference, not a policymaker. What I am trying to do is to discuss proposals for policies which look simple but break badly on already existing cases. > By the time enough of your postulated ISPs have grown big > enough AND THEN shrunk enough for this to matter in any practical sense, > IPv4 will have become mostly static, and all of us here will have retired > from active Internet Politics. I hope. We are talking about real ISPs. If you check the address space usage history of European local IRs, you will see that the growth in address space usage of some has flattened a lot (I was not talking about shrinking yet). Look in the area of national academic research networks. Your simplistic scheme, if cast in stone, would do the very wrong things for those. Try again Daniel From amb at Xara.NET Fri Jan 26 17:49:41 1996 From: amb at Xara.NET (Alex.Bligh) Date: Fri, 26 Jan 1996 16:49:41 +0000 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 26 Jan 1996 11:58:22 +0100." <9601261058.AA10837@ncc.ripe.net> Message-ID: <199601261649.QAA10154@diamond.xara.net> Daniel Karrenberg wrote: > 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. You are not distinguishing (initial) allocation from announcement. Your guarantee is worthless in the sense that it only gurantees that the announcements (as opposed to allocations) can be aggregated if each window allocation is tied to a single AS, and thus, for instance that none of the allocation is for PI space, or for allocation to customers who aren't local-IRs but have their own AS etc. etc. You also have the problem that currently it is impossible for local-IRs to allocate blocks of IP numbers that wouldn't be filtered out to multihomed customers (with their own AS - thus almost inevitably requiring a separate announcement) where that customer under the RIPE rules isn't 'justified' in getting a /19 (too small, for instance). Conservation vs. aggregation again. What is your recommendation on this? Alex Bligh Xara Networks 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.... 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 ? From smd at cesium.clock.org Fri Jan 26 18:09:04 1996 From: smd at cesium.clock.org (Sean Doran) Date: Fri, 26 Jan 1996 09:09:04 -0800 Subject: Policy Statement on Address Space Allocations Message-ID: <96Jan26.090917pst.5568@cesium.clock.org> | 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. From smd at cesium.clock.org Fri Jan 26 18:22:41 1996 From: smd at cesium.clock.org (Sean Doran) Date: Fri, 26 Jan 1996 09:22:41 -0800 Subject: Policy Statement on Address Space Allocations Message-ID: <96Jan26.092245pst.5568@cesium.clock.org> 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. From Daniel.Karrenberg at ripe.net Fri Jan 26 18:53:56 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 Jan 1996 18:53:56 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Fri, 26 Jan 1996 13:59:32 GMT. <9601261359.aa01854@office.demon.net> References: <9601261359.aa01854@office.demon.net> Message-ID: <9601261753.AA20185@ncc.ripe.net> > Peter Galbavy writes: > > Thanks for amitting at least that much ;-). > > Would you care to share your thoughts on less flawed paradigms > > that will work with current or near-future kit ({hard,firm,soft}ware for > > the non-british)? > > I wish I knew. In this I am the worst type of couch potato. .... So stop critising "paradigms" without proposing better ones or at least research the rationales and history behind them. > > Yes, CIDR works if addresses are allocated *somewhat* topologically. > > And in the case of (I am guessing) > 70% of RIPE NCC allocated addresses > are not. First you missed the emphasis on *somewhat*. Second you are guessing wrong. >From both of the above it seems that you only know of and are only concerned with your own particular situation. > This is no ones "fault", just the way the policy is. Therefore > I say the policy is WRONG. What is the better policy? > > The continental component in address space allocation is pure policy and > > has little to do with CIDR. The policy only seems unreasonable when > > considering only the issue you raise. > > But it is the *primary* issue. What else is there that influences how > addresses are allocated in a CIDR or hierarchical way ? More local topology than continental one is *very* important. > We have e-mail for admin - it is timezone orthoganal. The existance > of the RIPE NCC should just be remote, local staff for the InterNIC. Fine with me. Do RIEP and theother contributors agree? We can re-organise starting next week. > If the RIPE NCC applies a "local model" then it is not conforming > to the policies of IANA and the IAB that you keep referring to. The RIPE NCC applies local policies within the boundaries of the global policies. > > Personally I believe that even this issue is irrelevant for providers of > > the size of Demon. It makes no difference where you get a /16 from. > > Except you will not, even with correct justifications, give us one for > our dial up services. > > To wash some dirty laundry here ... I could help you washing in detail but I do not think this is appropriate in all these fora. For the record I will summarise: Demon is statically assigning IP addresses to dialup customers on a large scale. This results in adresses being used per customer and not per dial-in port. Obviously then number of customers is less limited than that of dial in ports. There is concern about the wastefulness of this practise on a large scale and the non-linear effects it could have on address space usage. Hence it is *global*, read IANA, policy to strongly discourage this practise and not to allocate more addresses than three months worth of usage. This is not just an NCC policy! Indeed we have allocated you a /19 to start with in addition to the address space you have been allocated for other purposes than dial up IP. Of course you will receive further allocations within the range of the above policy whenever you need them. Of course we will do our best to make the further allocations aggregateable with previous ones. Assignments of address space by local IRs to customers have to be registered in the RIPE (whois) database. You have raised that your commercial interest of keeping your customer list confidential should outweigh this registration requirement in the case of individuals because of the special characterisitcs of the (consumer) market you operate in. We have recognised that the tradeoff between the benefit of registration and the commercial interests of individual dialup providers is indeed special and consequently have worked with you(!), IANA and the other regional registries to establish a global policy for this special case. This policy has to take into account the need for verification of assignments since the registration requirement has been dropped and the database is not available for verification. We have worked with you in this matter, you have agreed to the result. I think it is *very* inappropriate to publicly abuse those who have worked with you and to throw polemics at compromises some of which you have even suggested and all of which you have agreed to. I will leave the polemics for what they are. > I wish I had the time, but it appears that we will have to make the > time to get more involed. sigh. Yes, it is more appropriate than polemicising publicly. > > What we do *not* do is consider *individual* interests of some over > > the ones of others. If we would do that we would eliminate our > > "raison d'etre". > > Why not. We are not a communist society are we ? Each individual member > of RIPE have their own unique requirements in a commercial and > academically challenging world. We have a USP (Unique Selling Point) of > giving our paying customers there own IP address (OK - it is not > unique, but close enough). We have built propretary technology that > allows our users to use *any* of our dial in points and get the same > service, with the same IP number etc etc, and as one of our primary USPs > we cannot allow the RIPE NCC to try to change that. > ... > The RIPE NCC model probably would work if it took into account that > fact that its members are (on the whole) commercial organisations > that sell differing products and services and have different > requirements of the NCC. This does not appear to be the case. You have received sufficient address space for your present needs and you have been assured that -unless there are policy changes- you will receive enough for your future needs. The same policy is applied to everyone. --- Polemic mode on ---- I have the slight suspicion that for you the only good model is one that does exactly what *you* want, everyone else be damned. --- Polemic mode off ---- Daniel From Daniel.Karrenberg at ripe.net Fri Jan 26 19:04:40 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 Jan 1996 19:04:40 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Fri, 26 Jan 1996 07:24:44 PST. <199601261524.HAA27147@hubbub.cisco.com> References: <199601261524.HAA27147@hubbub.cisco.com> Message-ID: <9601261804.AA20473@ncc.ripe.net> > Yakov Rekhter writes: > > - 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 ? Sorry, lack of clarity because of failing neurons. What I meant to say was "1024 CIDRable allocations". Or simply "allocations". The point is that we will guarantee that our allocation policy will create no more than 1024 allocations per /8 and therefore not necessitate by itself more routes than that. Currently our allocation sizes are /19 - /16. If you think about it a little you will see that it is easy to achieve. And just in case: Yes the minimum allocation is /19 irrespective of the number of hosts covered. Note: allocation != assignment. Daniel From smd at icp.net Fri Jan 26 14:15:52 1996 From: smd at icp.net (Sean Doran) Date: Fri, 26 Jan 1996 13:15:52 -0000 Subject: Policy Statement on Address Space Allocations Message-ID: <96Jan26.131554-0000_est.20608+338@chops.icp.net> 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. From Daniel.Karrenberg at ripe.net Fri Jan 26 19:24:07 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 Jan 1996 19:24:07 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Fri, 26 Jan 1996 09:09:04 PST. <96Jan26.090917pst.5568@cesium.clock.org> References: <96Jan26.090917pst.5568@cesium.clock.org> Message-ID: <9601261824.AA20778@ncc.ripe.net> > Sean Doran writes: > > | Now can we try to make things work rather than point fingers! > > Yes, indeed; that is the ultimate goal we share. Pooooh .... relief. > 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 ;-). > 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. All I am suggesting is to set it at /19 initially which should consume roughly ;-) as many CPU time as setting it to /18. Should we fail to meet the challenge later, I suggest to set it to /18 and allow some /19 exceptions caused by our allocation policy. This will be a quite limited number, the information will be machine readable in real time. We will provide the tools (3 lines perl) to generate filters from it. Frankly: If you cannot do this your motives become quite questionable. > 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. It is not as big a deal as you want to make it. Daniel From yakov at cisco.com Fri Jan 26 19:35:05 1996 From: yakov at cisco.com (Yakov Rekhter) Date: Fri, 26 Jan 96 10:35:05 PST Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 26 Jan 96 19:04:40 +0100." <9601261804.AA20473@ncc.ripe.net> Message-ID: <199601261835.KAA10448@hubbub.cisco.com> Daniel, > > Would the RIPE NCC provide such non-aggregatable allocations > > irrespective of how many hosts would be covered by such an > > allocation ? > > Sorry, lack of clarity because of failing neurons. > What I meant to say was "1024 CIDRable allocations". > Or simply "allocations". > > The point is that we will guarantee that our allocation policy will > create no more than 1024 allocations per /8 and therefore not > necessitate by itself more routes than that. Currently our allocation > sizes are /19 - /16. If you think about it a little you will see that > it is easy to achieve. > > And just in case: Yes the minimum allocation is /19 irrespective > of the number of hosts covered. Note: allocation != assignment. OK, so just to make it clear, if a customer would come to the RIPE NCC and the customer has just 1 host you would still allocated him /19 block. Correct ? Yakov. From smd at icp.net Fri Jan 26 15:03:19 1996 From: smd at icp.net (Sean Doran) Date: Fri, 26 Jan 1996 14:03:19 -0000 Subject: Policy Statement on Address Space Allocations Message-ID: <96Jan26.140333-0000_est.20614+343@chops.icp.net> 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. From smd at cesium.clock.org Fri Jan 26 20:22:34 1996 From: smd at cesium.clock.org (Sean Doran) Date: Fri, 26 Jan 1996 11:22:34 -0800 Subject: Policy Statement on Address Space Allocations Message-ID: <96Jan26.112237pst.5601@cesium.clock.org> | > 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. From smd at icp.net Fri Jan 26 16:18:25 1996 From: smd at icp.net (Sean Doran) Date: Fri, 26 Jan 1996 15:18:25 -0000 Subject: Policy Statement on Address Space Allocations Message-ID: <96Jan26.151836-0000_est.20615+346@chops.icp.net> | PS: Here's Sprint's sister company's current announcement of routes | *originating* in its AS as I see them - I do hope Sprint takes the honest | path if it does refuse to carry short announcements and not route all bar | 4 of these nets, as well as a similar long list from AS1239 :-) I'm | not convinced Sprint has the moral highground here.... Moral high ground does not interest me. Working networks interest me. I have to carry the ^1239_ routes internally anyway to get my customers able to talk to each other. I don't need to carry your routes at all, unless one of my customers wants to talk to you. It's a simple thing, elegantly described by Jeff Young earlier today. It was also elegantly described by Yakov Rekhter in his CIDRD presentation of the concepts of Push and Pull. Ordinarily I would answer "filter away; we've been prepared for this kind of filter being applied against us since day #1 (although admittedly it's not going to be too pretty if someone wants to talk to you and suddenly can't. been there, done that)". As a mechanism for motivating our customers to aggregate better than they could, an important provider doing a similar sort of inbound filtering likely would be much more widely effective than the occasional Seanogram to various customers warning of doom and the possibilities of being filtered, which sometimes seem to be completely ignored. This filtering is analagous to how ANS is able to get people to register their prefixes in the RADB or run into inbound announcement filters that will stop you from talking with AOL and other ANS customers. As you note, AS 4000 is run by a different company, and you shouldn't punish them just because I'm an arrogant asshole, as I have no control over or involvement with their routing strategies. (I'm not even sure that I'm entirely popular over there. ;-) ) However, yes, they are not aggregating as well as they could be, and are announcing more-specific-routes that are completely subsumed by aggregates. Some of those folks are here and should feel free to speak for themselves. Hi guys! :) Sean. | Network Next Hop Metric LocPrf Weight Path | *> 160.214.0.0 194.68.130.50 0 4000 ? | *> 163.164.0.0 194.68.130.50 0 4000 ? | *> 194.41.63.0 194.68.130.50 0 4000 ? | *> 194.106.0.0/19 194.68.130.50 0 4000 ? | *> 194.106.32.0 194.68.130.50 0 4000 ? | *> 194.106.33.0 194.68.130.50 0 4000 ? | *> 194.106.34.0 194.68.130.50 0 4000 ? | *> 194.126.64.0/19 194.68.130.50 0 4000 ? | *> 194.133.0.0/19 194.68.130.50 0 4000 i | *> 194.133.4.0/23 194.68.130.50 0 4000 ? | *> 194.133.6.0 194.68.130.50 0 4000 ? | *> 194.133.7.0 194.68.130.50 0 4000 ? | *> 194.133.8.0 194.68.130.50 0 4000 ? | *> 194.133.15.0 194.68.130.50 0 4000 ? | *> 194.133.24.0 194.68.130.50 0 4000 ? | *> 194.133.28.0 194.68.130.50 0 4000 ? | *> 194.140.128.0/19 194.68.130.50 0 4000 ? | *> 194.140.224.0/21 194.68.130.50 0 4000 ? | *> 194.149.192.0/18 194.68.130.50 0 4000 ? | *> 194.158.0.0/20 194.68.130.50 0 4000 ? | *> 194.176.96.0/19 194.68.130.50 0 4000 ? | *> 194.204.96.0/23 194.68.130.50 0 4000 ? | *> 196.27.0.0 194.68.130.50 0 4000 ? | *> 196.27.1.0 194.68.130.50 0 4000 ? | *> 198.169.26.0 194.68.130.50 0 4000 ? | *> 204.59.0.0/16 194.68.130.50 0 4000 i | *> 204.83.37.0 194.68.130.50 0 4000 ? | *> 204.83.237.0 194.68.130.50 0 4000 ? | *> 204.83.254.0 194.68.130.50 0 4000 ? | *> 206.49.64.0/18 194.68.130.50 0 4000 i | *> 206.49.65.0 194.68.130.50 0 4000 ? From iljitsch at unix1.bart.nl Fri Jan 26 21:31:09 1996 From: iljitsch at unix1.bart.nl (Iljitsch van Beijnum) Date: Fri, 26 Jan 1996 21:31:09 +0100 (MET) Subject: Policy Statement on Address Space Allocations In-Reply-To: <96Jan26.090917pst.5568@cesium.clock.org> from "Sean Doran" at Jan 26, 96 09:09:04 am Message-ID: <199601262031.VAA14605@unix1.bart.nl> > 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. So how is this for a compromise: If there actually _are_ more announcements than 1024 in any particular /8 under the control of the RIPE NCC, you implement filtering in such a way that it gets down below 1024 again. In this scenario, as long as the NCC can persuade it's customers to aggregate, there are no problems. And if problems arise, it is extremely likely that they can be fixed by filtering /20 and longer. That way, only the offenders suffer and not the people who aggregate as RIPE tells them to do. A weekly check to see if the number of announcements stays below 1024 would be quite adequate and not unduly machine or manpower intensive, in my opinion. From alague at hq.si.net Sat Jan 27 03:44:11 1996 From: alague at hq.si.net (alague at hq.si.net) Date: Fri, 26 Jan 96 18:44:11 PST Subject: Policy Statement on Address Space Allocations Message-ID: > >| 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 ? > From Bill.Simpson at um.cc.umich.edu Fri Jan 26 23:36:43 1996 From: Bill.Simpson at um.cc.umich.edu (William Allen Simpson) Date: Fri, 26 Jan 96 22:36:43 GMT Subject: Policy Statement on Address Space Allocations Message-ID: <4761.bsimpson@morningstar.com> I trimmed the CC list even further. And you are forwarned that this is a flame, with combined technical and political content: > From: Peter Galbavy > Just to spend a few minutes thinking about it, what do the phone > companies do ? They are the nearest thing with a large installed base > that the Internet even begins to map onto. There are however some > fundemental differences - primarily the fragmentation of Europe (which > is not the case in the US). > It should not surprise you that we've heard this before, and rejected it before. > We have a 2Mb line from London to Amsterdam which costs us very much > the same as a T1 from London to Washington. As I understand it, this > "milk them for all they are worth" pricing of the telcos applies to > cross-border land lines in Europe also. > So, lay your own lines if it is cost effective. Heck, spread spectrum radio comes to mind.... if not microwave towers on the oil rigs in the north sea.... > All this impacts very severely on the commercial decisions taken as to > the routeing of traffic. I would much rather buy more lines to the US > and let the traffics flow back to Europe then to just buy lines to > Europe. > Is this why the US-UK links are soooooo overcrowded? Destroying connectivity for the rest of us? > We allocate *each* dialup customer *1* IP address from a > block and dynamically route them based on where they log in to the > service (including RSN Amsterdam). The RIPE NCC has >effectively< refused > us space because they believe that we should change the product we > sell and use dynamic IP for dialups. > Hell yes! Damn right! Three cheers for RIPE!!! Anyone who still allocates more than 1 address per actual dial-up link should be taken out and shot! We spent rather a lot of volunteer-years getting this to work (PPP). > We provide a product which > our customers understand gives them *more* for their money. We do something > different, and the customers like it. Tough fact of business life that. > Are you sure you told your customers about the alternatives? Like dynamic addressing? Like having connectivity to the entire Internet? This isn't new, this is old hat static addresses! How is it different? What gives _more_ here? I don't see anything worthwhile! > The RIPE NCC believes it can dicate the business model we use, which > has been established for > 3.5 years. This is unlikely to happen. > There is this misconception on your part that you have a _right_ to succeed in business, at the expense of the rest of us. > Please read the policies again. You policy uses words like "strongly > discouraged" for static IP allocation, not "disallowed". You have > attempted to strongly discourage us, we have not been so discouraged, > and now give up and give us the address space we are *entitled* to. > You have another misconception that there is an _entitlement_ to Internet access, at the expense of the rest of us. > > What we do *not* do is consider *individual* interests of some over > > the ones of others. If we would do that we would eliminate our > > "raison d'etre". > > Why not. We are not a communist society are we ? I dunno about _your_ society, but the Internet Community requires cooperation. Call it communistic or socialistic as you like. The net won't work without it. Your "priveleges" end when you affect someone else. And you are affecting me, buddy, and I don't like it one bit! Perhaps you should go build your own internet, like MicroSoft.... Again, I applaud RIPE!!! Bill.Simpson at um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From smd at icp.net Sat Jan 27 00:52:00 1996 From: smd at icp.net (Sean Doran) Date: Fri, 26 Jan 1996 23:52:00 -0000 Subject: Policy Statement on Address Space Allocations Message-ID: <96Jan26.235208-0000_est.20615+364@chops.icp.net> | 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. From Daniel.Karrenberg at ripe.net Sat Jan 27 10:34:51 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Sat, 27 Jan 1996 10:34:51 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Fri, 26 Jan 1996 16:49:41 GMT. <199601261649.QAA10154@diamond.xara.net> References: <199601261649.QAA10154@diamond.xara.net> Message-ID: <9601270934.AA29299@ncc.ripe.net> > "Alex.Bligh" writes: > > You are not distinguishing (initial) allocation from announcement. Correct. This is because it is *only* the allocation that a regional registry has *control* over. After that we can only have *influence*. > Your guarantee is worthless in the sense that it only gurantees that > the announcements (as opposed to allocations) can be aggregated if > each window allocation is tied to a single AS, I wouldn't call that worthless exactly, because the method has shown some successes. > and thus, for instance that > none of the allocation is for PI space I do not care about PI space. Those wanting it have had ample warning. > or for allocation to customers > who aren't local-IRs but have their own AS etc. etc. There you are! Cases of genuine need for a seperate announcement (multihomed) are not covered by the guarantee. But my expectation is that their number can be offset by bigger aggregates. Note that the number of routes *currently* announced under 193/8 and 194/8, which have some room for improvement, is quite low already. Actually they are both within the theoretical limit of a /18 filter which is 2047 routes. > You also have the problem > that currently it is impossible for local-IRs to allocate blocks > of IP numbers that wouldn't be filtered out to multihomed customers > (with their own AS - thus almost inevitably requiring a separate > announcement) where that customer under the RIPE rules isn't 'justified' > in getting a /19 (too small, for instance). Conservation vs. aggregation > again. What is your recommendation on this? I fully agree that this is a problem. I believe that the only real solution to this is to reduce *unneeded* announcements as much as possible. This needs a routing registry and tools. This is why pure prefix length filtering is the wrong soloution. It just favours the big providers. The argument I am having with Sean is just part of this whole area: He says: "Change your allocation policy to match my routing policy." IANA says: "Registries shall not make allocations/assignments based on (individual) ISP's routing policies." (With which I fully agree) I say: "Change your routing policy very slightly such that it remains compatible with my allocation policy." This bartering does not solve the general problem and does not claim to. It is just part of the effort to keep things working. Daniel From Joel_M_Snyder at Opus1.COM Sat Jan 27 18:41:51 1996 From: Joel_M_Snyder at Opus1.COM (Joel M Snyder, writing fool) Date: Sat, 27 Jan 1996 10:41:51 -0700 (MST) Subject: Policy Statement on Address Space Allocations In-Reply-To: "Your message dated Fri, 26 Jan 1996 22:36:43 +0000 (GMT)" <4761.bsimpson@morningstar.com> Message-ID: <01I0I3D6V4BCCG8VNH@Opus1.COM> I've been following this discussion with great interest. Let me posit a situation and seek guidance. Consider a company, perhaps a very, very, small company, which happens to have a very, very, very popular web site. For the sake of argument, let's call this company "Netscape," (although this company isn't Netscape, but this will create the appropriate picture in your mind). This company needs only a microscopic amount of address space, something on the order of a /28. The company wishes to have more than one connection to the Internet through more than one of the major providers, for bandwidth & reliability reasons. It sounds to me, based on the discussions which have been occurring, that this company can't do what they want---unless they lie and somehow gobble up a /18 worth of address space. Is this true? jms PS: Double-numbering hosts won't work; because of monumentally poor programming practices on the part of WWW developers, WWW clients do not discern multiple A records for a given host name. Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX) jms at Opus1.COM http://www.opus1.com/jms Opus One PLEASE NOTE: The useful parts of Arizona changed from area code 602 to area code 520 on March 20, 1995. From Havard.Eidnes at runit.sintef.no Sat Jan 27 19:08:39 1996 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Sat, 27 Jan 1996 19:08:39 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 26 Jan 96 10:35:05 PST" References: <199601261835.KAA10448@hubbub.cisco.com> Message-ID: <199601271808.TAA28906@vader.runit.sintef.no> Hi, I see Daniel hasn't answered this one (weekend for some, I guess ;-) > > The point is that we will guarantee that our allocation policy > > will create no more than 1024 allocations per /8 and therefore > > not necessitate by itself more routes than that. Currently our > > allocation sizes are /19 - /16. If you think about it a little > > you will see that it is easy to achieve. > > > > And just in case: Yes the minimum allocation is /19 irrespective > > of the number of hosts covered. Note: allocation != assignment. > > OK, so just to make it clear, if a customer would come to the RIPE > NCC and the customer has just 1 host you would still allocated him > /19 block. Correct? This may be obvious to some familiar to the european networking scene already, but anyway... The RIPE NCC itself does in general not deal directly with end customers, only with local registries. To be allocated address space directly from the RIPE NCC you have to first establish yourself as a local registry, pay the startup fee and contribute to the financing of the running costs of the RIPE NCC. Remember, there is noone else than the organizations running the local registries who are picking up the tab for running the RIPE NCC. The typical local registry is also an ISP. Also note the distinction between allocation and assignment made by Daniel which could be lost on some. In this specific case allocation means "address space allocated for a local registry for subsequent assignment to customers". I've seen people critizising the RIPE NCC for their inflexible policies and the practicing of these policies. One important aspect of the RIPE NCC policies when allocating address space to registries is simplicity and uniformity of policy, because one of the worst things that could happen for the RIPE NCC would be for them to rightfully be accused of giving unfair preferential treatment to some registries (=~ ISPs) over others. The chance of this happening (or the RIPE NCC being accused of it) increases with the fuzziness of policies and the amount of evaluation and judgement the RIPE NCC has to apply to individual cases. I think this is fairly accurate, but since this is not coming from the authoritative source I may have made minor mistakes in formulating the above. Regards, - Havard From HANK at VM.TAU.AC.IL Sat Jan 27 20:04:22 1996 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Sat, 27 Jan 96 20:04:22 IST Subject: Policy Statement on Address Space Allocations In-Reply-To: Message of Fri, 26 Jan 1996 13:59:32 +0000 (GMT) from Message-ID: <9601271817.AA02806@ncc.ripe.net> On Fri, 26 Jan 1996 13:59:32 +0000 (GMT) you said: >Just to spend a few minutes thinking about it, what do the phone >companies do ? They are the nearest thing with a large installed base >that the Internet even begins to map onto. There are however some >fundemental differences - primarily the fragmentation of Europe (which >is not the case in the US). > >We have a 2Mb line from London to Amsterdam which costs us very much >the same as a T1 from London to Washington. As I understand it, this >"milk them for all they are worth" pricing of the telcos applies to >cross-border land lines in Europe also. > >All this impacts very severely on the commercial decisions taken as to >the routeing of traffic. I would much rather buy more lines to the US >and let the traffics flow back to Europe then to just buy lines to >Europe. Luckily, commercial concerns are not the only contraints >within which we have to work. What this has to do with RIPE allocation policies is beyond me. Everyone in the European realm suffers from extremely high tariffs. So what? >To wash some dirty laundry here, we as a provider have been trying to >get new address space for our dial up customers from RIPE NCC for almost 6 >months now. We allocate *each* dialup customer *1* IP address from a >block and dynamically route them based on where they log in to the >service (including RSN Amsterdam). The RIPE NCC has >effectively< refused >us space because they believe that we should change the product we >sell and use dynamic IP for dialups. > >We are the largest dialup ISP in Europe. We are not the largest provider >in Europe because we follow the rest of the ISPs like sheep, buying Ciscos >and installing off the shelf terminal servers. We provide a product which >our customers understand gives them *more* for their money. We do something >different, and the customers like it. Tough fact of business life that. You and hundreds of other companies approach RIPE with the same story of how big they are, how large their investors are, how their network is gonna take the world of the Internet by storm, and therefore they deserve a /16 or even a /15. If RIPE followed your logic, there would be no more address space left. Use dynamic IP like the rest of us. We all realize the drain of IP addresses and try our best to maximize the addresses. Why should you be different? >But this is all I have seen you do, therefore, how can I but believe >that this is the case. Every private mail that has been sent to us as >a company involves you acting as God and us as the grovelling peasants >praying for a benidication of address space. I have all these mails >in my various folders, as do you. It all depends on your ego. You could just look at them as an organization assigned the tough role of making sure there are IP addresses available in 1999. You see it as God. A viewpoint based on your world view. >Why not. We are not a communist society are we ? Each individual member >of RIPE have their own unique requirements in a commercial and >academically challenging world. We have a USP (Unique Selling Point) of >giving our paying customers there own IP address (OK - it is not >unique, but close enough). We have built propretary technology that >allows our users to use *any* of our dial in points and get the same >service, with the same IP number etc etc, and as one of our primary USPs >we cannot allow the RIPE NCC to try to change that. IBM has 460 POPs in over 40 countries and uses dynamic IP addresses. I can be in London or NYC or Tel Aviv and still use my SLIP connection to read my mail wherever I am. Why should you have static IP addresses for something others can do the dynamic way and thereby conserve IP address space? >Peter Galbavy peter at demon.net Hank Nussbacher Israel From HANK at VM.TAU.AC.IL Sat Jan 27 20:25:06 1996 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Sat, 27 Jan 96 20:25:06 IST Subject: Policy Statement on Address Space Allocations In-Reply-To: Message of Fri, 26 Jan 1996 14:03:19 -0000 from Message-ID: <9601271837.AA02951@ncc.ripe.net> On Fri, 26 Jan 1996 14:03:19 -0000 you said: >But still, sorry that it wasn't as smooth as it could >have been if there hadn't been a flaw in the filtering >that crept in in about April, long before anyone was >even really thinking of allocating from 206.0.0.0/8. > >However, as I think everyone remembers, after a short while, >in an effort to assist in getting aggregation of the >then-announced bits of 206.0.0.0/8 working OK and giving >people some time to get used to the filtering, I did relax >the filtering on 206.0.0.0/8 to permit /19s. > >As you note, this was to the benefit of other peoples' customers. > >| the real message is if you have a 206+ address, make sure that your >| provider can put it into an aggregation block for you (or go to sprint). > >Right, and we have been warning our customer base for >some time that if they announce a 206+ address that is >not aggregatable into something reasonably big (like a /18), >they run the risk of losing connectivity to other providers >if they ever were to impose similar filters for business >or technical reasons. Lets take a real world example between Sean's and Daniel's arguments. I am the registry of Last Resort for Israel and I assign CIDR blocks to ISPs here in Israel. I follow the slow start model of RIPE and give initially a /22 and then a /21 and then a /20, etc. One new ISP in Israel wanted more address space and found that Net99 (all ISPs have to connect to an ISP in the USA due to Israeli gov't regulations) would give it a /21 from 206.161.0.0 and later Agis gave it a /19 from 206.249.0.0. So we have now an ISP that circumvented the allocation policies and went to the USA to get cheap, large blocks at possibly an expense of them not being portable and/or not routable even if it is portable in the future. The smaller, new ISPs that don't know even what questions to ask will get stuck more and more by this type of situation. We can't do anything about that. But we do need a better GLOBAL policy for IP address allocation that everyone adheres to (perhaps I am asking for utopia). > Sean. Hank Nussbacher From Daniel.Karrenberg at ripe.net Sat Jan 27 20:58:39 1996 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Sat, 27 Jan 1996 20:58:39 +0100 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of Sat, 27 Jan 1996 19:08:39 MET. <199601271808.TAA28906@vader.runit.sintef.no> References: <199601271808.TAA28906@vader.runit.sintef.no> Message-ID: <9601271959.AA03685@ncc.ripe.net> > Havard.Eidnes at runit.sintef.no writes: > Hi, > > I see Daniel hasn't answered this one (weekend for some, I guess ;-) Yeah, I went outside with wife and kids. It *is* cold ( -5 Celsius plus wind chill for those still to depart for here). > ... > I think this is fairly accurate, but since this is not coming from > the authoritative source I may have made minor mistakes in > formulating the above. Thank you Havard, as usual you are right on the money. For those interested, the latest and most tutorial writeup of this can be found at ftp://ftp.ripe.net/ripe/drafts/ripe-104++.{ps,txt} Main points again: - the RIPE NCC as regional registry only deals with local registries - local registries are typically operated by ISPs - all local registries share the cost of the NCC (usually prevents the 1 host case) - anyone who commits to the contribution and operational requirements can become local registry - there curerntly are 300+ local registries - local registries determine NCC activities and charging scheme - RIPE (operators technical forum) guides technical work of NCC - allocation = address space held by local registry for assignment - assignment = to end-user for operating network - assignments happen according to assignment policy, different from allocation policy - end-user can be ISP operating registry themselves, i.e. ISP has to abide by assignment policy when assigning themselves address space for their own use - size of first allocation for new registry fixed (currently /19) - size of further allocations depends on usage rate - while we guarantee nothing, we try to make subsequent assignments such that they can be aggregated with previous ones So the answer to Yakhov's "1 host" question is: We will refer them to their service provider. If they insist we will send them the operational requirements, fee schedule and a service agreement. So far we have not heared back from any of the "1 host" cases. Apparently they consider it not worth the hassle. Also there is a natural growth path for ISPs. We have seen quite a few who initially had address space form their up-stram provider and later decided to start operating their own local registry. I have seen them using different strategies for using the original address space. Usually some thoughtful engineering will give them good mileage. While it is not perfect and far from esthetically pleasing it works at the moment. Yakhov: It is amusing to see you argue about the registry system from a tower made of some off-white substance (not unlike the colour of the *real* Cisco routers made from real sheet metal with real fans). I challenge you to propose a realistic distribution/registration method of IPv4 addresses which can be implemented a.s.a.p and does not involve neutrally run registries. With realistic I mean: - rough community consensus - little entropy - transition plan You would make my day. Let's hear it. Daniel From smd at cesium.clock.org Sat Jan 27 22:34:08 1996 From: smd at cesium.clock.org (Sean Doran) Date: Sat, 27 Jan 1996 13:34:08 -0800 Subject: Policy Statement on Address Space Allocations Message-ID: <96Jan27.133420pst.5605@cesium.clock.org> This is a very interesting question involving economics of the Internet, which are still very fuzzy. I think it would make an interesting experiment. Certainly there has been lots of talk about putting something big like wuarchive.wustl.edu or ftp.uu.net into something obscure to see what breaks. There are existence proofs of sorts that popular sites can have an effect: ftp.uu.net's insistence on IN-ADDR.ARPA mappings is the one that pops into my mind immediately. Some experiments, like exp39, involved moving root nameservers into a subnet of 39/8. However, nobody has yet said, "I am Playbeing, I have content people want to get to, I can leak a /32 if I want to, and everyone will have to carry it or explain to their users why they can't get their sex-on-demand". Perhaps that's because people are afraid that there is so much other interesting content out there that disconnectivity of any sort from their customer-base would be fatal, in that users would find alternatives fairly quickly. "Click here." (time passes) "Error." This happens so frequently and for so many reasons that friends of mine who are somewhat more typical dialup users would simply ignore the link or site and move on to something else.[*] There certainly is alot of competition on the content front these days. Can a big web site afford to have people thinking, "stoopid Netscape, their server is down"? Or would they be crafty and say, "all our information has now moved to _a new site_; if you get a time-out error then you should _send email to your Internet Service Provider_ telling them so"? Interesting stuff. Sean. [*] I'm different. I want to know why it doesn't work. I gather that doing traceroutes and looking at routers is atypical behaviour. From huitema at pax.inria.fr Mon Jan 29 10:40:34 1996 From: huitema at pax.inria.fr (Christian Huitema) Date: Mon, 29 Jan 1996 10:40:34 +0100 Subject: Policy Statement on Address Space Allocations Message-ID: At 11:22 AM 26/1/96, Sean Doran wrote: >| > 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. There is at least one very simple response. Set up some deviant CIX, say IX195-8, let everyone with a shortish 195/8 prefix connect to it either directly through their own provider, or indirectly through some tunnel, and have IX195-8 announce reachability of 195/8. That is, in short, altern topology to meet addresses when the converse is too hard. KRE detailed that for the general case, but it would be even simpler in the case of RIPE, since all the allocated network numbers are in the same geographical area. Christian Huitema From huitema at pax.inria.fr Mon Jan 29 10:40:40 1996 From: huitema at pax.inria.fr (Christian Huitema) Date: Mon, 29 Jan 1996 10:40:40 +0100 Subject: Policy Statement on Address Space Allocations Message-ID: At 8:04 PM 27/1/96, Hank Nussbacher wrote: >What this has to do with RIPE allocation policies is beyond >me. Everyone in the European realm suffers from extremely high >tariffs. So what? Because tariff distort topologies. In the short term, if you drew a map that used tariffs as the metric of your topology, the Atlantic would hardly be larger than the Rhine. This in itself is at cross purpose with the local implementation of CIDR, i.e. allocation of addresses to European networks from a European block by the RIPE NCC. If you look at the medium term, the perspective is even more interesting. Deregulation will gradually take place in the next three years. It will most probably result in lower tariffs for some lines, but not all, and definitely not at the same time. Take the map which I mentioned above. Imagine it printed on a fin sheet of elastic rubber, not paper. The effect of deregulation is that for the next three years the rubber will be constantly deformed, shrinking here and inflating there, and you are very lucky if you can predict where and when. To believe that this would not have some influence on addressing and internetworking is at least shortsighted. Christian Huitema From amb at Xara.NET Mon Jan 29 11:36:06 1996 From: amb at Xara.NET (Alex.Bligh) Date: Mon, 29 Jan 1996 10:36:06 +0000 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Fri, 26 Jan 1996 15:18:25 GMT." <96Jan26.151836-0000_est.20615+346@chops.icp.net> Message-ID: <199601291036.KAA29599@diamond.xara.net> Sean, > > | PS: Here's Sprint's sister company's current announcement of routes > | *originating* in its AS as I see them - I do hope Sprint takes the honest > | path if it does refuse to carry short announcements and not route all bar > | 4 of these nets, as well as a similar long list from AS1239 :-) I'm > | not convinced Sprint has the moral highground here.... > > Moral high ground does not interest me. Working networks > interest me. ... > As you note, AS 4000 is run by a different company, and you > shouldn't punish them just because I'm an arrogant asshole, > as I have no control over or involvement with their routing > strategies. > > (I'm not even sure that I'm entirely popular over there. ;-) ) > > However, yes, they are not aggregating as well as they could > be, and are announcing more-specific-routes that are > completely subsumed by aggregates. > That wasn't the point I was trying to make. What I was saying is that there are some of us who are tyring, within the boundaries set for us by RIPE, to announce as few announcements as possible for the space we have (ends up being /19s). There are other providers (including Sprint customers, and sorry to single out GSL but it was an easy target) who aren't. Your proposed filtering scheme gives providers like myself who are doing everything we can a problem, but doesn't actually incentivise some of the prime offenders (i.e. your customers) to do anything about the problem. Thus saying you are interested in working networks doesn't really cut any ice - there are many providers like us for whom no amount of renumbering within the current RIPE guidelines is going to give your routers less CPU load - all it will mean is the network will work *less* well (or rather your net will work less well in that it will give less connectivity). If you want to encourage people to use the optimum numbering schemes, make it hurt for those who can actually do something different first (i.e. anyone announcing loads of /22, /23 /24 routes etc.). Alex Bligh Xara Networks. From geoff at globalnet.co.uk Mon Jan 29 11:55:29 1996 From: geoff at globalnet.co.uk (Geoff Campbell) Date: Mon, 29 Jan 1996 10:55:29 +0000 Subject: Policy Statement on Address Space Allocations Message-ID: <199601291056.KAA04129@gandalf.globalnet.co.uk> > From: Ronald Khoo > That's too simplistic. A /19 in the Netherlands may well make sense. > In the UK it would be far too small, for ANY of our registries. That may well be the case with Demon Internet, who allocate a fixed IP address per customer, but for ISPs like ourselves at Global who use dynamic addressing, a /19 is fine - I've just renumbered my network to handle the next 37,500 dialup customers using one half of our /19, the only reason I shall need more in the next couple of years is if we sell lots of large leased line setups, that all need their own IP space. Regards, Geoff Campbell Technical Director Global Internet Ltd. From amb at Xara.NET Mon Jan 29 12:09:20 1996 From: amb at Xara.NET (Alex.Bligh) Date: Mon, 29 Jan 1996 11:09:20 +0000 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Sat, 27 Jan 1996 10:34:51 +0100." <9601270934.AA29299@ncc.ripe.net> Message-ID: <199601291109.LAA00338@diamond.xara.net> Daniel Karrenberg wrote: > > > "Alex.Bligh" writes: > > > > You are not distinguishing (initial) allocation from announcement. > > Correct. This is because it is *only* the allocation that a regional > registry has *control* over. After that we can only have *influence*. > > > Your guarantee is worthless in the sense that it only gurantees that > > the announcements (as opposed to allocations) can be aggregated if > > each window allocation is tied to a single AS, > > I wouldn't call that worthless exactly, because the method has > shown some successes. > > > and thus, for instance that > > none of the allocation is for PI space > > I do not care about PI space. Those wanting it have had ample warning. Neither do I. > > or for allocation to customers > > who aren't local-IRs but have their own AS etc. etc. > > There you are! Cases of genuine need for a seperate announcement > (multihomed) are not covered by the guarantee. But my expectation > is that their number can be offset by bigger aggregates. > Note that the number of routes *currently* announced under 193/8 and > 194/8, which have some room for improvement, is quite low already. > Actually they are both within the theoretical limit of a /18 filter > which is 2047 routes. > > > You also have the problem > > that currently it is impossible for local-IRs to allocate blocks > > of IP numbers that wouldn't be filtered out to multihomed customers > > (with their own AS - thus almost inevitably requiring a separate > > announcement) where that customer under the RIPE rules isn't 'justified' > > in getting a /19 (too small, for instance). Conservation vs. aggregation > > again. What is your recommendation on this? > > I fully agree that this is a problem. I believe that the only > real solution to this is to reduce *unneeded* announcements as much > as possible. This needs a routing registry and tools. OK, point taken. But AFAIK RIPE *still* works against this goal by giving only one window. Case in point: Our current window is /19, and all our announcements are maximally aggregated. Jo Customer comes along to me and says 'I want to go multihomed with you as a second provider, currently I have 8 class C's but they are all spread about the place'. Me 'You need to renumber then esp. as your class C's are within your current providers aggregate announcments (even though they are old, and thus technically PI' (there, that's me doing my bit for aggregation). Them: 'OK, give us a /21 to renumber into, you are a local-IR and we aren't'. Currently I have 2 choices as far as I can make out, give them a bit of my /19, break up my nice aggregate and ensure loads of extra announcements (and that probably none of them get routed by anyone applying prefix based filtering), or give them a new /19 all of their own (you've said it, that's the minimum size allocation) which actually solves their problem and mine, but this isn't an option currently available because currently it's one window per local-IR. So they have to go and become a local IR. > This is why pure prefix length filtering is the wrong soloution. > It just favours the big providers. Yup, I'd agree with us. And I hope Sprint have had a long chat with their lawyers over there as some of the more litigious smaller US providers are busy thumbing through the anti-trust laws, apparently. > ... > > This bartering does not solve the general problem and does not > claim to. It is just part of the effort to keep things working. Yup. Alex Bligh Xara Networks. From smd at cesium.clock.org Mon Jan 29 15:40:25 1996 From: smd at cesium.clock.org (Sean Doran) Date: Mon, 29 Jan 1996 06:40:25 -0800 Subject: Hmmmmmm... Message-ID: <96Jan29.064039pst.5577@cesium.clock.org> >From the latest Cook Report: | InterNIC now dealing with IP address requests from 50 new ISP start ups | every week. By sending them to their upstream providers InterNIC has | gone from handing out 800 CIDR blocks in the /24s to /21s ranges to about | 30 /24s - /21s per month. Sean. From peter at demon.net Mon Jan 29 16:13:52 1996 From: peter at demon.net (Peter Galbavy) Date: Mon, 29 Jan 1996 15:13:52 +0000 (GMT) Subject: Policy Statement on Address Space Allocations In-Reply-To: <9601261753.AA20185@ncc.ripe.net> from "Daniel Karrenberg" at Jan 26, 96 06:53:56 pm Message-ID: <9601291514.aa12876@office.demon.net> > > I wish I knew. In this I am the worst type of couch potato. .... > > So stop critising "paradigms" without proposing better ones or at least > research the rationales and history behind them. OK OK. I am trying to make some form of contribution :) Give me a little time. > > And in the case of (I am guessing) > 70% of RIPE NCC allocated addresses > > are not. > > First you missed the emphasis on *somewhat*. Second you are guessing wrong. OK. But for informational purposes is there a figure available ? > From both of the above it seems that you only know of and are only concerned > with your own particular situation. I would have to say, from reading my own e-mails that maybe I have given that impression. Let me reqind a bit and summarse it differently below... This should *not* have been the case. > > This is no ones "fault", just the way the policy is. Therefore > > I say the policy is WRONG. > > What is the better policy? Maybe that is what this thread can begine... a discussion of a different/ better policy ? Who knows ? > More local topology than continental one is *very* important. Yes. How can we help to make this happen ? Are there tools, that if we make sure our RIPE records are up to date that will help you in your allocations ? ISPs are not given the opportunity to apply for topological *and* portable address space (eg we are multihomed to the US - Sprint allocations are not "good enough") from the InterNIC - we are sent to the RIPE NCC because our physical location happens to be within a geographical domain managed by the RIPE NCC. > > We have e-mail for admin - it is timezone orthoganal. The existance > > of the RIPE NCC should just be remote, local staff for the InterNIC. > > Fine with me. Do RIEP and theother contributors agree? > We can re-organise starting next week. I am not sure I meant you to agree with me on this one... :-) > > If the RIPE NCC applies a "local model" then it is not conforming > > to the policies of IANA and the IAB that you keep referring to. > > The RIPE NCC applies local policies within the boundaries of the global > policies. The problem is that various people posting to this list change which set of policies they refer to whenever the "other" set suits better for their arguments. One set of goals please. Please. > I could help you washing in detail but I do not think this is appropriate > in all these fora. For the record I will summarise: > > Demon is statically assigning IP addresses to dialup customers on a > large scale. This results in adresses being used per customer and not > per dial-in port. Obviously then number of customers is less limited > than that of dial in ports. There is concern about the wastefulness of > this practise on a large scale and the non-linear effects it could have > on address space usage. Hence it is *global*, read IANA, policy to > strongly discourage this practise and not to allocate more addresses > than three months worth of usage. This is not just an NCC policy! In the way we assign numbers, it is very linear. Just not all the hosts are reachable all the time. We return ICMP Host Unreacable from our core routers when a dial up customer is not logged in. I will try to explain some of the reasons we do it this way below. But reasons do not change or infulence the current RIPE/IANA policies - which is the thing I am trying to highlight for "discussion". I am *NOT* trying (I know that it may look that way) to say that the RIPE NCC is full of people who don't care and are not doing "the right thing". This is patently untrue... Daniel et al are doing a very good job within their interpretation of (in my belief) an incorrect, incomplete frame work. > Indeed we have allocated you a /19 to start with in addition to the > address space you have been allocated for other purposes than dial up IP. > Of course you will receive further allocations within the range of the > above policy whenever you need them. Of course we will do our best to > make the further allocations aggregateable with previous ones. The primary issue with this one is not that of not getting the address space, but of getting additional address space in a timely fashion. By the time I write this we would have taken on another 150 - 200 customers since Friday. That is almost one /24. This (at a guess for growth) gives us about 2 months for a /19. It takes too long (in the real world - with holidays, sickness etc) to apply for a new allocation only days or a week before this (or the next) block runs out. If we can apply for a /19 at least 30 days before we need it then this may solve the problem, but I do not think this would work within the current applications processing methods. Or would it ? I don't actually know at this point, since we have been very concerned at how long it took to get the last block. > Assignments of address space by local IRs to customers have to be > registered in the RIPE (whois) database. You have raised that your > commercial interest of keeping your customer list confidential should > outweigh this registration requirement in the case of individuals > because of the special characterisitcs of the (consumer) market you > operate in. We have recognised that the tradeoff between the benefit of > registration and the commercial interests of individual dialup providers > is indeed special and consequently have worked with you(!), IANA and the > other regional registries to establish a global policy for this special > case. This policy has to take into account the need for verification of > assignments since the registration requirement has been dropped and the > database is not available for verification. It is not (even) a commercial confidence interest, since I believe that the RIPE NCC could be trusted with this information, but one of *LAW*. The EEC (as it was then) quite correctly required the UK parliment to pass a law called the Data Protection Act in 1984. In my opinion this act is far *too* weak, but even in its current form does not allow us to pass these detais on, with a small number of exceptions. > We have worked with you in this matter, you have agreed to the result. > I think it is *very* inappropriate to publicly abuse those who have > worked with you and to throw polemics at compromises some of which you > have even suggested and all of which you have agreed to. I will leave > the polemics for what they are. OK. OK. I will publicly apologise for any offense I may have given to the *people* involved. You have worked very hard trying to be fair. I just do not think that the underlying policies from which this fairness is drawn is correct for all situations. I will not apologies for critising policies that I believe to be flawed or the organisations that blindly implement them. I *do* believe that people run these organisations and that the policies should allow these people to behave like human beings and make judgements based on experience rather than a fixed, immutable set of criteria. > > I wish I had the time, but it appears that we will have to make the > > time to get more involed. sigh. > > Yes, it is more appropriate than polemicising publicly. I am here now in Amsterdam at the RIPE meeting, I am happy to try to make a contribution. > > The RIPE NCC model probably would work if it took into account that > > fact that its members are (on the whole) commercial organisations > > that sell differing products and services and have different > > requirements of the NCC. This does not appear to be the case. > > You have received sufficient address space for your present needs > and you have been assured that -unless there are policy changes- you > will receive enough for your future needs. The same policy is > applied to everyone. > > --- Polemic mode on ---- > > I have the slight suspicion that for you the only good model is > one that does exactly what *you* want, everyone else be damned. > > --- Polemic mode off ---- Nope. I am always open to critisism and people pointing out me errors. I do not think that the only policy that would work is the one that would fit my situation, but owing to a lack of involment in the "politics" of the Internet in the past 24 months or so (how long I have been in the serice provider game officially) those policies have happened without me seeing them, and so the bits that could make it all work for me/us have been either missed or overlooked. For a bit of background on why Demon use static IP allocation, and how, for those who are interested as opposed to just being opposed... When the service started (and I was just a customers) there was *NO* other reasonably priced IP service for individuals / small companies in the UK. Anyone want to disagree ? Right... Demon were set up to provide and Internet *service* not *access*. Please note my terminology on this one; Internet Service: Being a real host, providing full SMTP capabilities (ie mail transport, not mail access), fixed/unique FQDN, in effect being a full Internet site when connected. Internet Access: Getting access to WWW/POP3 etc, "using" the Internet to get information through search engines, e-mail stored in a mailbox etc etc. Being a Web surfer tupe consumer. It is difficult to enumerate the difference to well, but I think most people who have thought about it could. Some people also think of it exactly the other way around. We now have very close to 60000 dialup customers, each with their own FQDN and IP address. So far this "just" overflows a class B, once we include all all the other bits of equipment and the slightly sparse address space in the "secure" /24 subnets. Thre are a number benefits of static IP, just as there are disadvantages. We use a proprietary dynamic routeing protcol, which has been worked on very heavily over the years to provide (effectivley) invisible routeing changes when customer log in to the lines. The disadantages are the point of this discussion. I know a number of customers who use the IP addresses of the dialups for security and filtering (do that with a dynamic IP address). Another one (not so often used, but damned useful) is the ability to continue TCP sessions between disconnets (many a large FTP saved my this). There are others, but this e-mail is long enough already. This is a religious argument that I do not believe has any *real* impact on address space allocation except for a cosmetic one. So what if we gave almost every PC/Mac/UNIXen box in the world an IP address. Even in IPv4 space there are plenty for the coming years. IPv6 may be adopted for real in a few years, and by then it all changes anyhow. *ANOTHER* important one, but much more unlikely, is that we may one day (and pigs will grow wings and fly) offer all our customers a *permanent* connection to the 'net - what then ? The telecoms technology allows for it - it is just down to tariffing. Just a thought. Again - I have not inteded any of this as an attack on the dedication of the RIPE NCC staff, I just get carried away (I think I am human after all), Anyway, enough of this, I need to do some "work" here - I left my colleagues at RIPE while I cam to our offices to try to catch up with e-mail... Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From peter at demon.net Mon Jan 29 16:33:43 1996 From: peter at demon.net (Peter Galbavy) Date: Mon, 29 Jan 1996 15:33:43 +0000 (GMT) Subject: Policy Statement on Address Space Allocations In-Reply-To: <9601271817.AA02806@ncc.ripe.net> from "Hank Nussbacher" at Jan 27, 96 08:04:22 pm Message-ID: <9601291533.aa19551@office.demon.net> > >All this impacts very severely on the commercial decisions taken as to > >the routeing of traffic. I would much rather buy more lines to the US > >and let the traffics flow back to Europe then to just buy lines to > >Europe. Luckily, commercial concerns are not the only contraints > >within which we have to work. > > What this has to do with RIPE allocation policies is beyond > me. Everyone in the European realm suffers from extremely high > tariffs. So what? Sorry - I do not know your background, but here in the UK, in business, money and financing matters. If I can show that I could buy two lines for the same amount of money; where on would be 20% utilised on average and the other at 80% then any money (wo)man will take the second option as it is *seen* to be better use of the money. > You and hundreds of other companies approach RIPE with the same > story of how big they are, how large their investors are, how > their network is gonna take the world of the Internet by storm, > and therefore they deserve a /16 or even a /15. If RIPE followed > your logic, there would be no more address space left. I have to say it, even if I was trying not too, - but we *are* the largest dialup IP provider in Europe. Anyone want to argue ? We are not a new provider asking for a new allocation. We have a large, installed customer base that is growing at between 10 and 15% per *month*. This is difficult enough to manage in terms of our infrastructure. I am doing two things in Amsterdam this week. One is the RIPE, the other is visiting our Amsterdam operation, which is due to go live very soon now. Other countries to follow. We are not new comers here is what I am trying to get across. I think we have suffered in terms of the Internet politics because we have been too busy being concerned about our customer base... > Use dynamic IP like the rest of us. We all realize the drain of > IP addresses and try our best to maximize the addresses. Why > should you be different? Because we have a grwoning customer base that has been buying that particular product fastre than we can sell it for 3 1/2 years now. > It all depends on your ego. You could just look at them as > an organization assigned the tough role of making sure there > are IP addresses available in 1999. You see it as God. A viewpoint > based on your world view. Roll on IPv6 - that will be hell for us, but we will cope. I do not want "fix" what isn't actually broken now, or is likely to be. > IBM has 460 POPs in over 40 countries and uses dynamic IP addresses. > I can be in London or NYC or Tel Aviv and still use my SLIP connection > to read my mail wherever I am. Why should you have static IP addresses > for something others can do the dynamic way and thereby conserve > IP address space? Your mail yes, but can you access secure systems that use IP filtering ? Can you run a BBS from midnight to 5am and p expect people to find your host by domain name ? Can you get SMTP mail delivery ? etc etc. We have always been selling a full Internet connection, not just access. Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From peter at demon.net Mon Jan 29 16:22:39 1996 From: peter at demon.net (Peter Galbavy) Date: Mon, 29 Jan 1996 15:22:39 +0000 (GMT) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Christian Huitema" at Jan 29, 96 10:40:40 am Message-ID: <9601291523.aa16133@office.demon.net> > Because tariff distort topologies. In the short term, if you drew a map ... Thanks to Christian, who said what I was trying to get across. Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From iljitsch at unix1.bart.nl Mon Jan 29 16:50:34 1996 From: iljitsch at unix1.bart.nl (Iljitsch van Beijnum) Date: Mon, 29 Jan 1996 16:50:34 +0100 (MET) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601291109.LAA00338@diamond.xara.net> from "Alex.Bligh" at Jan 29, 96 11:09:20 am Message-ID: <199601291550.QAA18360@unix1.bart.nl> > to me and says 'I want to go multihomed with you as a second provider, > currently I have 8 class C's but they are all spread about the > place'. Me 'You need to renumber then esp. as your class C's are > within your current providers aggregate announcments (even though > they are old, and thus technically PI' (there, that's me doing my > bit for aggregation). Them: 'OK, give us a /21 to renumber into, > you are a local-IR and we aren't'. Currently I have 2 choices as > far as I can make out, give them a bit of my /19, break up my > nice aggregate and ensure loads of extra announcements (and that > probably none of them get routed by anyone applying prefix based > filtering), or give them a new /19 all of their own (you've > said it, that's the minimum size allocation) which actually > solves their problem and mine, but this isn't an option > currently available because currently it's one window per local-IR. > So they have to go and become a local IR. No they don't. You can ask the RIPE NCC for special PI space to assign to this customer. It seems they have a "chemical waste dump" to satisfy this kind of requests from. From kimh at internic.net Mon Jan 29 17:03:54 1996 From: kimh at internic.net (Kim Hubbard) Date: Mon, 29 Jan 1996 11:03:54 -0500 (GMT-0500) Subject: Hmmmmmm... In-Reply-To: <96Jan29.064039pst.5577@cesium.clock.org> from "Sean Doran" at Jan 29, 96 06:40:25 am Message-ID: <199601291603.LAA07566@ops.internic.net> > Wrong....by sending everyone connecting to the Internet to their upstream provider the number of assignments has dropped. Not just startup ISPs. Kim > >From the latest Cook Report: > > | InterNIC now dealing with IP address requests from 50 new ISP start ups > | every week. By sending them to their upstream providers InterNIC has > | gone from handing out 800 CIDR blocks in the /24s to /21s ranges to about > | 30 /24s - /21s per month. > > Sean. > > From gcook at tigger.jvnc.net Mon Jan 29 17:31:23 1996 From: gcook at tigger.jvnc.net (Gordon Cook) Date: Mon, 29 Jan 1996 11:31:23 -0500 (EST) Subject: Hmmmmmm... In-Reply-To: <199601291603.LAA07566@ops.internic.net> Message-ID: oops. Bad antecedent to the pronoun "them" from shortening the longer announcement. My apologies. ********************************************************************* Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 USA Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook at cookreport.com Corporate Site Lic. $650 http://pobox.com/cook/ for new COOK Report Glossary of Internet terms ********************************************************************* On Mon, 29 Jan 1996, Kim Hubbard wrote: > > > Wrong....by sending everyone connecting to the Internet to their upstream > provider the number of assignments has dropped. Not just startup ISPs. > > Kim > > > >From the latest Cook Report: > > > > | InterNIC now dealing with IP address requests from 50 new ISP start ups > > | every week. By sending them to their upstream providers InterNIC has > > | gone from handing out 800 CIDR blocks in the /24s to /21s ranges to about > > | 30 /24s - /21s per month. > > > > Sean. > > > > > > From amb at Xara.NET Mon Jan 29 17:42:34 1996 From: amb at Xara.NET (Alex.Bligh) Date: Mon, 29 Jan 1996 16:42:34 +0000 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Mon, 29 Jan 1996 16:50:34 +0100." <199601291550.QAA18360@unix1.bart.nl> Message-ID: <199601291642.QAA09648@diamond.xara.net> Iljitsch van Beijnum wrote: > No they don't. You can ask the RIPE NCC for special PI space to assign to > this customer. It seems they have a "chemical waste dump" to satisfy > this kind of requests from. Ah. That will be the "chemical waste dump" that Daniel K said he didn't care about whether it got routed or not (no offence Daniel - neither do I), and is all but unaggregatable so presumably Sprintlink et al. won't want to waste their CPUs routing it as well. What hope for a customer with those IP numbers? Alex Bligh Xara Networks From iljitsch at unix1.bart.nl Mon Jan 29 18:03:41 1996 From: iljitsch at unix1.bart.nl (Iljitsch van Beijnum) Date: Mon, 29 Jan 1996 18:03:41 +0100 (MET) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601291642.QAA09648@diamond.xara.net> from "Alex.Bligh" at Jan 29, 96 04:42:34 pm Message-ID: <199601291703.SAA23699@unix1.bart.nl> > > No they don't. You can ask the RIPE NCC for special PI space to assign to > > this customer. It seems they have a "chemical waste dump" to satisfy > > this kind of requests from. > Ah. That will be the "chemical waste dump" that Daniel K said > he didn't care about whether it got routed or not (no offence > Daniel - neither do I), and is all but unaggregatable so presumably > Sprintlink et al. won't want to waste their CPUs routing it as well. Well that's their policy, so it's their problem. As an ISP selling "global Internet connectivity" I may choose to take that policy into consideration, but I'm sure most people don't give a damn. (This is starting to get more and more like FidoNet...) > What hope for a customer with those IP numbers? The anti-trust laws. ;-) Iljitsch From jnc at ginger.lcs.mit.edu Mon Jan 29 19:37:33 1996 From: jnc at ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 29 Jan 96 13:37:33 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: <9601291837.AA01730@ginger.lcs.mit.edu> From: "Joel M Snyder, writing fool" The company wishes to have more than one connection to the Internet through more than one of the major providers From: lodge at houston.omnes.net (Mathew Lodge) its upstream provider ... They also want to be multi-homed from day one. They currently offer all sorts of fully redundant data services, and understandably they can't see why they should have a single point of failure in their global Internet access. Oh, good, the multi-homing discussion again. (The loud "bang" you just heard was Noel blowing out his brains in sheer desperation and frustration.) Here's a repeat of a previous post to a different list: For those who aren't up on the technical background to multihoming, you should consider consulting the Big-Internet archives from the end of September '95 for a long discussion of it. (In particular, see the thread "Discussing encap/mapping proposal", especially the messages of Thu Aug 31 23:33:12 1995 from me, Fri, 01 Sep 1995 11:13:39 -0500 from Scott M. Ballew, and Fri Sep 1 13:25:59 1995 and Sun Sep 3 01:23:59 1995 from me, which discuss the theoretical background in some detail. The thread "Multihoming", especially the messages Fri Sep 1 11:20:25 1995 and Mon Sep 4 14:26:06 1995 also contains some valuable material.) For those who don't wish to paw through all that, here are the salient points, quickly: 1. Multihoming for robustness adds new capability to the system, and that new capability does not come without cost, the cost being greater routing overhead. The amount of routing overhead will vary depending on many factors. 2. Connectivity-based addressing (i.e. the thing that "provider-based" is a subset of) provides routes at least as good, and at as least as small a cost in routing overhead, as any other addressing scheme. (Connectivity-based addresses for multi-homed sites allow us to use less than global scopes for the advertisement of routing information about such sites. Non-connectivity-based addresses do not have this characteristic; they require advertisment through the entire network.) 3. The cost in routing overhead (at least in conventional hop-by-hop routing systems such as the current Internet) is dependent on how far apart, in the connectivity topology, the multiple connections are. (More widely separated connections can increase the routing overhead with little payback in increased reliability.) 4. The cost further depends (again, in the same kind of systems) on how optimal you want routes to be if both links are up, how optimal you want them to be if one is down (and it will vary depending on whether it's a primary or secondary). I hope everyone will keep these 4 main points in mind in any discussion on multi-homing. Now, a few extra comments appropriate to this case: There is *no way*, in the current overall routing architecture (which uses exchange of routing tables) to add multihoming for fault tolerance without a cost in routing overhead. Providing this fault-tolerance is not zero-cost in *any* scheme I can conceive (TANSTAAFL, surprise, surprise), but some are better than others. Since redesigning the entire architecture is not something we can do this week, I'll leave the pleasant contemplation of such alternatives to academic, ivory-tower, environs. We can *easily* limit the amount of routing overhead caused by multi-homing among different providers if we provide some structure in the addressing hierarchy *above* providers. (To be technical, this will allow less than global advertisement scopes of such multi-homed entities.) Since this could necessitate renumbering most of the 'Net, I don't expect it to happen anytime soon. We can also limit the amount of routing overhead by providing configured AAB boundaries for a given multihomed site which enclose a path between the primary and secondary providers. Since this will in some cases require cooperation among multiple providers, as well as either i) massive amounts of manual mechanical configuration bookkeeping, or ii) automated tools we don't have yet, don't hold you breath for that one either. Noel PS: If you didn't understand that last paragraph, read the references before you speak. From Joel_M_Snyder at Opus1.COM Mon Jan 29 19:51:29 1996 From: Joel_M_Snyder at Opus1.COM (Joel M Snyder, writing fool) Date: Mon, 29 Jan 1996 11:51:29 -0700 (MST) Subject: Chiappa blows his brains out (was Re: Policy Statement) In-Reply-To: "Your message dated Mon, 29 Jan 1996 13:37:33 -0500" <9601291837.AA01730@ginger.lcs.mit.edu> Message-ID: <01I0KYO8A6Q2CG8W7U@Opus1.COM> > Oh, good, the multi-homing discussion again. > (The loud "bang" you just heard was Noel blowing out his brains in sheer > desperation and frustration.) You're misinterpreting my question. The fault must be mine; I guess that my query wasn't specific enough. Let me put it another way: GIVEN that there exists some set of organizations who want to purchase multiple T1s from multiple independent suppliers for purposes of reliability and load sharing yet have need for less than 255 unique IP addresses, and GIVEN that certain extremely popular software products (such as Netscape Navigator) which are important to these organizations were developed by programmers who seem to have no knowledge of either efficiency or the way that the Internet works, and GIVEN that I have sufficient knowledge about routing as is necessary to fully understand every technical issue involved, and GIVEN that I have a rudimentary and imperfect understanding of the political and economic issues regarding IP numbering and the propagation of routes thereunto, HOW do I resolve the conflict between justifiable corporate service requirements and the expressed statements on these mailing lists the past few weeks which seem to imply that anyone who does not consume at least a /18 worth of address space is not worthy of being globally routed? I am asking, I suspect, not for a technical answer (there being none other than Chiappa's "it's gonna cost"), but the most politically correct answer to give the organization (which is not Netscape). jms Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX) jms at Opus1.COM http://www.opus1.com/jms Opus One PLEASE NOTE: The useful parts of Arizona changed from area code 602 to area code 520 on March 20, 1995. From edm at halcyon.com Mon Jan 29 20:19:04 1996 From: edm at halcyon.com (Ed Morin) Date: Mon, 29 Jan 1996 11:19:04 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: Message-ID: To some extent, isn't this how the Amateur Radio folks carve up the 44.*.*.* network? It might be an interesting experiment to use another class A net, sort of like the recent 39.*.*.* (or was it 38?) subnet experiment for such things as web farms, etc. that don't need large allocations, but could really benefit from multi-homing. Ed On Mon, 29 Jan 1996, Christian Huitema wrote: > At 11:22 AM 26/1/96, Sean Doran wrote: > >| > 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. > > There is at least one very simple response. Set up some deviant CIX, say > IX195-8, let everyone with a shortish 195/8 prefix connect to it either > directly through their own provider, or indirectly through some tunnel, and > have IX195-8 announce reachability of 195/8. That is, in short, altern > topology to meet addresses when the converse is too hard. KRE detailed > that for the general case, but it would be even simpler in the case of > RIPE, since all the allocated network numbers are in the same geographical > area. > > Christian Huitema > > > Ed Morin Northwest Nexus Inc. (206) 455-3505 (voice) Professional Internet Services edm at nwnexus.WA.COM From michael at memra.com Mon Jan 29 23:48:17 1996 From: michael at memra.com (Michael Dillon) Date: Mon, 29 Jan 1996 14:48:17 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <9601291514.aa12876@office.demon.net> Message-ID: On Mon, 29 Jan 1996, Peter Galbavy wrote: > ISPs are not given the opportunity to apply for topological *and* > portable address space (eg we are multihomed to the US - Sprint > allocations are not "good enough") from the InterNIC - we are sent > to the RIPE NCC because our physical location happens to be within > a geographical domain managed by the RIPE NCC. You are the biggest ISP in Europe aren't you? How big? Couldn't you spend a few quid on incorporating Demon Internet Services Inc. in the USA? Wouldn't you then be eligible for IP addresses from the US Internic? > > Demon is statically assigning IP addresses to dialup customers on a > > large scale. This results in adresses being used per customer and not > > per dial-in port. Obviously then number of customers is less limited > > than that of dial in ports. There is concern about the wastefulness of > > this practise on a large scale and the non-linear effects it could have > > on address space usage. Hence it is *global*, read IANA, policy to > > strongly discourage this practise and not to allocate more addresses > > than three months worth of usage. This is not just an NCC policy! > > In the way we assign numbers, it is very linear. Just not all the hosts > are reachable all the time. We return ICMP Host Unreacable from our core > routers when a dial up customer is not logged in. I will try to explain In a classless IPV4 world in which the old Class A address area is in production use, would we have enough available IP addresses for providers to do this on a large scale assuming that they would have near 100% utilization in the blocks that were being allocated statically? Didn't the experiment with 39/8 show that it was safe to allocate classlessly out of the old Class A addresses? Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael at memra.com From huddle at mci.net Mon Jan 29 23:56:19 1996 From: huddle at mci.net (Scott Huddle) Date: Mon, 29 Jan 1996 17:56:19 -0500 Subject: Chiappa blows his brains out (was Re: Policy Statement) Message-ID: <199601292256.RAA06145@new6.Reston.mci.net> Joel_M_Snyder at Opus1.COM writes > GIVEN that there exists some set of organizations who want to purchase > multiple T1s from multiple independent suppliers for purposes of > reliability and load sharing yet have need for less than 255 unique IP > addresses, and GIVEN that certain extremely popular software products (such > as Netscape Navigator) which are important to these organizations were > developed by programmers who seem to have no knowledge of either efficiency > or the way that the Internet works, and GIVEN that I have sufficient > knowledge about routing as is necessary to fully understand every technical > issue involved, and GIVEN that I have a rudimentary and imperfect > understanding of the political and economic issues regarding IP numbering > and the propagation of routes thereunto, HOW do I resolve the conflict > between justifiable corporate service requirements and the expressed > statements on these mailing lists the past few weeks which seem to imply > that anyone who does not consume at least a /18 worth of address space is > not worthy of being globally routed? > > I am asking, I suspect, not for a technical answer (there being none other > than Chiappa's "it's gonna cost"), but the most politically correct answer > to give the organization (which is not Netscape). You present a hard edge case that isn't particularly well met by the current infrastructure and it can't necessarily be done well or even done at all. (Sean's tricky chocolate-consulting hack excluded). Probably the best thing that be currently supported is getting two diverse connections to a single provider that can globally aggregate your network. The connections should go to different POPs and should follow seperate physical paths. This should provide you the desired reliability and load sharing. -scott From michael at memra.com Tue Jan 30 01:47:43 1996 From: michael at memra.com (Michael Dillon) Date: Mon, 29 Jan 1996 16:47:43 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601291642.QAA09648@diamond.xara.net> Message-ID: On Mon, 29 Jan 1996, Alex.Bligh wrote: > Ah. That will be the "chemical waste dump" that Daniel K said > he didn't care about whether it got routed or not (no offence > Daniel - neither do I), and is all but unaggregatable so presumably > Sprintlink et al. won't want to waste their CPUs routing it as well. > What hope for a customer with those IP numbers? They all pay somebody (NSP X) for the following service. NSP X announces an aggregate route, ???/8 or whatever, which Sprint and others *WILL* listen to. Then, NSP X reroutes traffic to all those different customers within it's own network. If NSP X needs to route through another NSP for some reason, then NSP X uses an IP tunnel to encapsulate the swampy address. Of course, this may cost more than the swamp customers want to pay, or the swamp customers may not be able to agree enough to create a globally routable aggregate. In that case, they don't get routed. Hopefully they can be convinced to renumber and release the swamp addresses, thus filling in the swamp and allowing somebody to build a nice parking lot, mall and attached apartment buildings. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael at memra.com From lodge at houston.omnes.net Tue Jan 30 02:09:04 1996 From: lodge at houston.omnes.net (Mathew Lodge) Date: Mon, 29 Jan 1996 19:09:04 -0600 Subject: Chiappa blows his brains out (was Re: Policy Statement) Message-ID: Scott, >You present a hard edge case that isn't particularly well met by the current >infrastructure and it can't necessarily be done well or even done at all. >(Sean's tricky chocolate-consulting hack excluded). Probably the best >thing that be currently supported is getting two diverse connections to >a single provider that can globally aggregate your network. The connections >should go to different POPs and should follow seperate physical paths. >This should provide you the desired reliability and load sharing. Thank you, thank you, thank you. This is exactly the kind of pragmatic advice I was looking for. Saying "don't do it" or "multihoming costs" is not helpful -- this sort of answer is. Regards, Mathew From cnielsen at vii.com Tue Jan 30 02:26:16 1996 From: cnielsen at vii.com (Christian Nielsen) Date: Mon, 29 Jan 1996 18:26:16 -0700 (MST) Subject: Policy Statement on Address Space Allocations In-Reply-To: Message-ID: On Mon, 29 Jan 1996, Ed Morin wrote: > To some extent, isn't this how the Amateur Radio folks carve up the 44.*.*.* > network? It might be an interesting experiment to use another class A net, > sort of like the recent 39.*.*.* (or was it 38?) subnet experiment for such > things as web farms, etc. that don't need large allocations, but could really > benefit from multi-homing. As an amatuer radio operator, I could pick up a class C here in SLC and route it over the internet. I don't think they should carve up another class A just for Web stuff, we are going to than have routing problems again on the net. It would be better that they go to one of thier providers. Yes I know that is not always an option. Christian Nielsen Vyzynz International Inc. cnielsen at vii.com,CN46,KB7HAP Phone 801-568-0999 Fax 801-568-0953 Private Email - Christian at Nielsen.Net PS :) From alan at gi.net Tue Jan 30 03:05:53 1996 From: alan at gi.net (Alan Hannan) Date: Mon, 29 Jan 1996 20:05:53 -0600 (CST) Subject: Chiappa blows his brains out (was Re: Policy Statement) In-Reply-To: <199601292256.RAA06145@new6.Reston.mci.net> from "Scott Huddle" at Jan 29, 96 05:56:19 pm Message-ID: <199601300205.UAA03539@westie.gi.net> Scott, ] You present a hard edge case that isn't particularly well met by the current ] infrastructure and it can't necessarily be done well or even done at all. ] (Sean's tricky chocolate-consulting hack excluded). Why is it excluded? It's too easy for people to make up reasons why they shouldn't have to think, or heaven forbid, renumber. I'd wager a pound of reese's pieces that Sean threw those paragraphs out of his mind, with less than an hour's thought. The tricky thing about Sean is realizing that he thinks about problem solutions, not excuses as to why the problems can't be solved. As for the reordering crisis, order the book from the Phonics people, it might help -> D-H-C-P. What? Your software doesn't support it? Erm, call your sales rep. Make threats; threaten to go to Microsoft who does. These things can be done, and the current state of the net can be much eased by providers enforcing prefix aggregation impetus. It could also be done by being "good net.citizens" and all that ruckus, but the masses don't move unless forced to. Somone needs to force them. Thank you, Sprint, for slowing the acceleration with your /19 policy. Now, let's see if we can't decrease the problem with historical prefix aggregation rules, or retirement so as to achieve the same effect. -alan From gherbert at crl.com Tue Jan 30 04:41:15 1996 From: gherbert at crl.com (George Herbert) Date: Mon, 29 Jan 1996 19:41:15 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Mon, 29 Jan 1996 11:19:04 PST." Message-ID: <199601300341.AA29303@mail.crl.com> > There is at least one very simple response. Set up some deviant CIX, say > IX195-8, let everyone with a shortish 195/8 prefix connect to it either > directly through their own provider, or indirectly through some tunnel, and > have IX195-8 announce reachability of 195/8. That is, in short, altern > topology to meet addresses when the converse is too hard. KRE detailed > that for the general case, but it would be even simpler in the case of > RIPE, since all the allocated network numbers are in the same geographical > area. I still think it would be worthwhile doing a top-down experiment with this sort of address structure around an easily aggregated geographical area, say the San Francisco Bay Area in northern California. I brought the idea up about 6 months ago and it floundered due to disinterest, but it still seems to be viable. -george william herbert gherbert at crl.com From dsiegel at rtd.com Tue Jan 30 05:40:06 1996 From: dsiegel at rtd.com (Dave Siegel) Date: Mon, 29 Jan 1996 21:40:06 -0700 (MST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601300341.AA29303@mail.crl.com> from "George Herbert" at Jan 29, 96 07:41:15 pm Message-ID: <199601300440.VAA16398@seagull.rtd.com> > > There is at least one very simple response. Set up some deviant CIX, say > > IX195-8, let everyone with a shortish 195/8 prefix connect to it either > > directly through their own provider, or indirectly through some tunnel, and > > have IX195-8 announce reachability of 195/8. That is, in short, altern > > topology to meet addresses when the converse is too hard. KRE detailed > > that for the general case, but it would be even simpler in the case of > > RIPE, since all the allocated network numbers are in the same geographical > > area. > > I still think it would be worthwhile doing a top-down experiment with > this sort of address structure around an easily aggregated geographical > area, say the San Francisco Bay Area in northern California. I brought the > idea up about 6 months ago and it floundered due to disinterest, but it > still seems to be viable. However, as Andrew w/UUnet pointed out some time ago, you end up providing transit in this way. If the goal is to only announce 195/8, any provider numbered in that block that is dual-homed with this "deviant CIX" and some other provider suddenly starts providing transit for the entire "deviant CIX". I highly doubt that this is desirable. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)623-9663 Network Engineer -- Regional/National NSPs (Cisco) dsiegel at rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/~dsiegel/ for an ISP." From gherbert at crl.com Tue Jan 30 05:53:57 1996 From: gherbert at crl.com (George Herbert) Date: Mon, 29 Jan 1996 20:53:57 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Mon, 29 Jan 1996 21:40:06 MST." <199601300440.VAA16398@seagull.rtd.com> Message-ID: <199601300453.AA11418@mail.crl.com> I wrote: > I still think it would be worthwhile doing a top-down experiment with > this sort of address structure around an easily aggregated geographical > area, say the San Francisco Bay Area in northern California. I brought the > idea up about 6 months ago and it floundered due to disinterest, but it > still seems to be viable. Dave replied: >However, as Andrew w/UUnet pointed out some time ago, you end up providing >transit in this way. >If the goal is to only announce 195/8, any provider numbered in that block >that is dual-homed with this "deviant CIX" and some other provider suddenly >starts providing transit for the entire "deviant CIX". >I highly doubt that this is desirable. I think that we solved that problem by providing full information for all of the routes to routers within the area, and none outside. If you wish to correct me, feel free. -george From asp at uunet.uu.net Tue Jan 30 06:46:48 1996 From: asp at uunet.uu.net (Andrew Partan) Date: Tue, 30 Jan 1996 00:46:48 -0500 (EST) Subject: Policy Statement on Address Space Allocations Message-ID: > I think that we solved that problem by providing full information for > all of the routes to routers within the area, and none outside. > If you wish to correct me, feel free. So everyone w/in the area can get to all of these sites (& since they have to carry full routes, they don't save any routing table space), and everyone outside of this area has no routes to any part of the area and thus can't get to any of these sites at all? Humm; if I understand you corretly, this seems to be a loose all around. --asp at uunet.uu.net (Andrew Partan) From hal9001 at panix.com Tue Jan 30 07:50:19 1996 From: hal9001 at panix.com (Robert A. Rosenberg) Date: Tue, 30 Jan 1996 01:50:19 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: At 6:09 1/29/96, Alex.Bligh wrote: > Currently I have 2 choices as >far as I can make out, give them a bit of my /19, break up my >nice aggregate and ensure loads of extra announcements (and that >probably none of them get routed by anyone applying prefix based >filtering), or give them a new /19 all of their own (you've >said it, that's the minimum size allocation) which actually >solves their problem and mine, but this isn't an option >currently available because currently it's one window per local-IR. >So they have to go and become a local IR. If the high /21 of your /19 is not Allocated, you just assign it to them and add ONE announcement of the /21 to supersede with the current /19. If it is not free but is sparsely populated you can move the stuff out to free it up or go to RIPE to get your /19 turned into an /18 (ie: get the /19 right after your current /19 [RIPE did give you the first /19 in a shorter prefix block didn't they?]) in exchange for returning the /21 worth of space [giving you 3 extra /21s worth of space], and divide that 2nd /19 into a /20, and 2 /21s giving them the 2nd /21 (still doing the same 2 announcements as you would if allocated out of your current /19). From jnc at ginger.lcs.mit.edu Tue Jan 30 08:34:03 1996 From: jnc at ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 30 Jan 96 02:34:03 -0500 Subject: Chiappa blows his brains out (was Re: Policy Statement) Message-ID: <9601300734.AA04810@ginger.lcs.mit.edu> From: Scott Huddle Probably the best thing that be currently supported is getting two diverse connections to a single provider that can globally aggregate your network. The connections should go to different POPs and should follow seperate physical paths. This should provide you the desired reliability and load sharing. This solution has been pointed out before. Also, Dorian Kim sent in a good message to the Big-Internet list talking about reliability (the stated goal of most multi-homing), and the 7 places you could do redundancy, and what was really important in achieving reliability, which contained a lot of good insight. Here's his message (appended). Noel -------- Date: Fri, 1 Sep 1995 03:57:16 -0400 (EDT) From: Dorian Rysling Kim To: ... big-internet at munnari.oz.au Subject: Re: Multihoming .... There are many places where redundancy can be achieved with multiple connections. 0) Equipment spares on site 1) Diverse local access of the two links 2) Diverse routing of the physical links into COs 3) Diverse routing to different local providers 4) Diverse routing to different regional providers 5) Diverse routing to different large transit providers (MCI, Sprint, ANS, Alternet, Eunet etc) 6) #5 + connection to the NAPs. All of the above give you redundancy at various single points of failures. In my experince, #0 - #2 should be considered as important in providing true redundancy as 4-6. In fact, in most cases, the most common case of outtages come from equipment failures, and circuits themselves, and sites who are looking for multihoming for the reason of redundancy should look at the cost of having 0-2, and think long and hard about whether multihoming is what they really need. -dorian From jnc at ginger.lcs.mit.edu Tue Jan 30 09:55:05 1996 From: jnc at ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 30 Jan 96 03:55:05 -0500 Subject: Chiappa blows his brains out (was Re: Policy Statement) Message-ID: <9601300855.AA05090@ginger.lcs.mit.edu> From: "Joel M Snyder, writing fool" GIVEN that I have sufficient knowledge about routing as is necessary to fully understand every technical issue involved Sorry, I guess I just assumed the wrong interpretation of what your question was about. (Also, to be honest, if we've got to the point that most everyone understands these issues, I guess it's time for the champagne... :-) GIVEN that I have a rudimentary and imperfect understanding of the political and economic issues regarding IP numbering and the propagation of routes thereunto I'm not sure anyone has a truly "global" view of this, although if one listens on this and other lists hard, one can start to get a view which integrates the large and small ISP's, equipment suppliers, etc, etc... GIVEN that there exists some set of organizations who want to purchase multiple T1s from multiple independent suppliers ... HOW do I resolve the conflict between justifiable corporate service requirements and the expressed statements ... that anyone who does not consume at least a /18 worth of address space is not worthy of being globally routed? To start with, this is another case where setting the size-based filter for routing updates is having deleritous effects. Again, all we're doing is creating a demand for address space, and as long as there is no well-modulated back-pressure on address space (such as charging for it), I'm not sure I see any easy way of dealing with it. Second, whether it's a /18 or a /24 is of no interest to the routing. Let's assuming we can separate the addressing issues out, to focus just on the routing cost, which is going to be the same *regardless* of how you resolve the address space issues. This is important: *** No matter how you do the addresses, you *still* have the problem that if *** a significant percentage of customers want to be multihomed, and we still *** don't have any mechanism or tools for reducing the scopes of those *** advertisements from global (such as I mentioned in my original message on *** this thread), we will find it technically impossible to provide this *** multihoming capability to a large number of users: we will be rerunning the *** very routing table growth (tracking local sites individually) that caused *** us to go to CIDR in the first place. I don't know about you, but I could do without a re-run of that particular learning experience! :-) Ideally, in solving this, I would take a monetary approach, which is to say "what are the true costs of this multihoming, and given that, is it important enough to the client for them to pay for it", but of course we don't have a charging mechanism for routes that would help to answer this, and maybe never will. So, I can't use that copout. Maybe a better question is to ask "what goal are they really after with multi-homing", because if the answer is "reliability", then perhaps they get more bang for their with things like multiple access lines, etc. I am asking, I suspect, not for a technical answer (there being none other than Chiappa's "it's gonna cost"), but the most politically correct answer to give the organization I understand that you have a very "bottom-line" concern, which is "what do we tell the customer", but I hope that this time I have made clear to everyone that there is no solution to the technical question of "can we provide multihoming on a large scale", *at least in the system as it stands today*. (I.e. if this is an important goal we need to get cracking on technical solutions...) Any policy discussion must take place in an environment which is aware of this technical constraint. Thus, your question about the policy conflict you pointed out is interesting and true, but ultimately not a critical one... Noel From amb at Xara.NET Tue Jan 30 11:34:25 1996 From: amb at Xara.NET (Alex.Bligh) Date: Tue, 30 Jan 1996 10:34:25 +0000 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Mon, 29 Jan 1996 16:47:43 PST." Message-ID: <199601301034.KAA01752@diamond.xara.net> > On Mon, 29 Jan 1996, Alex.Bligh wrote: > > > Ah. That will be the "chemical waste dump" that Daniel K said > > he didn't care about whether it got routed or not (no offence > > Daniel - neither do I), and is all but unaggregatable so presumably > > Sprintlink et al. won't want to waste their CPUs routing it as well. > > What hope for a customer with those IP numbers? > > They all pay somebody (NSP X) for the following service. > > NSP X announces an aggregate route, ???/8 or whatever, which Sprint and > others *WILL* listen to. Then, NSP X reroutes traffic to all those > different customers within it's own network. If NSP X needs to route > through another NSP for some reason, then NSP X uses an IP tunnel to > encapsulate the swampy address. This is not beautiful but would work but... > Of course, this may cost more than the swamp customers want to pay, or > the swamp customers may not be able to agree enough to create a globally > routable aggregate. In that case, they don't get routed. Hopefully they > can be convinced to renumber and release the swamp addresses, thus > filling in the swamp and allowing somebody to build a nice parking lot, > mall and attached apartment buildings. I obviously didn't quote enough at the top of the message. The point was tht the potential swamp user wants PI addresses so he can get a more resilient connection and go multihomed, which was the very reason why they were thinking about the swamp at all (rather than renumbering into my easilly routable PA space). Your solution is fine for obstinate people who don't want to renumber, but the guys I'm concerned with have a good reason for a short announcement (i.e. they want more resilience). Now I suppose 2 NSPs could announce ???/8 and aggregate those, and reroute them, however they would have to be the same 2 NSPs. Also we're back to the geographic issue on this one, in that its quite likely that the tunnel of which you talk would go back from mainland Europe, Stateside, and back to me in the UK, i.e. instead of one transatlantic hop you get 3. I'd love to hear any solution where they can renumber *within existing rules* (remember they aren't a local-IR and can't justify a /19), use AS based announcement (they have a very good reason for doing this), and get routed. Alex Bligh Xara Networks From iljitsch at unix1.bart.nl Tue Jan 30 11:39:15 1996 From: iljitsch at unix1.bart.nl (Iljitsch van Beijnum) Date: Tue, 30 Jan 1996 11:39:15 +0100 (MET) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Robert A. Rosenberg" at Jan 30, 96 01:50:19 am Message-ID: <199601301039.LAA00516@unix1.bart.nl> > At 6:09 1/29/96, Alex.Bligh wrote: > > Currently I have 2 choices as > >far as I can make out, give them a bit of my /19, break up my > >nice aggregate and ensure loads of extra announcements (and that > >probably none of them get routed by anyone applying prefix based > >filtering), or give them a new /19 all of their own (you've Suppose you have a customer that needs a /22 and they want to go multi-homed. Suppose you give them that /22 out of your /19 or /16 you got from the RIPE NCC. So they announce their /22 to you and to their other provider. But you keep announcing your /19 or /16. So if anybody were to filter the /22 announcement, your customer only suffers partial loss of connectivity, since you are still announcing an aggregate of their announcemnt (your original /19 or /16). Problem fixed. Anything else? ;-) From amb at Xara.NET Tue Jan 30 11:48:59 1996 From: amb at Xara.NET (Alex.Bligh) Date: Tue, 30 Jan 1996 10:48:59 +0000 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Tue, 30 Jan 1996 01:50:19 EST." Message-ID: <199601301049.KAA02133@diamond.xara.net> "Robert A. Rosenberg" wrote: > At 6:09 1/29/96, Alex.Bligh wrote: > > > Currently I have 2 choices as > >far as I can make out, give them a bit of my /19, break up my > >nice aggregate and ensure loads of extra announcements (and that > >probably none of them get routed by anyone applying prefix based > >filtering), or give them a new /19 all of their own (you've > >said it, that's the minimum size allocation) which actually > >solves their problem and mine, but this isn't an option > >currently available because currently it's one window per local-IR. > >So they have to go and become a local IR. > > If the high /21 of your /19 is not Allocated, you just assign it to them > and add ONE announcement of the /21 to supersede with the current /19. If > it is not free but is sparsely populated you can move the stuff out to free > it up or go to RIPE to get your /19 turned into an /18 (ie: get the /19 > right after your current /19 [RIPE did give you the first /19 in a shorter > prefix block didn't they?]) in exchange for returning the /21 worth of > space [giving you 3 extra /21s worth of space], and divide that 2nd /19 > into a /20, and 2 /21s giving them the 2nd /21 (still doing the same 2 > announcements as you would if allocated out of your current /19). Thankyou for the first constructive workable suggestion had so far. However, this has two problems. a) RIPE fidn't give me the first /19 in a shorted prefix block ( its x.x.160.x and .192.x is used), but no matter, I'll renumber if necessary :-( or persuade them to give me a /18 as well so I can do the above (hopefully). b) The /21 advert may be inbound filtered by a.n.other, which will be fine if it has an AS-Path through me (as the less specific route will work the same way) but won't when that path goes through the other provider with whom they are multi-homed, as the /21 will disappear entirely (3rd parties, i.e. a.n.other's customers will see neither), the /19 will be the only thing that is visible, and I'll just black hole their packets. Anyway this is several times better than the swamp. Oh well. Alex Bligh Xara Networks From curtis at ans.net Tue Jan 30 18:28:12 1996 From: curtis at ans.net (Curtis Villamizar) Date: Tue, 30 Jan 1996 12:28:12 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Mon, 29 Jan 1996 16:42:34 GMT." <199601291642.QAA09648@diamond.xara.net> Message-ID: <199601301728.MAA02096@brookfield.ans.net> In message <199601291642.QAA09648 at diamond.xara.net>, "Alex.Bligh" writes: > Iljitsch van Beijnum wrote: > > > No they don't. You can ask the RIPE NCC for special PI space to assign to > > this customer. It seems they have a "chemical waste dump" to satisfy > > this kind of requests from. > > Ah. That will be the "chemical waste dump" that Daniel K said > he didn't care about whether it got routed or not (no offence > Daniel - neither do I), and is all but unaggregatable so presumably > Sprintlink et al. won't want to waste their CPUs routing it as well. > What hope for a customer with those IP numbers? > > Alex Bligh > Xara Networks Alex, Here's my suggestion. If you put that multi-homed customer in a larger aggregate (have them pick one of the providers and allocate from their address space) all of the providers must then announce the more specific. Some providers will block the longer prefix. The longer prefix will be preferred and traffic will avoid going through those providers that block it. This might cause longer or suboptimal routing for the longer prefix. Providers everywhere will have either the shorter prefix or both, so full connectivity would exist. If the multi-homing is sufficiently localized within the topology (for example, multiple providers in the same region or country) there might be a chance to draw an aggregation boundary around the whole thing and block the longer prefix outside of that locality and avoid the possibility of suboptimal routing due to long prefix filtering. Curtis From marthag at MIT.EDU Tue Jan 30 20:00:38 1996 From: marthag at MIT.EDU (marthag at MIT.EDU) Date: Tue, 30 Jan 96 14:00:38 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: "[2385] in Classless InterDomain Routing" Message-ID: <9601301900.AA16710@maze.MIT.EDU> > > In message <199601291642.QAA09648 at diamond.xara.net>, "Alex.Bligh" writes: > > Iljitsch van Beijnum wrote: > > > > > No they don't. You can ask the RIPE NCC for special PI space to assign to > > > this customer. It seems they have a "chemical waste dump" to satisfy > > > this kind of requests from. > > > > Ah. That will be the "chemical waste dump" that Daniel K said > > he didn't care about whether it got routed or not (no offence > > Daniel - neither do I), and is all but unaggregatable so presumably > > Sprintlink et al. won't want to waste their CPUs routing it as well. > > What hope for a customer with those IP numbers? > > > > Alex Bligh > > Xara Networks > > > Alex, > > Here's my suggestion. > > If you put that multi-homed customer in a larger aggregate (have them > pick one of the providers and allocate from their address space) all > of the providers must then announce the more specific. Some providers > will block the longer prefix. The longer prefix will be preferred and > traffic will avoid going through those providers that block it. This > might cause longer or suboptimal routing for the longer prefix. > Providers everywhere will have either the shorter prefix or both, so > full connectivity would exist. > > If the multi-homing is sufficiently localized within the topology (for > example, multiple providers in the same region or country) there might > be a chance to draw an aggregation boundary around the whole thing and > block the longer prefix outside of that locality and avoid the > possibility of suboptimal routing due to long prefix filtering. > > Curtis > Except that if the shorter prefixed route goes down, half the world will not be able to see any route to site, which sort of defeats the purpose of being multi-homed. Martha Greenberg marthag at mit.edu From asp at uunet.uu.net Tue Jan 30 20:11:07 1996 From: asp at uunet.uu.net (Andrew Partan) Date: Tue, 30 Jan 1996 14:11:07 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601301904.AA24230@mail.crl.com> from "George Herbert" at Jan 30, 96 11:04:29 am Message-ID: > Half correct. Everyone in the area carries full routes for the block. > Everyone outside the area can listen to only the /8 advertisement. So these providers are providing the free transit to their non-customers? This does not make any business sense; it will not happen. --asp at uunet.uu.net (Andrew Partan) From gherbert at crl.com Tue Jan 30 20:04:29 1996 From: gherbert at crl.com (George Herbert) Date: Tue, 30 Jan 1996 11:04:29 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Tue, 30 Jan 1996 00:46:48 EST." Message-ID: <199601301904.AA24230@mail.crl.com> >> I think that we solved that problem by providing full information for >> all of the routes to routers within the area, and none outside. >> If you wish to correct me, feel free. > >So everyone w/in the area can get to all of these sites (& since they >have to carry full routes, they don't save any routing table space), >and everyone outside of this area has no routes to any part of the area >and thus can't get to any of these sites at all? Half correct. Everyone in the area carries full routes for the block. Everyone outside the area can listen to only the /8 advertisement. Once their packets get within the geographical area, then the routers will know what to do with it. So, no matter how bad a swamp this block becomes (and that would be avoided if possible, but...), it doesn't impact the outside world very much (1 advertisement and more-than-normal care on filter sets, since this is a special case). -george From michael at memra.com Tue Jan 30 20:36:59 1996 From: michael at memra.com (Michael Dillon) Date: Tue, 30 Jan 1996 11:36:59 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: Message-ID: On Tue, 30 Jan 1996, Andrew Partan wrote: > > Half correct. Everyone in the area carries full routes for the block. > > Everyone outside the area can listen to only the /8 advertisement. > > So these providers are providing the free transit to their > non-customers? > > This does not make any business sense; it will not happen. The proper solution is for all these companies to form a consortium. The consortium would run the NAP and contract with multiple NSP's for service. In that case, the NSP's are not providing transit to non-customers because the consortium is the customer and every ISP who joins the consortium gets multihoming reliability outside the region. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael at memra.com From gherbert at crl.com Tue Jan 30 20:28:28 1996 From: gherbert at crl.com (George Herbert) Date: Tue, 30 Jan 1996 11:28:28 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Tue, 30 Jan 1996 14:11:07 EST." Message-ID: <199601301928.AA00431@mail.crl.com> I still do not see why you insist this is providing free transit. If you're a backbone and connected into the area, within your network you advertise the /8 outside the area and the details within the area. If you're a backbone and not connected into the area, people can advertise the /8 to you and provide transit, or not, per existing peering and transit agreements. If you're a small provider within the area, you can talk to everyone else in the area and to the customers of backbones which come into the area. If you're a small provider outside the area, you probably buy transit to the area from your backbone along with transit to everywhere else. Everyone would probably want to special-case the block in router filters to make sure that they weren't being unintentionally used for transit by people who aren't supposed to use that route, but the upside is that those faraway routers carry one instead of hundreds or however many routes. -george From asp at uunet.uu.net Tue Jan 30 20:41:21 1996 From: asp at uunet.uu.net (Andrew Partan) Date: Tue, 30 Jan 1996 14:41:21 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Michael Dillon" at Jan 30, 96 11:36:59 am Message-ID: > The proper solution is for all these companies to form a consortium. The > consortium would run the NAP and contract with multiple NSP's for > service. In that case, the NSP's are not providing transit to > non-customers because the consortium is the customer and every ISP who > joins the consortium gets multihoming reliability outside the region. Ah - we may have something that works - we have someone (the consortium) being paid (by these companies) to provide (or further purchase) transit. However I'm not sure how this works of one (or more) of these companies decides to buy or provide transit on their own (outside of the consortium). Lets pick a company (call it X) that decides to do this. Now X's routes have to be known outside of the consortium's aggregate (since X is providing its own global transit and since X does not want to give free transit to the entire aggregate). Humm - this does not seem to scale. I suppose that if you find a set of companies that are all willing to be part of the consortium & just part of the consortium, then you could do addressing for this consortium as a whole. Hey! I think that we just invented provider (consortium) based addressing again. --asp at uunet.uu.net (Andrew Partan) From asp at uunet.uu.net Tue Jan 30 20:54:57 1996 From: asp at uunet.uu.net (Andrew Partan) Date: Tue, 30 Jan 1996 14:54:57 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601301928.AA00431@mail.crl.com> from "George Herbert" at Jan 30, 96 11:28:28 am Message-ID: > If you're a backbone and connected into the area, within your network > you advertise the /8 outside the area and the details within the area. This is the free transit case. Provider X is connected into the area, so provider X has all of the more specific routes for that area. Provider X is also connected outside of the area, so provider X has 3 choices. 1) Provider X can announce the aggregate outside of the area & thus give free transit to the whole area; or 2) Provider X can announce just provider X's customers outside of the area, thus defeating the gain from aggregation; or 3) Provider X can be paid by everyone else in the area to provide transit to the entire area to where ever else Provider X connects to. So either you can't aggregate (case 2) or you get paid by more customers (case 3) or you end up with free transit (case 1). Now lets look at the situation where there are many of these areas and you have some provider connected to more than one of them (as most big providers will be). For every area that provider Y is connected to, provider Y has to carry full routes for the entire area - no aggregation. Humm - I think that we just lost again. --asp at uunet.uu.net (Andrew Partan) From yakov at cisco.com Tue Jan 30 21:08:05 1996 From: yakov at cisco.com (Yakov Rekhter) Date: Tue, 30 Jan 96 12:08:05 PST Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Tue, 30 Jan 96 11:36:59 PST." Message-ID: <199601302008.MAA18979@hubbub.cisco.com> Michael, > > So these providers are providing the free transit to their > > non-customers? > > > > This does not make any business sense; it will not happen. > > The proper solution is for all these companies to form a consortium. The > consortium would run the NAP and contract with multiple NSP's for > service. In that case, the NSP's are not providing transit to > non-customers because the consortium is the customer and every ISP who > joins the consortium gets multihoming reliability outside the region. Forming a consortium is certainly an alternative for ISPs that aren't big enough, so that they don't provide a degree of addressing information aggregation sufficient to justify their routes to float throughout the "default-free" zone of the Internet. The consortium would acquire a (faily large) block of addresses, which would be partitioned among the members of the consortium. The consortium could run its own "backbone" (e.g., NAP) that would provide all members of the consortium with connectivity to other parts of the Internet. The basic connectivity (what I would call "route push") would be provided via this "backbone". The "backbone" would also perform address information aggregation into a single prefix. Additional connectivity can be acquired by the individual members of the consortium via "route pull", but this connectivity would be just to get better routers. This way a small ISP would have a choice of joining a consortium (and there may be a choice of consortiums to join) and get its addresses out of the consortium's block, or to connect to a large NSP and get its addresses out of the large NSP. However, one needs to understand the consortium model has its own issues ... Yakov. From michael at memra.com Tue Jan 30 21:29:21 1996 From: michael at memra.com (Michael Dillon) Date: Tue, 30 Jan 1996 12:29:21 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: Message-ID: On Tue, 30 Jan 1996, Andrew Partan wrote: > I suppose that if you find a set of companies that are all willing to > be part of the consortium & just part of the consortium, then you could > do addressing for this consortium as a whole. Hey! I think that we > just invented provider (consortium) based addressing again. Depends on your definition of provider. I'm just saying that there appears to be room for another tier of provider in between the local ISP's and the national/global NSP's. NAP's and exchange points are popping up all over the place these days; it is only a small extension of the exchange point concept to a business that provides city-wide backbones (or meshes). It won't work everywhere, but it will work in some places and it will help control the growth of routes and that is good. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael at memra.com From yakov at cisco.com Tue Jan 30 21:42:24 1996 From: yakov at cisco.com (Yakov Rekhter) Date: Tue, 30 Jan 96 12:42:24 PST Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Tue, 30 Jan 96 14:41:21 EST." Message-ID: <199601302042.MAA22513@hubbub.cisco.com> Andrew, > Ah - we may have something that works - we have someone (the > consortium) being paid (by these companies) to provide (or further > purchase) transit. > > However I'm not sure how this works of one (or more) of these companies > decides to buy or provide transit on their own (outside of the > consortium). > > Lets pick a company (call it X) that decides to do this. Now X's > routes have to be known outside of the consortium's aggregate (since X > is providing its own global transit and since X does not want to give > free transit to the entire aggregate). > > Humm - this does not seem to scale. Members should be able to get additional connectivity, beyond what will be provided by the consortium, but this connecitivy would be provided via "route pull", and thus could have limited propagation scope. This connectivity would be just to get better routes. Global connectivity would be provided by "pushing" the route that covers all the destinations within the consortium. > I suppose that if you find a set of companies that are all willing to > be part of the consortium & just part of the consortium, then you could > do addressing for this consortium as a whole. Hey! I think that we > just invented provider (consortium) based addressing again. Yep, one should realise that a NAP is nothing but a provider. The NAP run by a consortium is nothing but a provider that is operated by the consortium. With consortiums a little ISP could have a choice - pick a consortium and get its addresses out of consortium's block, or pick a "big provider's" and get its addresses out of the provider's block. Observe though, that changing contractual relations (with the consortium or the provider) would require renumbering of all the ISP's clients. Among some issues to consider are: (a) how competition among the members of the consortium would impact the cooperation needed to preserve the consortium (b) would an "inter-consortium" carrier be allowed to join the consortium(s) it serves and compete against other (local) ISPs Yakov. From curtis at ans.net Tue Jan 30 22:40:47 1996 From: curtis at ans.net (Curtis Villamizar) Date: Tue, 30 Jan 1996 16:40:47 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Mon, 29 Jan 1996 13:37:33 EST." <9601291837.AA01730@ginger.lcs.mit.edu> Message-ID: <199601302140.QAA03195@brookfield.ans.net> In message <9601291837.AA01730 at ginger.lcs.mit.edu>, Noel Chiappa writes: > > We can also limit the amount of routing overhead by providing configured > AAB boundaries for a given multihomed site which enclose a path between the > primary and secondary providers. Since this will in some cases require > cooperation among multiple providers, as well as either i) massive amounts of > manual mechanical configuration bookkeeping, or ii) automated tools we don't > have yet, don't hold you breath for that one either. > > Noel Noel, You may not have to wait as long as you think. The slides below were presented at the most recent RPS WG meeting: ftp://ftp.ans.net/pub/papers/slides/rps/aggregation.ps ftp://ftp.ans.net/pub/papers/slides/rps/aggr-methods.ps The idea is to provide a means to specify the aggregation boundary within the IRR and provide the tools to transform that specification into router configurations. I'm not sure the slides are entirely self explanitory, but I think they convey the general idea. This work is progressing. Gradually, but it is progressing. ANS should have working code to do this deployed by next IETF. This code will enable ANS to do much better aggregation that we now do regardless as to whether other providers buy into the idea. To accomplish the type of multiprovider cooperation you refer to above, it is a matter of getting someone else doing the same thing, or something similar enough that we have someone to cooperate with. Curtis From bmanning at ISI.EDU Tue Jan 30 23:21:21 1996 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 30 Jan 1996 14:21:21 -0800 (PST) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Christian Huitema" at Jan 29, 96 10:40:34 am Message-ID: <199601302221.AA16974@zed.isi.edu> > There is at least one very simple response. Set up some deviant CIX, say > IX195-8, let everyone with a shortish 195/8 prefix connect to it either > directly through their own provider, or indirectly through some tunnel, and > have IX195-8 announce reachability of 195/8. That is, in short, altern > topology to meet addresses when the converse is too hard. KRE detailed > that for the general case, but it would be even simpler in the case of > RIPE, since all the allocated network numbers are in the same geographical > area. > > Christian Huitema This was proposed and received mild interest about 9 months back. I was able to persuade some people that this was a variant of what was called "provider-based" addressing. It has the interesting trait of also being "geographic-based" as well, for those that can still relate to the old labels. Not enough to take the effort to make it work. I'd be willing to exert some, for any of the existing or planned exchanges, if people thought this would be a viable alternative. --bill From G.Huston at aarnet.edu.au Wed Jan 31 00:41:25 1996 From: G.Huston at aarnet.edu.au (Geoff Huston) Date: Wed, 31 Jan 1996 10:41:25 +1100 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Andrew Partan" at Jan 30, 96 02:11:07 pm Message-ID: <199601302341.KAA22066@nico.aarnet.edu.au> (I'm reluctant to add to the noise, but what the hell - everyone else is partying :-) ) The space we are playing in is both a technical and an economic one, and the conversation stream to date veers widely around the technical issues and is completely off the planet economically speaking! Andrew half hit the issue with the comment relating to ISPs undertaking what is a variant of proxy aggregation to suppress routing table size when he noted that this is tantamount to "free transit". However this way he then inferred that free transit is impossible to sustain as the fatal flaw in this model, should be broken down further before dismissing it as completely flawed: a) forced proxy aggregation implies transit peering across ISPs Technically this (transit) is of course possible to construct. b) it will be economically infeasible IF we continue with this strange system of zero dollar interconnections we use as a peering model. i.e "free" is the problem here, not "transit". If you manage to provide a better model for interconnection which includes a rational economic model of interaction then, strangely enough, you then have a powerful tool you can use to address teh technical issue of scaling the routing domain. i.e. "free transit" is stupid, as Andrew indicates. "transit" is possible given a rational economic model of the transit interaction. In the same way that giving away IP addresses and giving away IP routing can only be described as a very bad case of irrational behaviour, especially when the underlying resource is under stress as it is at present, then I'd also note that giving away transit is similarly a case completely irrational behaviour! All this points to a desperate need for a more realistic economic structure to be used within a number of key aspects of Internet infrastructure. Thanks, Geoff Huston Andrew's comments: > > > Half correct. Everyone in the area carries full routes for the block. > > Everyone outside the area can listen to only the /8 advertisement. > > So these providers are providing the free transit to their > non-customers? > > This does not make any business sense; it will not happen. > --asp at uunet.uu.net (Andrew Partan) > > From iljitsch at daisy.bART.nl Wed Jan 31 01:32:44 1996 From: iljitsch at daisy.bART.nl (Iljitsch van Beijnum) Date: Wed, 31 Jan 96 01:32:44 Subject: Policy Statement on Address Space Allocations In-Reply-To: <199601301049.KAA02133@diamond.xara.net> (from "Alex.Bligh" ) (at Tue, 30 Jan 1996 10:48:59 +0000) Message-ID: <220287b7.6654a-iljitsch@daisy.bART.nl> People on this list of lists seem to be focussing on squeezing more aggregation out of assignment and routing policy's. But that won't work. The Internet isn't organized in a geographical way nor in a very hierarchical way. There are less than 2000 Autonomous Systems, but more than 30000 routes. That means an average of 15 routes per AS. That's the real problem. And we know how to fix it too: renumber. But whatever happens, the routingtable will continue to grow. Get used to it. At present I can still run full routing with only a Cisco 2514 so the problem is hardly as big as some people (Sprint...) like to tell themselves and the rest of us. We pay those backbone people big money, so either they do their job and quit complaining about their overloaded CPU's, tight memory and other stuff or they find themselves another line of work. I'm getting sick and tired of reading how everybody will bend over backwards to find a way to live with an utterly ridiculous policy of some dinosaur company with a flawed network because they pay their lawyers more than their engineers. Maybe they could get away with that in the good old phonebusiness, but not on the Internet. Iljitsch From hal9001 at panix.com Wed Jan 31 09:17:50 1996 From: hal9001 at panix.com (Robert A. Rosenberg) Date: Wed, 31 Jan 1996 03:17:50 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: At 11:39 1/30/96, Iljitsch van Beijnum wrote: >> At 6:09 1/29/96, Alex.Bligh wrote: > >> > Currently I have 2 choices as >> >far as I can make out, give them a bit of my /19, break up my >> >nice aggregate and ensure loads of extra announcements (and that >> >probably none of them get routed by anyone applying prefix based >> >filtering), or give them a new /19 all of their own (you've > >Suppose you have a customer that needs a /22 and they want to go >multi-homed. Suppose you give them that /22 out of your /19 or /16 you >got from the RIPE NCC. So they announce their /22 to you and to their >other provider. But you keep announcing your /19 or /16. So if anybody >were to filter the /22 announcement, your customer only suffers partial >loss of connectivity, since you are still announcing an aggregate of >their announcemnt (your original /19 or /16). > >Problem fixed. Anything else? ;-) Unless you announce both the /16 (or 19) AND the /22, they are not multi-homed but only single routed (with some fallback for those who see the /22 announcement). Anyone who gets the unfiltered /22 announcement will used the other provider (so long as that provider is up) while you get used only by those who get a filter routing (and as fallback when the other provider goes down). From hal9001 at panix.com Wed Jan 31 09:19:00 1996 From: hal9001 at panix.com (Robert A. Rosenberg) Date: Wed, 31 Jan 1996 03:19:00 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: At 5:48 1/30/96, Alex.Bligh wrote: >Thankyou for the first constructive workable suggestion had so far. However, >this has two problems. You're welcome. > >a) RIPE fidn't give me the first /19 in a shorted prefix block > ( its x.x.160.x and .192.x is used), but no matter, I'll renumber > if necessary :-( or persuade them to give me a /18 as well so I > can do the above (hopefully). My convert the /19 to an /18 was a way to get minimal extra announcements. Getting a new /19 and keeping the first 3 /21s for your own use and giving them the 4th, still adds only one EXTRA announcement (over the need to announce the [new] /19 itself). >b) The /21 advert may be inbound filtered by a.n.other, which will be > fine if it has an AS-Path through me (as the less specific route > will work the same way) but won't when that path goes through the > other provider with whom they are multi-homed, as the /21 will disappear > entirely (3rd parties, i.e. a.n.other's customers will see neither), > the /19 will be the only thing that is visible, and I'll just black > hole their packets. As a Multi-Home (as opposed to a Private) /21 it should (theoretically) be entitled to being added to the filter lists as valid - Getting this done is a political problem. You should not be black holing the packets since your receipt of them is VALID (since they are Multi-Homed as opposed to having walked with the block). From peter at demon.net Wed Jan 31 10:11:04 1996 From: peter at demon.net (Peter Galbavy) Date: Wed, 31 Jan 1996 09:11:04 +0000 (GMT) Subject: Policy Statement on Address Space Allocations In-Reply-To: from "Michael Dillon" at Jan 29, 96 02:48:17 pm Message-ID: <9601310911.aa13182@office.demon.net> > You are the biggest ISP in Europe aren't you? How big? Couldn't you spend > a few quid on incorporating Demon Internet Services Inc. in the USA? > Wouldn't you then be eligible for IP addresses from the US Internic? This has been consdidered I understand... but we want to play the game and make the rules better, not cheat :-) > In a classless IPV4 world in which the old Class A address area is in > production use, would we have enough available IP addresses for providers > to do this on a large scale assuming that they would have near 100% > utilization in the blocks that were being allocated statically? > > Didn't the experiment with 39/8 show that it was safe to allocate > classlessly out of the old Class A addresses? I think so and yes :-) Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From huitema at pax.inria.fr Wed Jan 31 18:48:26 1996 From: huitema at pax.inria.fr (Christian Huitema) Date: Wed, 31 Jan 1996 18:48:26 +0100 Subject: Policy Statement on Address Space Allocations Message-ID: At 2:41 PM 30/1/96, Andrew Partan wrote: >> The proper solution is for all these companies to form a consortium. The >> consortium would run the NAP and contract with multiple NSP's for >> service. In that case, the NSP's are not providing transit to >> non-customers because the consortium is the customer and every ISP who >> joins the consortium gets multihoming reliability outside the region. > >Ah - we may have something that works - we have someone (the >consortium) being paid (by these companies) to provide (or further >purchase) transit. My initial message may have been terse, but I was certainly not expecting the "deviant CIX" or "specialized NAP" or "Agregating CIDR Internet Detour" (ACID, (tm)) to provide world wide reachability for free. In fact, it is providing a service at a cost. The service is to provide reachability to smallish 192/27 single home or multihomed networks. It does so by aggregating several such networks into a larger, CIDR routable, 192/8 (or /10, or /15). The cost is indeed that the transit traffic goes through the ACID, consume bandwidth and other resources, and that these resources have to be payed for. In short, networks owners pay for not having to renumber; how much they are ready to pay depends on how expensive their renumbering will be. Paying can be done in many way, from the "consortium" which you suggest to some fees to a service company that operates the ACID. In fact, the major roadblock here is the intrisic monopoly -- at first sight, there can only be one ACID for a given aggregate. This may trigger all sorts of regulatory questions. Sharing of resource between consortium members or service customers may be done either the usual way (i.e. FIFO and random luck) or in a more organized way, e.g. using class based queuing. Christian Huitema From yakov at cisco.com Wed Jan 31 19:13:11 1996 From: yakov at cisco.com (Yakov Rekhter) Date: Wed, 31 Jan 96 10:13:11 PST Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Wed, 31 Jan 96 18:48:26 +0100." Message-ID: <199601311813.KAA17564@hubbub.cisco.com> Christian, > Paying can be done in many way, from the "consortium" which you suggest to > some fees to a service company that operates the ACID. In fact, the major > roadblock here is the intrisic monopoly -- at first sight, there can only > be one ACID for a given aggregate. This may trigger all sorts of > regulatory questions. It had been pointed out several times before that hierarchical routing has an *inherently* monopolistic aspect - it ties an organization whose addresses have to be aggregated with the organization that aggregates these addresses (aggregator). Yakov. From curtis at ans.net Wed Jan 31 19:38:43 1996 From: curtis at ans.net (Curtis Villamizar) Date: Wed, 31 Jan 1996 13:38:43 -0500 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Tue, 30 Jan 1996 14:00:38 EST." <9601301900.AA16710@maze.MIT.EDU> Message-ID: <199601311838.NAA05128@brookfield.ans.net> In message <9601301900.AA16710 at maze.MIT.EDU>, marthag at MIT.EDU writes: > > > > Here's my suggestion. > > > > If you put that multi-homed customer in a larger aggregate (have them > > pick one of the providers and allocate from their address space) all > > of the providers must then announce the more specific. Some providers > > will block the longer prefix. The longer prefix will be preferred and > > traffic will avoid going through those providers that block it. This > > might cause longer or suboptimal routing for the longer prefix. > > Providers everywhere will have either the shorter prefix or both, so > > full connectivity would exist. > > > > If the multi-homing is sufficiently localized within the topology (for > > example, multiple providers in the same region or country) there might > > be a chance to draw an aggregation boundary around the whole thing and > > block the longer prefix outside of that locality and avoid the > > possibility of suboptimal routing due to long prefix filtering. > > > > Curtis > > > > Except that if the shorter prefixed route goes down, half the world will > not be able to see any route to site, which sort of defeats the purpose > of being multi-homed. > > Martha Greenberg > marthag at mit.edu True. What this protects against is losing the tail circuit to either provider. If the primary provider is single homed to the rest of the world or is otherwise unreliable and their entire aggregate disappears from global routing, then you lose connectivity to providers blocking long prefixes. I think that is the best you can do as long as some providers plan to block your long prefix. Pick a very stable aggregate to cover your long prefix. Curtis From gherbert at crl.com Wed Jan 31 19:45:11 1996 From: gherbert at crl.com (George Herbert) Date: Wed, 31 Jan 1996 10:45:11 -0800 Subject: Policy Statement on Address Space Allocations In-Reply-To: Your message of "Wed, 31 Jan 1996 10:13:11 PST." <199601311813.KAA17564@hubbub.cisco.com> Message-ID: <199601311845.AA15340@mail.crl.com> >It had been pointed out several times before that hierarchical routing >has an *inherently* monopolistic aspect - it ties an organization >whose addresses have to be aggregated with the organization that >aggregates these addresses (aggregator). Having an open consortium / association managing large aggregated spaces therefore is somewhat beneficial, in that it isn't competing with its members at any level. -george From jnc at ginger.lcs.mit.edu Wed Jan 31 21:00:33 1996 From: jnc at ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 31 Jan 96 15:00:33 -0500 Subject: Policy Statement on Address Space Allocations Message-ID: <9601312000.AA13981@ginger.lcs.mit.edu> From: Geoff Huston it will be economically infeasible IF we continue with this strange system of zero dollar interconnections we use as a peering model. ... In the same way that giving away IP addresses and giving away IP routing can only be described as a very bad case of irrational behaviour, especially when the underlying resource is under stress ... then I'd also note that giving away transit is similarly a case completely irrational behaviour! All this points to a desperate need for a more realistic economic structure to be used within a number of key aspects of Internet infrastructure. Geoff, while I sort of agree with you, please note that the current "free" models in all these areas do have one real advantage, which is that they are simple. Perhaps we will need "more realistic economic structure[s]", but I can more or less guarantee you that those will be more complex as well. Also, that complexity has a cost, which also has to be figured in. (The classic example is long-distance telephone service, where the cost of creting the bill is said to be far larger than the cost of the underlying service.) Finally, given past history, I suspect that the 'Net community, and particularly the 'Net technical community, is going to have a painful transition, on the emotional level and others, to this brave new world of more commercial structures, and the inevitable technical impacts that causes. That has certainly been the case in every such step in the past... Noel From jon at branch.com Wed Jan 31 21:56:55 1996 From: jon at branch.com (Jon Zeeff) Date: Wed, 31 Jan 1996 15:56:55 -0500 (EST) Subject: Policy Statement on Address Space Allocations In-Reply-To: <9601312000.AA13981@ginger.lcs.mit.edu> from "Noel Chiappa" at Jan 31, 96 03:00:33 pm Message-ID: All this discussion seems to be about work arounds for the real problem. Namely, that the current hardware/software/protocols can't handle what is actually a small number of routes. Restricting announcements of new routes should be one of the last things considered. Here is one - for whatever reasons, we have a provider who can't seem to correctly announce an aggregate and instead, announces several specifics. Nobody says anything about this inefficiency - not to us or to them. Some automated process watching for things like this and sending an advisory email might help quite a bit. -- (313) 741-4442 http://branch.com/ Jon Zeeff Branch Internet Services Inc. jon at branch.com *** WWW Hosting Services, WWW Site Development and the Branch Malls *** From smd at cesium.clock.org Wed Jan 31 23:13:06 1996 From: smd at cesium.clock.org (Sean Doran) Date: Wed, 31 Jan 1996 14:13:06 -0800 Subject: Policy Statement on Address Space Allocations Message-ID: <96Jan31.141316pst.5776@cesium.clock.org> | 1) Provider X can announce the aggregate outside of the area & thus | give free transit to the whole area; or | | 2) Provider X can announce just provider X's customers outside of the | area, thus defeating the gain from aggregation; or | | 3) Provider X can be paid by everyone else in the area to provide | transit to the entire area to where ever else Provider X connects to. Just to be vicious, I think I should mention option #4: Provider X can announce the aggregate outside of the area and drop packets bound for people in the area who do not pay Provider X for transiting packets to them. I think you will find that if a system were set up such that there were many touchdowns of this nature (announcing a single prefix), people would be screaming that they were at the mercies of the decisions about to whom in each local aggregate each long-distance carrier would be willing to deliver traffic. One could also view this as a way to push the problems of CIDRization out to the edges -- it would then be the end sites which would have to learn and be able to route towards the exceptions in the local aggregates, rather than the long-haul carriers. Sean.