- lir-wg - mailman.ripe.net

Re: Creation of Reverse Delegation Objects
by Wilfried Woeber, UniVie/ACOnet 25 Apr '02

25 Apr '02

Hi Joao! >Date: Wed, 24 Apr 2002 19:44:23 +0200 (CEST) >From: Joao Luis Silva Damas <joao(a)ripe.net> >To: "Wilfried Woeber, UniVie/ACOnet" <woeber(a)cc.univie.ac.at> >CC: lir-wg(a)ripe.net >Subject: Re: Creation of Reverse Delegation Objects > >Dear Wilfried, thanks for the very useful explanations! It turns out that we were discussing a non-issue - mostly. Sorry for getting started again, yesterday, it was the style of the 1st answer... >I wholeheartedly agree with your arguments: > >There *IS* indeed a mandate on the RIPE NCC to provide services to the >community at large. > > [ snip ] > > ... Those are usually either LIRs or have their >address space registered at the ARIN Database (and yes this becomes an >issue to discuss in view of the pending transfer of "legacy" space from >ARIN to the RIPE NCC). Where do you propose to discuss those things? LIR / DB / somewhere else? For scheduling reasons, I do have a preference for DB, but it's your decision. >I hope to have filled you in with this message Indeed, thanks again. >Regards, >joao Cheers, Wilfried.

1 0

Re: Creation of Reverse Delegation Objects
by James Aldridge 24 Apr '02

24 Apr '02

Gert Doering wrote: > Hi, > > On Wed, Apr 24, 2002 at 02:51:02PM -0400, Tanya Hinman wrote: > > I agree completely with Tanja. PI space should not be assigned to End-Users > > if they cannot be responsible for it, including the reverse delegation. > > I feel tempted to shorten that sentence further to > > "PI space should not be assigned to End-Users" > > but I am afraid this isn't too workable. How about simply "PI space should not be assigned." (if not to an end-user, then to whom?) ;-) However, you request PI space from a LIR. Why not request in-addr.arpa delegation from this same LIR at the same time? Once the delegation is in place you are free to change provider as much as you like but there is no reason to change the DNS setup (after all, you've got yourself PI address space and your master nameserver's in that space, isn't it?) James

1 0

Re: Creation of Reverse Delegation Objects
by Wilfried Woeber, UniVie/ACOnet 24 Apr '02

24 Apr '02

Hi Dominic, >Date: Wed, 24 Apr 2002 17:00:28 +0200 >To: Tanja Heimes <theimes(a)de.cw.net> >From: Dominic Spratley <dominic(a)ripe.net> >Subject: Re: Creation of Reverse Delegation Objects >CC: lir-wg(a)ripe.net > >Hi Tanja, > >There are several reasons why we do not accept requests directly >from end-users. Most are based on the fact that the Internet >Registry system is hierarchical. This means that we are funded by >LIRs to provide services to them, not to end-users. From _quite_ a distance, I tend to agree, in principle, but. Looking at the details, you are (from my point of view) over-simplifying the situation. E.g. there are probably quite a few holders of "traditional" address space which have a considerably higher clue-level that some LIRs. And, there _IS_ (or is this was?) a mandate for the NCC to provide services or functions for the community at large (just have a look at the annual activity descriptions which get agreed in the RIPE Community and ultimately get approved by the members once a year). Not all of these activities have to be channeled through (the wait queue for) a particular LIR. But my biggest point of concern here is that this is another instance where pretty *fundamental* operational (and policy) changes get implemented unilaterally by the NCC (should I say hostmaster group here?), without discussion, approval, and a look at the consequences and *NOT EVEN* an information being distributed those *AFFECTED*: the LIR community. We are left to find out by chance. > >LIRs have more expertise in dealing with the RIPE Database than >End Users. This is the main reason for requiring requests to come >from them. > >Yours sincerely, > > >Dominic Spratley, > >R.S. Assistant Manager, >RIPE NCC In my books this is very bad management style! Respectfully, Wilfried Woeber, (at.aconet) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

6 6

RE: IPv6 assignments to DNS root servers in the RIPE region
by Guy Davies 24 Apr '02

24 Apr '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Gert, I think what Joao was suggesting was that if the nameserver had been in NASA's v6 block, then rapid renumbering would have made it viable to demand the whole block back from NASA when the nameserver was shutdown. While this is nice in theory, I tend to agree with Randy that it is not very likely in reality for a huge organisation like NASA. Regards, Guy > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Wednesday, April 24, 2002 1:56 PM > To: Randy Bush > Cc: Joao Luis Silva Damas; lir-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: IPv6 assignments to DNS root servers in the RIPE > region > > > hi, > > On Wed, Apr 24, 2002 at 08:50:05AM -0400, Randy Bush wrote: > > > No, NASA should probably not return their IPv4 space. > With IPv6 you > > > can do it right, so why not do it right? > > > > oh, i forgot ipv6's rapid renumbering. i also forgot santa > claus and > > the tooth fairy. > > Huh? What does this have to do with anything? > > This proposal is about NOT changing IPv6 root name server > addresses, and > NOT about "easy renumbering". > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 44543 > > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPMauCY3dwu/Ss2PCEQLfkwCg7upE2tAaEQ2GoHjIlRwwIEkLez8AoMjD X24zM7WSw2QARZm0DFdvnnCx =WbDK -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

5 4

RE: IPv6 assignments to DNS root servers in the RIPE region
by Guy Davies 24 Apr '02

24 Apr '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > In message > <C653AC166708D51195D600034723D865075BBB(a)cain.telindus.co.uk>, Guy > Da vies writes: > > >Hi Gert, > > > >I think what Joao was suggesting was that if the nameserver had > >been in NASA's v6 block, then rapid renumbering would have made it > >viable to demand the whole block back from NASA when the > >nameserver was shutdown. While this is nice in theory, I tend to > >agree with Randy that it is not very likely in reality for a huge > >organisation like NASA. > > As I read it, it means that the root-server will get its own > allocation, and that allocation follows the rootserver around. That's the original discussion point. However, there's a little throwaway comment in one of Joao's subsequent emails in which he says... "No, NASA should probably not return their IPv4 space. With IPv6 you can do it right, so why not do it right?". To me, that implies that you can force an organisation like NASA to return *all* their v6 space and renumber in this kind of situation. > Sounds surprisingly reasonable to me. For the initial discussion point, yes. For the subsequent point, above, absolutely not. Guy -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPMavqo3dwu/Ss2PCEQJL/wCfRGx6hetMOJqPCh/+d/thPLA9dssAn0y3 1KYq6bIEy0YhVED7SbjmdxTV =0hrB -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

1 0

RE: IPv6 assignments to DNS root servers in the RIPE region
by matthew.ford＠bt.com 24 Apr '02

24 Apr '02

I couldn't agree more. The only conceivable objection to the proposal is that it potentially sets a precedent that will be used to trash the IPv6 routing heirarchy. Given carefully worded policy, that precedent need not be set. Mat. > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: 24 April 2002 13:55 > To: Randy Bush > Cc: Joao Luis Silva Damas; lir-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: IPv6 assignments to DNS root servers in the RIPE region > > > Hi, > > On Wed, Apr 24, 2002 at 08:44:44AM -0400, Randy Bush wrote: > > > Seriously now. I strongly believe that if a root server > were to stop > > > operations, it would be in everyone's benefit that either > the address > > > space where it is hosted moves with it OR **the address > space which > > > it was using is returned** > > > > nope. should nasa return 128.8 just because the server is > moved from > > 128.8.10.90? i don't think so. but, if it is moved, they > should not > > put anything else at 128.8.10.90 for a decade or two. > > Which makes you agree with Joao, doesn't it? The way it was done with > 128.8 obviously created problems, which would mean that > "special networks > for root name servers" might be a good thing after all... > > Lacking experience with root name server operations, I didn't comment > the whole proposal yet, and I'm still not sure what is "the > right thing > to do". > > Let's turn it around - which of both approaches would be "the > wrong thing > to do", and why? > > Having special-case networks for every other purpose is clearly a bad > thing, but I think most would agree that root name server > *are* special > because that's the only thing you cannot (completely) put into DNS... > > With the number of root name servers, I don't see any major issues due > to address wastage or enormous numbers of additional routes. > > Just my $0.2... > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 44543 > > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 >

1 0

network transfer
by Marcus.Ruchti＠colt.de 19 Apr '02

19 Apr '02

Hello, the german Internet and DSL provider RIODATA has requested insolvency 3 weeks ago. We (COLT Telecom) plan to take over a huge part of their customers. Some customers have already switched their connection to us. My question is now, whether it is possible (administratively and policy-based) to take over a part of RIODATA's IP addresses. RIODATA is owner of the 62.16.128.0/17 network. If it is possible, what have we and RIODATA to do now ? Thanks for your answer and kind regards, Marcus Ruchti Internet Systems Engineer mailto:marcus.ruchti@colt.de COLT TELECOM GmbH Fon: +49 (0) 69 / 5 66 06 - 6351 Fax: +49 (0) 69 / 5 66 06 - 6350

2 2

New Draft IPv4 Policy Documents
by Mirjam Kuehne 18 Apr '02

18 Apr '02

Dear LIRs, We are pleased to announce the availability of the new draft "IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region" document. Previous drafts of this document have been sent to the public mailing list ripe-185bis(a)ripe.net and reviewed by an editorial team. During this time we received many useful and constructive comments and would like to thank those that were active in providing feedback. The current RIPE document "European Internet Registry Policies and Procedures" (ripe-185) contains all topics and aspects related to addressing policy including procedures and background information. During the review process it was decided that this document would be split into several concise documents. These documents would also make it easier for LIRs to refer to various parts of IPv4 policy. Additional goals of the review process were to clarify and separate policies from procedures, motivate policies and procedures, include policy amendments since the publication of ripe-185, and generally update the policy document. No policies described in the ripe-185 document were changed other than the amendments discussed and agreed by the LIR Working Group. The new set of policy documents consist of the following: - IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region - Autonomous System (AS) Number Assignment Policies and Procedures - Mergers, Acquisitions, Take-overs and Closures of LIRs - New Values of the "status:" Attribute for Inetum Objects (LIR-PARTITIONED) The text version of the draft "IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region" document can be found in the text to follow. The complete set of new draft documentation can be found at: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-docume… The deadline for comments and suggestions is Friday, 3 May 2002. After incorporating any suggested changes to the documents the final documents will be published soon after the RIPE Meeting. All comments and suggestions should be sent to <lir-wg(a)ripe.net>. Regards, Mirjam Kuehne Director External Relations ======= DRAFT: IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region Author(s): Document ID: TBA Date Published: April 2002 Obsoletes: ripe-104, ripe-105, ripe-136, ripe-140, ripe-159, ripe-185 ABSTRACT This document describes the current IPv4 address allocation policies developed by the Local Internet Working Group (LIR WG) of the RIPE community and implemented by the RIPE NCC. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) in the RIPE NCC service region. Table of Contents 1.0 Introduction 1.1 Scope 2.0 Internet Address Space 3.0 Goals of the Internet 4.0 Establishing a New LIR 5.0 IPv4 Address Assignment and Allocation Policies 5.1 General 5.1.1 Validity of an Assignment 5.1.2 Documentation 5.1.3 Registration Requirements 5.1.4 Reservations Not Supported 5.1.5 Administrative Ease 5.1.6 Utilisation 5.1.7 Provider Independent vs. Provider Aggregatable Addresses 5.1.8 Private Address Space 5.2 Assignment Guidelines 5.2.1 Dynamic Assignments 5.2.2 Web Hosting 5.2.3 Renumbering 5.2.4 Assignment Window 5.2.4.1 Assignment Window for End User Assignments 5.2.4.2 Assignment Window for LIR Infrastructure 5.3 Policies and Guidelines for Allocations 5.3.1 First allocation 5.3.2 Slow-start Mechanism 5.3.3 Further Allocations 5.4 Operating an LIR 5.4.1 Record Keeping 5.4.2 Contact persons 5.4.3 Mergers, Take-overs, and Closures of LIRs 5.4.4 LIR Audit 5.4.5 Closure of an LIR by the RIPE NCC 5.4.6 Reverse Delegation 6.0 Appendices I. RIPE Database Procedures II. Assignment Window III. Useful URLs IV. Bit Boundary Chart 1.0 Introduction The RIPE Network Coordination Centre, established as an independent association, serves as one of three existing Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, Central Asia and African countries located north of the equator. As an RIR, the RIPE NCC is responsible for the assignment and allocation of IP address space, Autonomous System (AS) Numbers and the management of reverse domain names. The distribution of IP address space follows the hierarchical scheme described in the draft document "Internet Registry System" found at: http://www.ripe.net/ripencc/mem-services/registration/policies/registry-sys… The RIPE NCC allocates address space to Local Internet Registries that assign address space on to End Users. In this document, the policies associated with the distribution and management of IPv4 address space are described. These policies need to be implemented by all LIRs. The RIPE community, through the open-consensus process used for policy development, has developed the policies described in this document. In RIPE, it is the RIPE LIR Working Group (LIR-WG) where Internet address policy is developed, discussed and set. This process is facilitated and supported by the RIPE NCC. 1.1 Scope This document describes the policies for the responsible management of the globally unique IPv4 Internet address space in the RIPE NCC service region. The policies set forth in this document apply to all IPv4 address space allocated and assigned by the RIPE NCC. This document does not describe address policies related to IPv6, multicast, or private address space. This document does not describe address distribution policies used by other RIRs. Policies regarding AS Numbers are also out of scope for this document. The draft document "Autonomous System (AS) Number Assignment Policies and Procedures" can be found at: http://www.ripe.net/rs/policies/draft-documents/asn-assignments.html 2.0 Internet Address Space IP addresses, for the purposes of this document, are 32-bit binary numbers used as addresses in the IPv4 protocol. There are three main types of IPv4 addresses: Public Addresses Public IP addresses are assigned to be globally unique according to the goals described in Section 3.1. of this document. 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 networks without any registration or co-ordination. Hosts using these addresses cannot be reached directly from the Internet. For a detailed description of private address space and the ranges set aside for this purpose, please refer to RFC 1918 (Address Allocation for Private Internets) at: ftp://ftp.ripe.net/rfc/rfc1918.txt Special and Reserved Addresses There are a number of address ranges reserved for applications such as multicast. These are described in RFC 1112 (Host Extensions for IP Multicasting) and are beyond the scope of this document. RFC 1112 can be found at: http://www.ietf.org/rfc/rfc1112.txt?number=1112 3.0 Goals of the Internet In this document, we are primarily concerned with the management of public Internet address space as applied to IPv4. It should be understood that the focus or importance of these goals might differ for other IP versions, such as IPv6. Public Internet address space assignments should be made with the following goals in mind: Uniqueness Each public Internet address worldwide must be unique. This is an absolute requirement that guarantees that every host on the Internet can be uniquely identified. Aggregation Public Internet addresses must be distributed in an hierarchical manner, permitting the aggregation of routing information. This is necessary to ensure proper operation of Internet routing. This goal could also be called Routability. Conservation Public Internet address space must be fairly distributed, according to the operational needs of the End Users' operating networks using this address space. To maximize the lifetime of the public Internet address space resource, addresses must be distributed according to need, and stockpiling must be prevented. Registration The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels. It is in the interest of the Internet community as a whole that these goals are pursued. It is worth noting that "conservation" and "aggregation" are 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 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 LIRs and End Users in their search for equitable compromises. 4.0 Establishing a New LIR The process of setting up a new LIR is explained in detail in the RIPE document, "Guidelines for Setting up a Local Internet Registry at the RIPE NCC" at: http://www.ripe.net/ripe/docs/new-lir.html 5.0 IPv4 Address Assignment and Allocation Policies 5.1 General The policies in the RIPE NCC service region document are applicable to all globally unique, unicast IPv4 addresses. Specific policies and guidelines for Provider Aggregatable (PA) and Provider Independent (PI) address space are covered later in this section. 5.1.1 Validity of an Assignment Address space assignments of any kind are valid as long as the original criteria on which the assignment was based are still valid. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid. 5.1.2 Documentation Relevant information must be gathered about the network in question in order to determine the amount of addresses required for that network. This information may include organisation details, addressing requirements, network infrastructure, current address space usage, and future plans of the End User requesting address space. This information is essential in making the appropriate assignment decisions, balancing the overall goals of the Internet Registry system (Section 3.0) with the requirements of the network in question, and is needed for every network (the level of detail is dependent on the complexity of the network). The LIR must ensure that the necessary information is complete before proceeding with a request. The RIPE NCC provides a set of forms to be completed for gathering the required information as well as supporting notes for the forms. The set of information requested in the forms provided by the RIPE NCC should be collected by the LIR. LIRs may use these forms for their customers' requests or develop their own local set of forms. Please note that local forms produced by the LIR can be used provided they record all the required data. However, if a request needs to be approved by the RIPE NCC or if information is required in the event of an audit, the information must be submitted on a current version of the "European IP Address Space Request Form" available at: http://www.ripe.net/ripe/docs/iprequestform.html For complete instructions on how to fill out the "European IP Address Request Form", please refer to: http://www.ripe.net/ripe/docs/iprequestsupport.html Please note that all information sent to the RIPE NCC must be submitted in English. 5.1.3 Registration Requirements Each assignment and allocation for public Internet address space must be registered in a publicly accessible Whois Database. Allocations and assignments in the RIPE NCC service region are registered in the RIPE Whois Database. This is necessary to ensure uniqueness and to support network operations. Only allocations and assignments registered in the RIPE Database are considered valid. The required registration of objects in the RIPE Database is the final step in making an assignment. This step validates the assignment and makes information regarding the assignment publicly available and archived. Therefore, care should be taken to ensure that the data registered is correct (e.g. correct IP address range, contact information, etc.). IP addresses used solely for the connection of an End User to an LIR can be considered as part of the service provider's infrastructure. This means that these addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure, i.e. point-to-point links. However, four or more addresses (e.g. /30 or more) used on the End User's network need to be registered separately with the contact details of the End User. For further instructions on how to register objects in the Database, please refer to section I (RIPE Database Procedures) of the Appendix. 5.1.4 Reservations Not Supported In accordance with the goal of address conservation, End Users are not permitted to reserve address space. Evaluation of IP address space requests must be based on a demonstrated need. If possible, unused or inefficiently used address space assigned in the past should be used to meet the current request. Once an organisation has used its assigned address space, it can request additional address space based on an updated estimate of growth in its network. 5.1.5 Administrative Ease The current rate of consumption of the remaining unassigned IPv4 address space does not permit the assignment of addresses for administrative ease. Examples of this include, but are not limited to, ease of billing administration and network management. 5.1.6 Utilisation Immediate utilisation should be at least 25% of the assigned address space and the utilisation rate after one year should be at least 50% of the address assignment unless special circumstances are defined. 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 as this fragments the address space. LIRs cannot make long-term reservations for End Users or their own infrastructure as this violates the goal of conservation and also fragments the address space in case the initial forecasts are not met. 5.1.7 Provider Independent vs. Provider Aggregatable Address Space Provider Aggregatable Address Space (PA) LIRs are allocated Provider Aggregatable address space that they assign to their End Users and announced as one prefix. If an End User changes its service provider, the PA address space assigned by the previous service provider will have to be returned and the network renumbered. Provider Independent Address Space (PI) In contrast to PA address space, PI address space is not aggregatable but can remain assigned to the network as long as the criteria for the original assignment are met. However, PI addresses are expensive to route as no use can be made of aggregation and therefore they might not be globally routable. Please note that the use of PA address space should always be recommended. LIRs must make it clear to the End User which type of address space is assigned. Clear contractual arrangements that specify the validity and duration of the address assignment are strongly recommended for every address assignment. For further information and more detailed recommendations concerning PI and PA addresses, please refer to the RIPE document: "Provider Independent versus Provider Aggregatable Address Space" at: http://www.ripe.net/ripe/docs/pi-pa.html 5.1.8 Private Address Space Using private addresses helps to meet the conservation goal and provides more flexibility for the End User when addressing the network. For this reason End Users should always be informed that private addresses might be a viable option. For a detailed description of private address space and the actual ranges of addresses set aside for that purpose, please refer to RFC 1918 ("Address Allocation for Private Internets") at: http://www.ietf.org/rfc/rfc1918.txt?number=1918 5.2 Assignment Guidelines LIRs assign IP address space from the range of addresses allocated to them by the RIPE NCC. As conservation and aggregation are often conflicting goals, each address request needs to be evaluated carefully in order to assign the amount of address space fulfilling these goals in the best way possible. Implications for both conservation and aggregation have to be evaluated before an assignment is made. For example, if the assignment of the exact number of addresses required creates a large number of prefixes, it might be better to assign one single prefix. In other cases, multiple prefixes might have to be "announced" if the assignment of one single prefix would leave too many addresses unused. Please note that the RIPE NCC must approve requests that are larger than the LIR's Assignment Window. LIRs are always welcome to request advice from the RIPE NCC in making assignment decisions. 5.2.1 Dynamic Assignments The use of static IP address assignments (e.g. one address per customer) for dial-up users is strongly discouraged due to a shortage of IPv4 address space. Organisations considering the use of static IP address assignments are expected to investigate and implement dynamic assignment technologies whenever possible. If static IP address assignments are requested, special verification procedures apply. However, for services that are permanently connected to the Internet, static one-to-one connections are considered acceptable. All assignments to End Users need to be registered in the RIPE Whois Database. However, static assignments of single IP addresses to individual End Users (e.g. dial-up, ADSL, etc.) do not have to be registered separately to the Database. However, special verification methods apply. 5.2.2 Web Hosting With the development of HTTP 1.1, the need for one-to-one mapping of IP addresses to web sites has been eliminated. The RIPE community strongly encourages the deployment of name-based web hosting versus IP-based web hosting in accordance with the goal of conservation. For certain applications the need for IP-based web hosting is recognised and should be described. Special verification methods apply for IP-based web hosting. 5.2.3 Renumbering In general, address space can be replaced on a one-to-one basis. A valid assignment can be replaced with the same amount of addresses if the original assignment criteria are still met and if the address space to be replaced is currently in use. An End User will be required to submit the usual documentation to the LIR only if a large percentage of the original assignment is not in use (50%). This part of the request is then treated as any other request for the assignment of additional addresses. If this exceeds the Assignment Window, see Section 4.2.4 (Assignment Window for End User Assignments), the renumbering request needs to be sent to the RIPE NCC for approval. A period of 3 months is generally accepted, within the RIPE community, to be enough to migrate a network from the old to the new address space. For exceptional cases where the End User requests to keep both assignments for more than three months, an agreement should be obtained from the RIPE NCC for the proposed time frame. 5.2.4 Assignment Window An Assignment Window (AW) refers to the maximum number of addresses that can be assigned by the LIR to either their own network or to an End User's network without prior approval from the RIPE NCC. This is expressed in /nn notation. The Assignment Window procedure was put in place to achieve various levels of support based on the level of experience of the LIR. The RIPE NCC may review LIR assignments made with the LIR's AW in order to assure the LIR is assigning according to policies. This is important to assure the fair distribution of address space and to meet the goals of aggregation, conservation and registration. Documentation regarding assignments made with an AW need to contain equivalent information as in a completed "European IP Address Space Request form". All new LIRs start with an Assignment Window of zero (0). This means that every assignment requires prior approval from the RIPE NCC. The same applies to assignments larger than the LIR's Assignment Window. The AW is applied differently depending whether the assignment is for an End User or for the LIR's infrastructure. 5.2.4.1 Assignment Window for LIR Infrastructure The Assignment Window policy was adjusted in December 2001 to include LIR infrastructure assignments. There is no constraint as to how often the LIR uses its AW for own infrastructure assignments. These assignments may not exceed the LIR's AW. This means that an LIR with a /25 AW can make numerous individual /25 assignments to its own network infrastructure without having to send each request to the RIPE NCC. However, where a single assignment would exceed a /25 the LIR would need to complete the RIPE document "European IP Address Space Request Form" and send it to the RIPE NCC for approval. An LIR must specify which assignments have been made with the AW to the LIR's own infrastructure. Such assignments must have a remarks attribute with the value INFRA-AW in the inetnum object registered in the RIPE database. It is important that a separate remarks attribute is used solely for this purpose. For further explanation of the Assignment Window procedures, please refer to Section II (Assignment Window) of the Appendix. 5.2.4.2 Assignment Window for End User Assignments An LIR can apply their Assignment Window to an End User network only once in any 12 month period. This means that if an LIR makes more than one assignment to an organisation, the total amount of address space assigned with their AW in any 12-month period may not exceed the LIR's AW size. The LIR may only assign additional addresses to the same organisation after approval from the RIPE NCC. 5.3 Policies and Guidelines for Allocations All LIRs that receive address space from the RIPE NCC shall adopt allocation and assignment policies that are consistent with the policies formulated by the RIPE community as described in this document. An LIR cannot have more than one "open" (less than 80% assigned) allocation. The RIPE NCC is the only organisation that allocates address space in its service region. An LIR is not allowed to re-allocate part of its allocation to any other organisation. An LIR can only make assignments. If an LIR is planning to exchange or transfer address space it needs to contact the RIPE NCC so that the changes can be properly registered. The RIPE NCC recognises that LIRs may want to issue parts of their allocation to re-sellers or downstream service providers, as this may be beneficial for aggregation. Please note that the LIR always remains responsible for the entire allocation it receives from the RIPE NCC and that all policies are applied. 5.3.1 First Allocation The minimum allocation size to LIRs is a /20 (4096 addresses), according to the slow-start mechanism described in section 4.3.2 (Slow-start Mechanism). It is expected that this prefix be announced as one aggregate. In order to receive an initial allocation an LIR needs to demonstrate: - either the previous utilisation of a minimum /22 (1024 addresses) - or an immediate need for at least a /22 of address space. This can include address assignments to the LIR's infrastructure as well as assignments to customers' networks that will be renumbered into the LIR's new allocation. Verification of previous utilisation by an organisation is based on the assignments registered in the RIPE Database, as only assignments registered in the RIPE Database are considered valid. Further details can be found in the RIPE document "Guidelines for Setting up a Local Internet Registry at the RIPE NCC" at: http://www.ripe.net/ripe/docs/new-lir.html 5.3.2 Slow-start Mechanism The intent of the slow-start mechanism is to treat all new LIRs equally by allocating address space to LIRs at the rate that the addresses are assigned by the LIRs. The minimum size of the first allocation is /20 (4096 addresses). An allocation larger than a /20 can be made if the need is demonstrated. Additionally, the size of future allocations will be based on the usage rate of the previous allocation. The slow-start mechanism was put into place by the Regional Internet Registries to ensure a consistent and fair policy for all LIRs with respect to allocations. 5.3.3 Further Allocations An LIR is eligible for additional address space allocation when: - at least eighty percent (80%) of the allocated address space is used in valid assignments; - or if a single assignment will require a larger set of addresses that cannot be satisfied with the address space currently held by the LIR; - the appropriate documentation is available for each assignment; - each assignment is registered in the RIPE Whois Database; - 80% of the allocation is utilised before additional address space is requested; - all allocations must be at 80% usage; - overall usage must also be at 80%. Reservations are not counted as assignments. It may be useful for internal aggregation to keep some address space free for a customer for future growth in addition to the actual assignment. However, the LIR must be aware that these internal reservations do not count as assignments and must be assigned before the LIR can request another allocation. The size of further allocations mainly depends on the assignment rate of previous allocations. To obtain a new allocation, an LIR should submit a request to the RIPE NCC using the RIPE document "European IP Allocation Request Form" and include a complete list of the assignments (i.e. IP address range and netname) made from their last allocation. However, all previous allocations made to the LIR also need to show a utilisation rate of at least 80%. Additional address space will be allocated only after the information supplied with the request has been verified and a new allocation has been deemed necessary. The RIPE NCC will do its best to allocate contiguous address space in order to support aggregation. This cannot be guaranteed as it depends on factors outside the RIPE NCC's influence (e.g. the number of new LIRs and the time needed to utilise the allocation). 5.4 Operating an LIR This section outlines procedures associated with IP registration services that LIRs are expected to follow in order to ensure that the policies are applied in a fair and impartial manner throughout the entire RIPE NCC service region. 5.4.1 Record Keeping LIRs must maintain proper records of all address assignments they have made. All documentation related to an IP address request and assignment needs to be maintained by the LIR for future reference. This data is needed for the evaluation of subsequent requests for the same organisation/End User, for audits by the RIR, and for the resolution of any questions that may arise regarding assignments. The records must include: - The original request - All supporting documentation - All related correspondence between the LIR and the customer - The assignment decision, including: - Reasons behind any unusual decision - The person responsible for making the decision The chronology of events and the persons responsible should be stated clearly in the records. In order to facilitate the exchange of information, it is highly recommended that documents are kept electronically and readily accessible. If requested, any of this information should be made available to the RIPE NCC in English. 5.4.2 LIR Contact Persons Each LIR must provide the RIPE NCC with a list of contact persons. The contact persons should be those who submit address space requests for the LIR. This contact information should be kept up-to-date. Address space requests will only be accepted from LIR staff members that are registered as contact persons for an LIR. This is necessary to ensure confidentiality. Every registered contact person can make updates and/or changes to the contact information the RIPE NCC keeps for that LIR. A list of registered contact person's responsibilities and important referencing documents can be found at: http://www/ripe/docs/new-lir.html [This document is currently being revised.] 5.4.3 Mergers, Take-overs, and Closures of LIRs In the event that an LIR changes ownership (e.g. merger, sale, or take-over), the new entity must register any changes to its network operations or contact persons with the RIPE NCC. If the effect of a take-over, sale, or merger results in a change of the LIR as a legal entity, the LIR must provide relevant legal documentation confirming the new organisation to the RIPE NCC. For further information on change of LIR ownership and closures, see the draft document "Mergers, Acquisitions, Takeovers and Closures of LIRs" found at: http://www.ripe.net/rs/policies/draft-documents/mergers.html 5.4.4 LIR Audit The RIPE NCC was asked by the RIPE community to audit LIR operations in order to ensure consistent and fair implementation of address policies set by the community. This includes regular checks of assignment data in the RIPE Whois Database for completeness and consistency. The RIPE NCC may also contact an LIR to ask for documentation or for more information about certain requests or database entries. The RIPE NCC will work with an LIR to correct any problems that are found. If necessary, the RIPE NCC may take corrective action such as lowering the LIR's Assignment Window. This activity is described in detail in the RIPE document "RIPE NCC Consistency and Auditing Activity" at: http://www.ripe.net/ripe/docs/audit.html For further information regarding the RIPE NCC auditing activity, please refer to: http://www.ripe.net/audit 5.4.5 Closure of an LIR by the RIPE NCC The RIPE NCC may decide to close an LIR for the following reasons: - the LIR stops paying its bills to the RIPE NCC - and/or the LIR cannot be contacted by the RIPE NCC for a significant period of time Moreover, if an LIR consistently violates the policies applicable in the RIPE NCC service region, it may result in closure of the LIR. In the event of an LIR closure, the RIPE NCC will take responsibility for all address space held by the LIR. 5.4.6 Reverse Delegation LIRs should maintain in.addr.arpa resource records for their customers' networks. The RIPE NCC only accepts requests for reverse delegation from LIRs. More information about reverse delegation can be found in the draft document "Reverse Delegation Under "in-addr.arpa" in the RIPE NCC Service Region" found at: [To be published] 6.0 Appendices I. RIPE Whois Database Procedures Registration of objects pertaining to an assignment in the RIPE Whois Database enables uniqueness and provides contact information. This is essential for the effective administration and operation of IP networks. Submission of objects to the RIPE Whois Database is the final step in making an assignment. This step validates the assignment and makes the information regarding the assignment publicly available. Therefore, care should be taken to assure the assignment and of all relevant data is correct prior to completing this step. The information collected about the End User's organisation in the Network Template (see http://www.ripe.net/ripe/docs/iprequestsupport.html) is used to construct an inetnum object. The range of addresses assigned to the End User is also entered in the inetnum object and is specified in dotted quad notation. For example, if an organisation is assigned a /22 address set for 1024 network addresses, the range will resemble the following: 193.0.0.0 193.0.1.255 A person object must be submitted for each person specified in the tech-c and admin-c fields of the inetnum object unless up-to-date objects are already available in the RIPE Database in addition to the inetnum object. The person object is referenced from the inetnum by its nic-handle. The information should remain in the RIPE Database for as long as the original assignment is valid. If the address space is returned, the LIR that made the assignment must remove the old entry from the RIPE Database. An assignment is considered valid when based on the following factors: - all assignments must be registered in the RIPE Database - assignments should either be covered by an LIR's AW or should have received prior approval from the RIPE NCC - Database objects describing an assignment approved by the RIPE NCC should: - use the same netname as approved by the RIPE NCC - use the date of approval or a later date in the first changed line of the inetnum object - not exceed the number of IP addresses approved by the RIPE NCC The type of the assigned address space must be registered in the status attribute of the inetnum object. The possible 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. To improve registration of old assignments, LIRs are encouraged to mark legacy assignments in the RIPE Database with PA or PI as appropriate. This should be done in collaboration with the End User to make sure of the status of the address space. Both LIR and End User should understand the implications. Allocation Registration The RIPE NCC registers all address space allocated to an LIR in the RIPE Whois Database using inetnum objects. Inetnum objects describing allocations to LIRs are maintained by the RIPE NCC. Hierarchical authorisation can be used to allow the LIR the creation of inetnum objects more specific than the allocation objects. Organisational information about the LIR is stored together with the address space range and the type of addresses. The range of the addresses is stored in the inetnum field in dotted quad notation. The address 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 LIR or an RIR and all assignments made from it are provider aggregatable. This is the most common allocation type for LIRs. ALLOCATED PI This address space has been allocated to an LIR and all assignments made from it are provider independent. This case is extremely rare and is only done after careful consideration. ALLOCATED UNSPECIFIED This address space has been allocated to an LIR 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 received this allocation type. For information and instructions on the use of the RIPE Database, please refer to the RIPE document: "RIPE Database Reference Manual" at: http://www.ripe.net/ripe/docs/databaseref-manual.html II. Assignment Window The LIR's Assignment Window can either be applied to assignments for their own network infrastructure or for End User assignments. As mentioned in 4.2.6 (Assignment Window for LIR Infrastructure), LIRs must specify in the RIPE database which assignments have been made to the LIR's own infrastructure network using their AW. Only assignments to the LIR's infrastructure may have the INFRA-AW identifier. Assignments to End Users do not need any identifier. The AW is regularly reviewed by the RIPE NCC Hostmasters. LIRs may approach the RIPE NCC for an evaluation of its Assignment Window at any time. Please note that LIRs are always welcome to approach the RIPE NCC for a second opinion on requests even if theyfall within the LIR's Assignment Window. Raising of the Assignment Window As the proficiency of the LIR contacts increases the size of their Assignment Window may be raised. This is determined based on: - correctly completed documentation presented to the RIPE NCC - good judgement shown in the evaluation of address space requests - past assignments have been properly registered. Lowering of the Assignment Window An established LIR is responsible for training new LIR contacts to handle address space assignments according to the policies described in this document and their procedures. Less experienced LIR contacts may make errors both in judgement and procedure. If errors happen repeatedly the Assignment Window of the LIR may be decreased to prevent the LIR from making erroneous assignments. The Assignment Window may again be increased based on the criteria stated above. The Assignment Window may be lowered as a result of an audit where erroneous assignments are noted or to enforce overdue payment. III. Useful URLs RIPE NCC Registration Services information http://www.ripe.net/rs/ RIPE NCC E-mail contacts http://www.ripe.net/ripencc/about/contact.html RIPE NCC Frequently Asked Questions http://www.ripe.net/ripencc/faq/index.html Quick Tips for IP and AS Requests http://www.ripe.net/ripencc/tips/tips.html IPv6 Allocation and Assignment Information http://www.ripe.net/ipv6 Draft: New Values of the "status:" Attribute for Inetum Objects(LIR-Partitioned) http://www.ripe.net/rs/policies/draft-documents/lir-partitioned.html RIPE Documentation store http://www.ripe.net/ripe/docs/index.html IV. Bit Boundary Chart Historically, IP addresses have been assigned in the form of network numbers of class A, B, or C. With the introduction of classless inter-domain routing (CIDR) classful restrictions are no longer valid. Address space is now allocated and assigned on bit boundaries. The following table illustrates this: +-----------------------------------------------+ |addrs bits pref mask | +-----------------------------------------------+ | 1 0 /32 255.255.255.255 | | 2 1 /31 255.255.255.254 | | 4 2 /30 255.255.255.252 | | 8 3 /29 255.255.255.248 | | 16 4 /28 255.255.255.240 | | 32 5 /27 255.255.255.224 | | 64 6 /26 255.255.255.192 | | 128 7 /25 255.255.255.128 | | 256 8 /24 255.255.255 | | 512 9 /23 255.255.254 | | 1K 10 /22 255.255.252 | | 2K 11 /21 255.255.248 | | 4K 12 /20 255.255.240 | | 8K 13 /19 255.255.224 | | 16K 14 /18 255.255.192 | | 32K 15 /17 255.255.128 | | 64K 16 /16 255.255 | | 128K 17 /15 255.254 | | 256K 18 /14 255.252 | | 512K 19 /13 255.248 | | 1M 20 /12 255.240 | | 2M 21 /11 255.224 | | 4M 22 /10 255.192 | | 8M 23 /9 255.128 | | 16M 24 /8 255 | | 32M 25 /7 254 | | 64M 26 /6 252 | | 128M 27 /5 248 | | 256M 28 /4 240 | | 512M 29 /3 224 | |1024M 30 /2 192 | +-----------------------------------------------+ 'bits' The size of the allocation/assignment in bits of address space. 'addrs' The number of addresses available; note that the number of addressable hosts is normally 2 less than this number because the host parts with all equal bits (all 0s, all 1s) are reserved. 'pref' The length of the route prefix covering this address space. This is sometimes used to indicate the size of an allocation/assignment. 'mask' The network mask defining the routing prefix in dotted quad notation. Throughout this document, the RIPE NCC refers to the size of allocation and assignments in terms of 'bits of address space' and adds the length of the route prefix in parentheses wherever appropriate.

1 0

CAll for action - PLEASE READ
by Stephen Burley 15 Apr '02

15 Apr '02

Hi Me again I know half of you are say shut up and go away and the rest just do not care, well I have no where else to go and I think everyone should care about our community. Yesterday I replied to the hostmaster email which contained nothing but excuses for what has been an abysmal service on the hostmaster queue I will get to that later. First I would like to say to the hostmaster in general those who know me and those who do not, you are the backbone of our community and you do a fine job...most of the time ;), and this email is in no way aimed at the hostmasters, it is aimed at the management of the NCC. RIPE fundamental truth number 1 - The NCC is there to work for the BENEFIT of the RIPE community at large. RIPE fundamental truth number 2 - We the RIPE community do not expect the NCC staff to do this out of love but are charged a SERVICE fee which enables the NCC to staff competent, intelligent hostmasters equal to the task at hand. So lets look at the facts. How many people work for the NCC 100 approx? How many are working as hostmasters 27? I do not see the lack of staffing, what I do see is a shift in priorities. All NCC staff members should be trained on the hostmaster desk for at least 6 months or until they are a competent hostmaster and can make correct decisions on requests. All NCC staff should spend a week every 6 months answering queries so they never lose their hostmaster skill. Throwing more staff at the wait queue problem is not the answer we have the staff at the NCC they are just not used when needed to help with increased work loads. Question - How many times has the wait queue ever been at an acceptable level 3 days max? Notice I said max not minimum, requests should not be in the queue longer than 3 days even this would be excessive in my view. In the current climate order to revenue needs to be as short as possible and if we have to build into the order process a possible 10 day delay that is unacceptable, we should be able to build in to our order processes a standard response time for all requests. And remember the wait queue list only measures how long before the initial response it does not account for the email conversation between hostmasters which could mean anything upto a week or more. So lets go back to the email we received giving us excuses for the pitiful turnaround times: 1. Firstly, the number of tickets opened by LIRs during the first three months of 2002 was approximately 6% higher than that period in 2001. I am sorry this is bad management it is obvious this increase would happen why was it not planned for? We work on the internet which has not stopped growing or had that escaped managements notice ;) 2. Secondly, the number of mergers and closures of LIRs have more than doubled and their complexity has risen. We are seeing far more mergers involving six or more LIRs. Fuller details will be presented at the next RIPE meeting (RIPE42, 29 April - 3 May 2002 in Amsterdam). And? This in no way should have any impact on the rest of the community - bad management! 3. Finally, the "criteria for an initial /20 PA allocation" policy implemented in November 2001 has placed an additional load on our New-LIR Co-ordinators. Now this is possibly the worst, since the NCC came up with this policy it would have seemed obvious to the world that this would increase the load on the hostmasters apart from the NCC management as they did not planned for it. They are not reasons they are excuses for bad management and far from excusing the hostmasters for not doing their job (because they are) if firmly points the finger at bad management and a lack of prioritising. The NCC has the resources to get the wait queue under control they are not being used. When was the last time Axel approved a request? If management do not see the wait queue as a major problem we are in trouble. If management do see the problem why are all hands not on the pumps (ALL)? I am not going to even start on the task force findings and ask what has been done and what has not been done it just frustrates our efforts. To summarise: A. ALL NCC staff should be trained on the hostmaster queue. B. ALL NCC staff should help with excessive wait queues 3 days +. C. If the above is not acceptable I would remind the community of the 2 fundamental truths stated at the start of this email. D. If A and B do not solve the problem then we look to changing the workflow process i.e.. adding an automated approval system with proper audit tracking and processes as detail by the task force or arrange another task force paid by the NCC this time. http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/lir-wg39-ple naryreport/sld012.html This problem has reared its head too many times, its now time to listen to the community and do what they ask, you the NCC have given us your assurance this would be brought under control and have failed every time. Have a look at APnic, they would never have a wait queue longer than 3 days, and if ARIN had the wait queue we have the Americans would be calling for legal action. Why should we put up with a second rate service? It used to be RIPE was the registry which showed the way it should be done, i think it may have been side tracked. Lets get this one solved once and for all time!! Regards Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE

12 13

Re: Current wait times
by Mirjam Kuehne 15 Apr '02

15 Apr '02

Dear LIRs, Be assured that we take this matter very seriously and we are doing all we can to improve the situation. All suggestions made by the "17th May Task Force" and agreed by the LIR WG were implemented (since May 2001) and resulted in a significantly lower response time as you can see on the yearly Hostmaster Waitqueue graph (last graph on the following page): http://www.ripe.net/ripencc/mem-services/registration/rttqueue/rttwaitqueue… Due to market developments (i.e. increase of mergers, take overs, closures) and unforeseen issues with the implementation of the new "Minimum Allocation Criteria" policy in November 2001 we experienced an unexpected high work load since mid January 2002 (as described in our previous mail). These factors appeared unfortunately at the same time. We are currently preparing a detailed report for you to be presented at the RIPE 42 Meeting. However, we are going to send a preliminary summary early next week to this list. Kind Regards, Mirjam Kuehne External Relations RIPE NCC

3 2