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@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-documen... 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@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-syst... 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.