Fwd: a Proposal to replacing RIPE 185
Nurani Nimpuno nurani at ripe.net
Thu Aug 30 05:32:29 CEST 2001
Dear all, As you all know, the RIPE NCC was actioned to review the current IP& ASN policy document, ripe-185 (European Internet Registry Policy and Procedures) and to present a raw first draft to the lir-wg August 29, 2001. Please find this draft attached. As outlined in Hans Petter's mail below, the task was to update the current policy document with policy changes implemented since the publication of ripe-185. Based on feedback from the membership, the objective was also to create a more condensed, clear and concise policy document that would make it easier for new LIRs and End Users to learn relevant IPv4 and ASN policies and procedures. Experience with the previous policy document clearly showed that new members found ripe-185 very complex. There was a clearly expressed need for a simpler and clearer document that could be used on a daily basis as a reference document for the LIRs. I have followed the structure in Hans Petter's mail below and have produced a first draft for the lir-wg to revise. The changes between this document and ripe-185 are the following: - Structure The structure has been completely revised in order to improve readability and making the information easy to find. - Update of policy The policy changes that have taken place since the last published version of the policy document have been incorporated in this draft. In addition to this, the document has been shortened to make it easier for readers to find the relevant information. Some sections have been completely removed as they are either covered elsewhere and/or not within the scope of a concise policy document. The sections that have been removed are: - Reverse Delegation procedures - Separate RIPE Document will be published (Reverse Delegation Policy distilled and kept) - Mergers, transfers & Closures - Separate RIPE Document will be published - RIPE NCC Registration Services - information available on the web (not policy nor procedure) - Request documentation - Available in the Supporting notes document (Currently ripe-220) (Sections pertaining to policy kept) - Obtaining an AS Number - Available in ASN request form and supporting notes (currently ripe-147) (ASN Policy kept however) - Routing considerations - (not policy nor procedure) As explained, this is a first draft produced by the RIPE NCC to facilitate the writing of this document as requested by the lir-wg. We are now welcoming the feedback on the community and the work of the editorial commitee to finalise this policy document. Kind regards, Nurani *--------------------------------------------------------* | Nurani Nimpuno <nurani at ripe.net> | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | *--------------------------------------------------------* ------- Forwarded Message >From: "Hans Petter Holen" <hph at online.no> >To: lir-wg at ripe.net >Subject: a Proposal to replacing RIPE 185 >Date: Wed, 22 Aug 2001 22:17:43 +0200 > >Dear Working Group. >Last year we set up the 17th of May task force to help the RIPE NCC identify >potential improvements to the handeling of requests sent to >hostmaster at ripe.net. May of theese have been implemented with success. The >continuing growth of the number of LIRs does however call for other >meassures to be taken. > >One of the suggestions by the task force and by the RIPE NCC hostmasters was >to improve the IP address request form. A fruther analysis of the >underlying problems seems to indicate that the shortcomings of the form is >merely a symptom. There are clear indications that the whole policy and >procedure document, RIPE 185, would benefit from an overhaul. > >After studying this document which was created when CIRD was still >young and unknow to large parts of our community, we have found that it >cotains a lot of usefull information, which is strictly speaking not >Policies or Procedures. Rewriten in a clearer and more concise way we may >archive a much better common understanding between the individual LIRs and >the RIPE NCCC hostmasters. > >Our hypothesis is therefore that by creating a new strucure for documenting >policy and procedures with better examples, and work on clearifying the >language in the policy statements the work load of the RIPE NCC hostmasters >may be reduced drasticaly. This is due to the fact that for a large >propotion of the requests handeled by the RNH's there is lacking information >the NRH's. By making it clear to the LIRs that it is the LIRs responsibility >to request from the customer and make sure all relevant information is in >the application before it is submittet to the RNH, we belive the total time >spent, both by RNH's, and by LIR staff will be significantly reduced. > >We have therefor proposed the following structure for a replacement of RIPE >185: "Addressing Policies and Procedures for the RIPE NCC service region" > >(Abstract, Introduction, Scope) >Internet Address Space and the Internet Registry System >Policy framework >Policies >Glossary >References >Appendices (bitboundary chart, examples etc) > >Remove the following sections: >All instructions on how to fill out an IP or ASN request form > (in separate "supporting notes" ripe docs) >PA vs PI > (Is described in ripe-127) >RIPE NCC RS (mailboxes, ticketing system, robot etc) > (Instructions on website) >Inaddr procedures (policy to be left in) > (separate ripe doc will be created) >Routing considerations > >Our proposal is that the RIPE NCC will present a first draft by doing >the ground work on the document, re-writing some sections >in a more clear and concise manner. This will then be presented to the >lir-wg and the editorial committe for comments and input. > >We also belive that there is a strong need to publish all policy changes as >RIPE document. If there is a need to reduce the administrative overhead of >changing the procedures and policies document for every policy document, the >changes and amenedments could be made in a single (not more than one at a >time !) "Amendments to Policies and procedures. > >I have spent some days with Nurani and Sabrina at the RIPE NCC and discussed >various ways to do this, and our proposal is to form a RIPE-185bis editorial >team to facilitate discussion on the lir-wg mailing list and working group >meetings and summarise the community consensus. > >----- >Hans Petter Holen, http://hph.home.online.no >Phone: +47 40 20 39 16, Stalsberggt 28 B, 2010 Strxmmen, Norway -------------- next part -------------- IPv4 and ASN Policies in the RIPE NCC Service Region Document ID: ripe-[insert number here] Date Published: [insert date here] Obsoletes: ripe-104, ripe-105, ripe-136, ripe-140, ripe-159, ripe-185 ABSTRACT This document describes the current RIPE NCC policies and procedures associated with IPv4 address space and Autonomous System Number management applicable in the RIPE NCC service region. They are to be implemented by the RIPE NCC and the Local Internet Registries in the RIPE NCC service region. Table of Contents Abstract 1.0 Introduction 1.1 Scope 2.0 Internet Address Space 3.0 The Internet Registry System 3.1 Goals of Public Address Space Distribution 4.0 Policy Framework 5.0 IPv4 and ASN Policies 5.1 General 5.1.1 Validity of assignment 5.1.2 Documentation 5.1.3 Registration requirements 5.2.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.1.9 Static assignments 5.1.10 Web hosting 5.1.11 Assignments within allocations 5.1.12 IP Address Space Replacement Procedures 5.1.13 Assignment Window 5.2 Rules and Guidelines for Allocations 5.2.1 First allocation 5.2.2 Slow-start mechanism 5.2.3 Further allocations 5.2.4 No guarantee of contiguous allocations 5.2.5 Assignments to other providers 5.3 Operating an LIR 5.3.1 Establishing a new LIR 5.3.2 LIR Operations 5.3.3 Record keeping 5.3.4 Contact persons 5.3.5 Publishing LIR policy 5.3.6 Mergers, take-overs, and closures of LIRs 5.3.7 External Quality Assurance 5.3.8 When an LIR is closed by the RIPE NCC 5.4 Reverse Delegation responsibilities 5.5 Autonomous System Numbers 6.0 Glossary 7.0 References 8.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 covers Europe, the Middle East, Central Asia, and African countries north of the equator. As an RIR, it is responsible for the assignment and allocation of IP address space, Autonomous System Numbers and the management of reverse domain name space. The distribution of IP address space follows the hierarchical scheme described in section 3.0. The RIPE NCC allocates address space to Local Internet Registries (LIRs) that assign it to End Users. In this document, we describe the policies and procedures associated with address space management that must be followed by LIRs. The policies described in this document have been developed by the RIPE community, through the open consensus process facilitated by the RIPE NCC. 1.1 Scope This document describes the policies for the responsible management of the globally unique Internet address space and Autonomous System Numbers (ASNs) in the RIPE NCC service region. Particularly, it describes the rules and guidelines governing the distribution of this address space. The rules set forth in this document are binding for all address space allocated and assigned via the RIPE NCC. This document does not describe specific addressing policies related to IPv6, multicast, or private Internet address space. This document does not describe allocation and assignment rules used by other RIRs. 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 IP addresses: Public Addresses The public IP addresses make up the Internet address space. They are assigned to be globally unique according to the goals described in Section 3.1. The main purpose of this address space is to allow communication, using IPv4 over the Internet. One can currently distinguish two kinds of public addresses: Provider Independent (PI) and Provider Aggregatable (PA) addresses. . More information about PI and PA address space can be found in the RIPE document: " Provider Independent versus Provider Aggregatable Address Space" at: http://www.ripe.net/ripe/docs/pi-pa.html 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 coordination. Hosts using these addresses cannot be reached from the Internet. For a thorough description of private address space, please refer to RFC 1918 [Rekhter96b]. Special and Reserved Addresses There are a number of address ranges reserved for applications like multicasting. These are described elsewhere (cf RFC 1112 [Deering89a]) and are beyond the scope of this document. 3.0 The Internet Registry System The Internet Registry System consists of the following levels of hierarchy: Internet Assigned Numbers Authority (IANA), Regional Internet Registries (RIRs), Local Internet Registries (LIRs). The Registry System been established to achieve the goals of public address space distribution: uniqueness, aggregation, conservation, and registration. IANA has authority over all IP number spaces used in the Internet. IANA allocates address space to RIRs, such as the RIPE NCC, to be redistributed to LIRs. The LIRs assign address space to End Users under the guidance of the RIRs, and in accordance with the policies and procedures described in this document. End Users are those organisations operating networks in which the address space is used. 3.1 Goals of Public Address Space Distribution In this document, we are primarily concerned with the management of public Internet address space, as defined in the previous section. Public Internet address space assignments should be made with the following three 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 a 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 trouble shooting 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 Internet Service Providers (ISPs). 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. Definitions Regional Internet Registries RIRs operate in large, geopolitical regions that are continental in scope. Currently, there are three RIRs established: ARIN, serving North America, South America, the Caribbean, and sub-Saharan Africa; APNIC, serving the Asia Pacific region; and the RIPE NCC, serving Europe, Central Asia, the Middle East, and the Northern part of Africa. The duties of an RIR include the co-ordination and representation of its members in its region. Additional RIRs may be established in the future, although their number will remain relatively low. Local Internet Registries LIRs are established under the authority of an RIR. LIRs are typically operated by Internet Service Providers - and serve the customers of those ISPs as well as the customers of smaller ISPs that are connected to the rest of the Internet through the larger ISP. Other organisations such as large enterprises can also operate LIRs. Much of this document is concerned with the responsibility of the LIR in the assignment process. In some cases, the LIR assigning the address space is not run by the ISP that will provide connectivity. It is important to note that the maintenance of the administrative information regarding the assigned address space is the responsibility of the LIR that makes the assignment and not of the ISP providing the connectivity. Furthermore, only RIRs and LIRs can hold address allocations. End User An entity that uses IP address space for its network only and does not provide IP/ASN services to customers. Strictly speaking, End Users are not part of the Internet Registry System. They do, however, play an important role with respect to the goals defined above. In order to achieve the conservation goal, for example, End Users should plan their networks to use a minimum amount of address space. They must document their addressing and deployment plans to the LIR and furnish any additional information required by the LIR for making assignment decisions. To achieve the aggregation goal, an End User should choose an appropriate LIR. End Users should be aware that changing ISPs may require replacing addresses in their networks. Finally, End Users must provide and update registration data for the address space assigned to them. Allocation A block of address space held by an RIR or an LIR from which further allocations or assignments will be made. The RIPE NCC makes allocations to LIRs, from which the LIR can make address space assignments to End Users or to the LIR's own network. Only RIRs can make allocations. An LIR is not allowed to sub-allocate their allocation to any other organisation, it can only make assignments to End Users. Assignment Address space distributed to an End User entity by a RIR or LIR for use in their network, and not to be further distributed. 4.0 Policy framework IP addresses not to be considered property Address space is a finite resource with no intrinsic value and direct costs cannot be ascribed to it. While they may not charge for address space as such, LIRs may charge for their administrative and technical services. For further information on charging for services by LIRs and acceptable practice for such charging please refer to RIPE Document: "Charging by Local Internet Registries", at: http://www.ripe.net/ripe/docs/chargingbylirs.html Impartiality The RIPE NCC represents the interests of the Internet community in general and the Internet community of the RIPE region in particular. As such, it will apply its policies fairly and equitably with respect to all RIPE NCC members, without regard to the size or geographic location of the organisation, or any other factor. Confidentiality Information collected by an RIR or LIR in the registration process must be kept in strict confidence. It is to be used for registration and request evaluation purposes only. The LIR is responsible for protecting the End User's privacy. Aside from the data that is published in the RIR database, the information gathered must be kept in strict confidence. It must be transmitted only to higher level registries and/or IANA upon request, but will not be transmitted to any other party unless explicitly requested in writing by the End User. Registration Every assignment and allocation of public Internet address space must be registered in a publicly accessible registry. Registration of objects pertaining to an assignment in the RIPE Database makes it possible to track the use of address space, support operational contacts, and facilitate studies of address allocation. These activities are essential to the effective maintenance of the Internet. Stockpiling discouraged RIPE NCC policies discourage the stockpiling of IP addresses as it conflicts with the goals of conservation and fairness. Efficient deployment of address space on the basis of demonstrated immediate need is encouraged. Documentation To make appropriate assignment decisions, relevant information must be gathered about the network in question. First, the information is required to make address assignment decisions with respect to the aggregation and conservation goals. Second, the information is required for registration purposes. Good faith The RIPE NCC recognises that its relationships with its members should be based on an implicit trust that the information, network plans, and other documentation provided by LIRs and their customers are genuine and accurate. 5.0 IPv4 and ASN Policies 5.1 General One can currently distinguish two kinds of globally unique, unicast IPv4 addresses: Provider Independent (PI) and Provider Aggregatable (PA) addresses. Provider Independent Addresses IP addresses which are assigned directly to the End User by the RIR. PI addresses are not part of an LIR's allocated block. Provider Aggregatable (PA) Addresses IP addresses that are part of a bigger block of addresses allocated to an LIR (or an RIR). The policies in this section is applicable to all globally unique, unicast IPv4 addresses. Specific policies and guidelines for PA and PI address space are covered later in this section. 5.1.1 Validity of assignment Assignments of any kind of address space are valid as long as the original criteria on which the assignment was based are still valid. If an assignment is made for a specific purpose and the purpose no longer exists, then the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, so is the assignment. 5.1.2 Documentation To make appropriate assignment decisions, relevant information must be gathered about the network in question. Such information may include organisation, addressing requirements, network infrastructure, current address space usage, and future plans of the End User requesting address space. This information is essential to the assignment process, and is formally required by the LIRs. The LIR must assure that the required information is complete before proceeding with the request. For gathering the required information, the RIPE NCC provides a set of forms and supporting notes to fill them in. All information required by the RIPE NCC should be in English. IP address requests requiring evaluation by the RIPE NCC must, however, be submitted on a current version of the "European IP Address Space Request Form" in English: 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 5.1.3 Registration requirements Every assignment and allocation of public Internet address space must be registered in a publicly accessible database. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels. Allocations and assignments in the RIPE NCC service region are registered in the RIPE Database. Only allocations and assignments registered in the RIPE Database are considered valid. Submission of objects to the database is the final and required step in making an assignment. This step makes the assignment definite, and makes public information regarding the assignment available to anyone seeking it. Care should therefore be taken to assure the correctness of the assignment number and of all relevant data prior to completing this step. For further instructions on how to register objects in the database, please see the appendix, section I. 5.1.4 Reservations not supported In accordance with the conservation goal, End Users are not permitted to reserve address space. Evaluation of IP address space requests must be based on demonstrated need. Address space assigned in the past should be used to meet the current request, if possible. 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 Unless there are special circumstances, immediate utilisation should be at least 25% of the assigned address space, and the utilisation rate one year later should be at least 50%. Assignments must be based solely on realistic expectations as specified in the addressing plan and the current address space usage. End Users are not permitted to reserve addresses based on long term plans, because it fragments the address space. 5.1.7 Provider Independent vs. Provider Aggregatable addresses Provider Aggregatable Address Space LIRs operated by Internet Service Providers are allocated Provider Aggregatable (PA) address space that they assign to their End Users. If an End User changes service providers, their PA address space will have to be replaced. The End User will need to obtain a new address space assignment and return the previously assigned address space. Provider Independent Address Space In contrast to PA address space, PI address space can remain assigned to its user as long as the criteria for the original assignment are met. The apparent advantage of PI address space is that a User's hosts and routers need not be reconfigured if the user decides to change service providers. However, PI addresses are expensive to route because no use can be made of aggregation. LIRs must make it clear to the user which type of address space is assigned. Clear contractual arrangements that specify the duration of the address space assignment are mandatory for every assignment of PA address space. Although not strictly required, it is strongly recommended that contractual arrangements are made when assigning PI space as well. With respect to aggregation, the clear advantages of assigning PA space mandate that LIRs recommend its use whenever possible. End Users should, therefore, be advised to use PA space if it appears to be sufficient for their situation. 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. For this reason, users should always be informed that private addresses might be a viable option. For a thorough description of private address space, please refer to RFC 1918 [Rekhter96b]. 5.1.9 Static assignments Due to constraints on the available free pool of IPv4 address space, the use of static IP address assignments (e.g., one address per customer) for dial-up users is strongly discouraged. Organisations considering the use of static IP address assignment are expected to investigate and implement dynamic assignment technologies whenever possible. If assignments for static assignments are indeed made, special verification procedures apply. However, for services that are permanently connected to the Internet, static one-to-one connections is considered acceptable. Verification of usage will in these cases take place when the LIR is requesting approval for additional assignments. Please contact the RIPE NCC for details on applicable verification methods. 5.1.10 Web hosting Recent developments in some protocols (for example HTTP 1.1) have eliminated the need for one-to-one mapping of IP addresses to web sites. In accordance with the goal of conservation, the RIPE NCC policy strongly encourages the deployment of name-based web hosting versus IP-based web hosting. The RIPE NCC does acknowledge the need for IP-based web hosting for certain applications. Special verification methods apply for IP-based web hosting. 5.1.11 Assignment guidelines LIRs make assignments from its allocated address block. If the addresses are to be assigned from a range of address space allocated to the LIR making the assignment, then care must be taken to prevent fragmentation of the allocated space. Specifically, each set of address space assigned should start on a CIDR (bit) boundary. This helps to achieve the aggregation goal in address space assignments. Suppose an assignment request can be satisfied with either a number of small chunks of address space or with a single large one. For example, if 384 addresses are sufficient to satisfy a request, but no more than 256 will be used in a single physical subnet, then the user can be assigned a /24 and a /25 rather than a /23. This results in saving a /25 for another user. In general, and in accordance with the conservation goal, LIRs are encouraged to assign multiple ranges of addresses rather than a single large range. LIRs are always welcome to request advice from the RIPE NCC in making assignment decisions. Assignments larger than those which the LIR is authorised to make must be approved by the RIPE NCC in advance. The assignment size that an LIR is autorised to make without prior approval is based on the LIR's experience and is reflected in the LIR's assignment window. (See section 5.1.13.) 5.1.12 IP address space replacement procedures In general, address space should be replaced on a one-to-one basis. An assignment of PA space to replace previously assigned PI space can be made if the original assignment criteria are still met and if the address space to be replaced is currently used for the End User's network. Only if a large percentage of the original assignment is not in use (50%) will an End User be required to submit the usual documentation to the new LIR. This part of the request is then treated like any other request for assignment of additional addresses. The address space to be replaced (the individual address ranges and the total size) must be properly documented with the standard IP address space assignment request forms. For address space that was allocated by LIRs established within the framework of the RIPE NCC, a copy of the documentation is forwarded to the LIR or LIRs that assigned the address space being replaced. Before assigning the new address space, an agreement (preferably contractual) should be reached regarding the maximum period within which the previously assigned addresses will be returned to the original LIR or to the RIR for eventual reassignment. After the renumbering is complete, the RIPE database must be updated to reflect the changes. In general, a period of three months should be allowed for the End User to complete the transition to the new addresses. RFC 2008, "Implications of Various Address Allocation Policies for Internet Routing" [Rekhter96a], recommends a grace period of at least 30 days and no longer than six months. For exceptional cases, where the End User requests to keep both assignments for more than six months, agreement should be obtained for the proposed time frame from the RIPE NCC. For those addresses that have not been assigned by an LIR, or which were assigned by an LIR that has since closed, the RIR will act in lieu of the original LIR. 5.1.13 Assignment Window An Assignment Window (AW) refers to the maximum number of addresses that can be assigned by the LIR to an End User without prior approval by the RIPE NCC within a 12 month period. The Assignment Window procedure was put in place to achieve various levels of support, based on the level of experience of the LIR and to ensure that assignment criteria and procedures are properly applied by the LIRs. To assure that the conservation, aggregation, and registration goals are met, the assignment criteria and procedures need to be properly applied by all LIRs. All new LIRs start with an Assignment Window of zero (0). This means that every assignment requires prior approval by the RIPE NCC before becoming effective. The Assignment Window is not only applied to individual assignments, but to multiple assignments to the same End User in a 12 month period. If an LIR makes more than one assignment to an organisation in any 12 month period, the total amount of address space assigned may not exceed the LIR's assignment window. This also applies to address space used by the LIR for their internal network. Additional address space may be assigned to that organisation only upon approval by the RIPE NCC. Address space assignments larger than the LIR's Assignment Window is formally invalid until explicit approval is acquired from the RIPE NCC. Without this approval, the address space cannot be used as it may result in a failure to meet the uniqueness requirement for Internet addresses at a later date. The AW is regularly reviewed by the RIPE NCC Hostmasters, based on the proficiency of the LIR staff. The Assignment Window may be raised as the proficiency of the LIR staff increases and it can also be lowered if erroneous assignments are made by the LIR or if new LIR staff needs additional support. It should be noted that LIRs may approach the RIPE NCC for an evaluation of its Assignment Window. Additionally, LIRs are always welcome to approach the RIPE NCC for a second opinion on requests that fall within the LIR's Assignment Window. For further explanation of the Assignment Window procedures, please see Appendix, section II. 5.2 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 permitted to allocate 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. Moreover, without prior approval by the RIPE NCC, LIRs are not permitted to exchange or transfer allocated address space among them. 5.2.1 First allocation The minimum allocation size allocated to LIRs is a /20 (4096 addresses), according to the slow-start mechanism described below. It is expected that this prefix is announced as one aggregate. Allocations are made to LIRs that meet one of the following criteria: A. The LIR must demonstrate previous efficient utilisation of at least a /22 (1024 addresses). Or B. The LIR must demonstrate an immediate address space need of at least a /22 (1024 addresses.) Additionally, if current address space held by the LIR amounts to a /22 or less, then the LIR is required to renumber its address space into the allocation it receives from the RIPE NCC. As only assignments registered in the RIPE Database are considered valid, verification of previous utilisation by an organisation is based on the assignments registered in the database. 5.2.1 Slow-start mechanism The slow-start mechanism was put in place by the RIRs to ensure a consistent and fair policy for every LIR with respect to allocations. The slow-start mechanism was also introduced to prevent allocating large blocks of address space that will not be used. The idea is to allocate address space to LIRs at the rate it will be assigned. The minimum size of an individual address space allocation is /20 (4096 addresses). 5.2.2 Further allocations An LIR is eligible for additional address space allocation when at least eighty (80) percent of the currently allocated address space is assigned, or if a single assignment will require a larger set of addresses than can be satisfied with the allocated address space. Reservations are not counted as assignments. An LIR can set aside (or "reserve") address space in their allocation for customers, if they think the customers will grow beyond their assignments. However, once the LIR's allocation reaches depletion and the LIR starts running out of address space, they should reuse these "reserved" blocks by giving them to other customers. The RIPE NCC will consider "reservations" as free address space when evaluating an allocation request. 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 that includes a complete list of the assignments made from their last allocation. However, all previous allocations made to the LIR also need to show a utilisation rate of at least 80%. The RIPE NCC will verify the LIR's utilisation rate, compare it with assignments registered in the database, and may request further information (such as documentation of some of the assignments) to determine the need for a new allocation. 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. 5.2.3 No guarantee of contiguous allocations A new allocation to an LIR cannot be expected to be contiguous with past allocations. While the RIPE NCC always aims to further the aggregation goal by allocate contiguous space, multiple allocations made to the same LIR can not be guaranteed to be contiguous and aggregatable with previous allocations. Contiguous allocations are merely done on a best effort basis. 5.2.4 Assignments to other providers In some cases, an LIR makes address space assignments for the customers of another ISP that, itself, does not operate an LIR. The LIR is responsible for all assignments from its allocation, even if there is an agreed involvement of the staff from the other ISP. Whereas the staff of the other ISP can and should be involved in processing the End User's request, local agreements regarding shared responsibility in the registration process are not recognised by the RIR and are strongly discouraged. If, at some point, an ISP decides to establish an LIR rather than using an existing LIR to obtain address space, then all subsequent assignments it makes should be from address space allocated to it from the RIPE NCC. Furthermore, any address space used by the ISP's customers that was acquired from a transit provider's allocations should be returned to the transit provider as soon as possible, and new assignments should be made to the End Users from the ISP's allocated address space. In the following subsections, we describe how an LIR can obtain an allocation and how allocated address space should be managed. 5.3 Operating an LIR LIRs process the vast majority of address space assignments to End Users. Most LIRs are operated by ISPs and offer IP registration services to the customers of the ISP. In this section, we describe a number of services offered by the RIPE NCC to facilitate the uniform implementation of the policies outlined in this document. We also outline 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 RIPE NCC service area. 5.3.1 Establishing a new LIR An LIR is established after submitting a request to the RIPE NCC that includes assurances that the relevant rules and guidelines defined in this and related documents are known and a commitment that the rules and guidelines will be followed. 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": http://www.ripe.net/ripe/docs/new-lir.html 5.3.2 LIR operations In this section, we outline a number of practices that should be followed when running an LIR. Most have been established traditionally by consensus among the LIRs in the RIPE community. LIRs should adhere to the established practices, or move to have them modified by starting discussions on the <local-ir at ripe.net> mailing list, and actively participate in the LIR working group. 5.3.3 Record keeping LIRs must maintain proper records about all address assignments made by them. Every LIR should keep all information collected from those customers who are in the process of making a request for an IP address space and ASN assignment. This data is needed for the evaluation of subsequent requests for the same customers, 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 that they are readily accessible. If requested, any of this information should be made available to the RIPE NCC in English. 5.3.4 Contact persons Every LIR must provide the RIPE NCC with a list of contact persons. The contact persons should be those who submit address space and AS number requests for the LIR. The contact information should be kept up to date. Address space and AS number requests will only be accepted from LIR staff members that are registered as contact persons for an LIR. This is necessary to ensure confidentiality. 5.3.5 Publishing LIR policy The core business of an LIR is to assign IP addresses. These have no intrinsic value, although they are essential for Internet connectivity. They must be assigned judiciously with regard to volume; strategically with regard to aggregation; and equitably as between different ISPs. The best assurance of these objectives is "perfect knowledge" by the market of the policies of LIRs. For this reason, every LIR must publish its policies regarding LIR operations. LIRs must register their policies with the RIPE NCC, which will publish them. The information to be published should include at least the following: 1) The Community Served An LIR should provide a concise description of the community it serves. The following description is sufficient: "We serve customers of <foo> company, an ISP with mostly <bar> type customers based in countries NN AA BB and CC". The LIR should also indicate whether it will provide IP address space registration services to those not buying other services from them. 2) Charging Policies An LIR must publish its charging policy. The policy is defined in the RIPE Document: "Charging by Local Internet Registries". http://www.ripe.net/ripe/docs/chargingbylirs.html Address space is a finite resource with no intrinsic value and direct costs cannot be ascribed to it. While they may not charge for address space as such, LIRs may charge for their administrative and technical services. LIRs must publish their operating procedures and details of the services they offer and the conditions and terms that apply, including scales of tariffs if applicable." 3) Terms of Assignment The LIR must publish its policy about assigning Provider Aggregatable (PA) and Provider Independent (PI) address space, and the terms and conditions that apply. 5.3.6 Mergers, take-overs, and closures of LIRs If an LIR changes ownership (e.g. merger, sale, or take-over), then the new entity must register with the RIPE NCC any changes to its network usage and contact personnel. If the effect of a take-over, sale, or merger is that the LIR changes its name, then the LIR must provide to the RIPE NCC relevant legal documentation supporting the name change. For further information on change of LIR ownership and closures, please refer to the RIPE Document: [Insert RIPE Document Name & Link here] 5.3.7 External Quality Assurance In order to promote consistent and fair application of assignment criteria, with regard to conservation and registration of address space and aggregation of routing information, the RIPE NCC checks consistency of registry data and performs auditing of LIRs. To ensure that LIRs are following the assignment criteria, and entering assignments into the database correctly, the RIPE NCC may contact an LIR to ask for documentation or for more information about certain requests or database entries. If the RIPE NCC finds problems, it will work with the LIR to correct these. If necessary, the RIPE NCC may take corrective actions, such as lowering the LIR's Assignment Window. This activity is described in detail in the RIPE Document, "RIPE NCC Consistency and Auditing Activity", which can be found at: http://www.ripe.net/ripe/docs/auditing.html For further information on the RIPE NCC auditing activity, please refer to: http://www.ripe.net/audit 5.3.8 When an LIR is closed by the RIPE NCC The RIPE NCC may decide to close an LIR that stops paying its bills to the RIPE NCC and/or cannot be contacted by the RIPE NCC for a significant period of time. Moreover, if an LIR consistently violates the policies established by IANA, or within the RIPE NCC community, in spite of multiple warnings, then it may be closed. The RIPE NCC will send the LIR a message to notify it of its closure. The LIR must then provide documentation to the RIPE NCC regarding its allocated address space and follow the other procedures for closing an LIR outlined in RIPE Document: [Insert RIPE Document Name & Link here] If the LIR does not provide the RIPE NCC with the proper documentation, the RIPE NCC will determine which address space and ASNs should be returned to the public pool of IP address space. 5.4 Reverse Delegation responsibilities The RIRs are responsible for maintaining IN-ADDR.ARPA records only for the parent blocks of IP addresses issued directly to the ISPs and for CIDR blocks smaller than /16. LIRs with a prefix length of /16 or shorter will be responsible for maintaining all IN-ADDR.ARPA resource records for their customers. IN-ADDR.ARPA resource records for networks not associated with a specific LIR will continue to be maintained by the RIRs. Internet Providers and End Users with address blocks must verify their own internal networks are properly represented in IN-ADDR records, either by providing that service themselves, or delegating it to others. For details on the RIPE NCC Reverse Delegation procedures, please refer to: [Insert RIPE Document Name & Link here] 5.5 Autonomous System Numbers Autonomous System (AS) Numbers are assigned to organisations that are multihomed and have a single, clearly defined routing policy that is different from their providers' routing policies. AS Numbers should be requested in accordance with the guidelines expressed in RFC 1930, "Guidelines for the creation, selection, and registration of an Autonomous System". In order to help decrease global routing complexity, a new AS Number should be created only if a new routing policy is required. Autonomous System Numbers should be requested through the European Autonomous System Number Application Form that can be found at: http://www.ripe.net/ripe/docs/asrequest.html The RIPE NCC assigns AS numbers for Autonomous Systems that are located in the RIPE NCC service region. As for IP address requests, the RIPE NCC accepts requests for AS numbers only from LIRs that contribute to the RIPE NCC. Returning an AS Number If an organisation has an AS Number that is no longer in use, it can be returned to the public pool of AS Numbers by sending a message to <hostmaster at ripe.net>. It can then be re-assigned to another Autonomous System by the RIPE NCC. 6.0 Glossary (This section provides a brief description of important terms used in this document.) Address Space -- Specific to global, unicast IPv4 and IPv6 addresses, a unique numeric address used to identify a machine on the Internet (i.e., 123.456.789.012). An address space represents an extent of storage available to a program. Aggregation --- One of the main goals of Internet administration, aggregation refers to the distribution of public Internet addresses in a hierarchical manner that permits the "combining" of routing information and limiting the number of routing entries advertised in the Internet. This is necessary to ensure the proper operation of Internet routing. Allocation -- The range of addresses made available by the RIPE NCC to an LIR, which in turn is used by the LIR in assigning address space to End Users. The LIR is not allowed to sub-allocate its allocation to any other organisation. It can only make assignments to End Users. The minimum size of the first allocation to an LIR is a /20 (4096 addresses). The RIRs get their allocations from the Internet Assigned Numbers Authority (IANA). Assignment ---Address space provided to an End User entity by an RIR or LIR for use on their own network, not to be further distributed to customers. The LIR guarantees that no other End User will be assigned the same address space during the validity of the assignment. Assignments of any kind of address space are valid for as long as the original criteria on which the assignment was based are still valid. Assignment Window (AW) -- The maximum number of addresses that can be assigned by an LIR to an End User without prior approval by the RIPE NCC. The AW for new LIRs is zero (0); every assignment requires prior approval by the RIPE NCC. As the LIR staff becomes familiar with policies, procedures, and makes less errors, the AW size is increased to match the size of requests sent by the LIR. Autonomous System (AS) -- Group of IP networks run by one or more network operators that has a single and clearly defined external routing policy. The term "AS" is often confused and even misused as a convenient way of grouping together a set of networks that belong under the same administrative umbrella, even if within that group of networks there are various routing policies. The RIPE NCC provides the "community" concept for such use. Autonomous Systems can, strictly speaking, have only one external routing policy. Autonomous System Number -- A unique number associated with an Autonomous System that is used both in exchange of exterior routing information and as an identifier of the AS itself. Exterior routing protocols such as Border Gateway Protocol (BGP) and Exterior Gateway Protocol (EGP) are used to exchange routing information between Autonomous Systems. Conservation --- One of the main goals of Internet administration, it refers to the fair distribution of globally unique Internet address space according to the operational needs of the End Users and ISPs operating networks using this address space. This aids in the prevention of stockpiling in order to maximise the lifetime of Internet address space. Contiguous Allocation -- An additional address block that can be combined with another allocated address range to a larger aggregate. End User -- An entity that uses IP address space for its own network only and does not provide services to customers. First Allocation -- An address block allocated to an LIR upon the first address space assignment request the RIPE NCC receives from that LIR. Internet Community -- An open, collaborative community of organisations and individuals, operating wide area IP networks. In this document we refer mainly to the RIPE community. Internet Registry System -- Created through membership-based associations, the Registry System exists to provide IP address allocations and registration services. It consists of the following levels of hierarchy as seen from the top, down: IANA, RIRs, LIRs, End Users. It was established some 10 years ago to achieve the goals of public address space distribution, which are uniqueness, aggregation, conservation, and registration. Local Internet Registry (LIR) -- An organisation, established under the authority of a Regional Internet Registry, that assigns IP addresses and Autonomous System Numbers to End Users. LIRs are mostly operated by ISPs and serve their customers and - smaller ISPs. The maintenance of administrative information regarding assigned address space is the responsibility of the LIR making the assignment, not the ISP providing connectivity. Only LIRs can hold IP address allocations that they assign to their End Users. Private Addresses -- Addresses assigned to hosts that: 1) do not require access to hosts in other enterprises or the Internet at large, or, 2) need access to a limited set of outside services (e.g., e-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). (See RFC 1918) Provider Aggregatable Address Space -- PA address space is Provider Aggregatable, meaning that the addresses are part of a bigger block of addresses allocated to the upstream provider. In contrast, Provider Independent (PI) addresses are not part of an LIR's allocated block. More information about PI and PA address space is explained in the RIPE Document, "Provider Independent versus Provider Aggregatable Address Space". Provider Independent Address Space -- PI address space can remain assigned with its End Users even if they move to another ISP, unlike with PA address space. The duration of the assignment is independent of the use of a particular ISP's services. The advantage is that the End Users' hosts and routers need not be reconfigured. However, the RIPE community discourages the use of PI address space because they may not be routed on certain parts of the Internet where routing tables grow too big. PI ranges are usually small, so they are the first candidates to be dropped from routing tables. PI users cannot receive more addresses for routing reasons. More information about PI address space is explained in the RIPE Document "Provider Independent versus Provider Aggregatable Address Space". Public Addresses -- Addresses assigned to hosts that need network layer access outside the enterprise (provided via IP connectivity). These hosts require IP addresses that are globally unambiguous. (See RFC 1918) Regional Internet Registry -- RIRs are established under the authority of the Internet Assigned Numbers Authority (IANA). They operate in large geopolitical regions, such as continents, and among their duties are the coordination and representation of LIRs in their respective regions, allocation and assignment of IPv4 and IPv6 address space, AS Numbers, and maintenance of public databases. There are three existing RIRs in the world: RIPE NCC, ARIN, and APNIC. Registration -- One of the main goals of the Internet, it is the provision of a public registry documenting address space allocations and assignments. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels. (See RFC 2050) Renumbering a Network -- - Changing the IP host addresses, and perhaps the network mask, of each device within the network that has an address associated with it. (See RFC 2071) RIPE Community -- Made up of organisations and individuals with an interest in the operation of wide area networks or Internet administration. RIPE is a collaborative organisation open to all parties. The objective of RIPE is to ensure the administrative and technical coordination necessary to enable the operation of an IP network in the RIPE region. There are no membership requirements for participation in RIPE and activities are performed on a voluntary basis. The RIPE community is an important source of public input for the RIPE NCC. RIPE Database -- A public Whois Database that contains information about allocations and assignments of IP address space, Internet routing, and related objects in the RIPE region. It is known as the RIPE Network Management Database or, more usually, the "RIPE Database". The information in the database is available to the public for agreed Internet operational purposes. This supports Network Information Centres and Network Operation Centres all over Europe and beyond to perform their respective tasks. Slow-Start Mechanism: -- The first allocation that an LIR receives will be the size of the minimum practical allocation. The slow-start policy is used by all Regional Internet Registries to prevent allocations of large blocks of address space that may then remain substantially unassigned. Uniqueness: One of the main goals of the Internet, it is the insurance of IP addresses being globally unique. 7.0 References To be completed 8.0 Appendices I. RIPE Database procedures Registration of objects pertaining to an assignment in the RIPE Database makes it possible to track the use of address space, facilitate operational contacts, and facilitate studies of address allocation. These activities are essential for the effective maintenance of the Internet. Submission of objects to the Database is the final and required step in making an assignment. This step makes the assignment definite, and makes public information regarding the assignment available to anyone seeking it. Care should, therefore, be taken to assure the correctness of the assignment and of all relevant data prior to completing this step. The information collected about the User's organisation in the Network Template (see http://www.ripe.net/ripe/docs/iprequestsupport.html) is used to construct an inetnum database object. The range of addresses assigned to the User is also entered in the inetnum object, and is specified in dotted quad notation. For example, if an organisation is assigned a /22 address set for 1024 network addresses, the range will be something like: 193.1.192.0 - 193.1.195.255. Unless up-to-date objects are already available in the RIPE Database, in addition to the inetnum object, a person object must be submitted for each person specified in the tech-c and admin-c fields of the inetnum object. The person object needs to reference a nic-handle. The information should remain in the 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 Database. Assuming the assigning LIR has properly stored information gathered in the assignment process for future reference, submission of the objects described above completes the assignment process. The LIR can now provide the End User with the assigned address range and any other data relevant to its use. The type of assigned address space must be registered in the status attribute of the inetnum object within the RIPE Database by the assigning LIR. 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. Moreover, to improve registration of old assignments, LIRs are encouraged to mark past assignments in the RIPE Database with PA or PI as appropriate. Any assigned address space without an explicit type in the status attribute is assumed to be PI space. Priority should, therefore, be given to marking PA space as such. Allocation registration Allocations are registered in the RIPE Database by the RIPE NCC using inetnum objects. Information about the LIR, which is similar to that for an End User receiving an assignment, is stored together with the range of allocated address space and its type. The range of addresses is stored in the inetnum field in dotted quad notation. The type of address 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. 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 receive this allocation type. These objects are maintained by the RIPE NCC. When hierarchical authorisation is implemented, authorisation can be used for the creation of inetnum objects "under" the allocation objects. ASN registration Aut-num objects are registered in the RIPE Database by the RIPE NCC upon approval of an AS Number request, using the aut-num template provided in the request form by the requesting LIR. It is important to note that once the aut-num object is entered into the Database, it is the LIR's responsibility to maintain the object. It is also the LIR's responsibility to keep the information in the aut-num object up-to-date. 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 As explained in Section 5.1.13, the Assignment Window is the maximum number of addresses that can be assigned by the LIR to an End User without prior approval by the RIPE NCC. This is expressed in "/nn" notation. Therefore, an LIR with an Assignment Window of /23 is allowed to assign up to and including 512 addresses to an End User without prior approval of the RIPE NCC. All new LIRs start with an Assignment Window of "0". This means that every assignment requires prior approval by the RIPE NCC before becoming effective. Ex. 1: The LIR has an Assignment Window of "0". The LIR has to send in every assignment to the RIPE NCC for approval. Ex. 2. The LIR has an Assignment Window of /26. The LIR can assign up to 64 addresses per customer in a 12 month period. Larger assignments need to be sent to the RIPE NCC for approval. Any additional assignments exceeding 64 addresses also need to be sent to the RIPE NCC for approval. The AW is regularly reviewed by the RIPE NCC Hostmasters. Raising of the Assignment Window As the proficiency of the LIR staff increases, the size of their Assignment Window may be raised. This is determined based on whether assignment documentation presented to the RIPE NCC is correctly completed; whether good judgement is shown in the evaluation of address space requests; whether past assignments have been properly registered; and on the experience of the LIR with handling larger assignments. An LIR can also approach the RIPE NCC if they believe they are eligible for a raise of its Assignment Window. Lowering of the Assignment Window An established LIR is responsible to train new staff to handle address space assignments, according to the policies and procedures described in this document. Sometimes, due to time constraints on experienced LIR staff, the training is not performed sufficiently. As well, new staff members of a well-established LIR may make errors both in judgement and procedure before they are properly trained to make assignments. If such errors are noticed by the RIPE NCC, the LIR will be notified. If errors happen repeatedly, the Assignment Window of the LIR may be decreased to prevent the new staff members from making erroneous assignments involving large amounts of address space. 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. In some cases, LIRs may request a temporary lowering of their Assignment Window as a method to train new staff. 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 IV. Bit Boundary Chart Historically, IP addresses have been assigned in the form of network numbers of class A, B, or C. With the advent of classless inter-domain routing (CIDR) this classful restrictions are no longer valid. Address space is now allocated and assigned on bit boundaries. The following table illustrates this: +----------------------------------------------+ |addrs bits pref class 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 1C 255.255.255 | | 512 9 /23 2C 255.255.254 | | 1K 10 /22 4C 255.255.252 | | 2K 11 /21 8C 255.255.248 | | 4K 12 /20 16C 255.255.240 | | 8K 13 /19 32C 255.255.224 | | 16K 14 /18 64C 255.255.192 | | 32K 15 /17 128C 255.255.128 | | 64K 16 /16 1B 255.255 | | 128K 17 /15 2B 255.254 | | 256K 18 /14 4B 255.252 | | 512K 19 /13 8B 255.248 | | 1M 20 /12 16B 255.240 | | 2M 21 /11 32B 255.224 | | 4M 22 /10 64B 255.192 | | 8M 23 /9 128B 255.128 | | 16M 24 /8 1A 255 | | 32M 25 /7 2A 254 | | 64M 26 /6 4A 252 | | 128M 27 /5 8A 248 | | 256M 28 /4 16A 240 | | 512M 29 /3 32A 224 | |1024M 30 /2 64A 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 normally is 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. 'class' The size of the address space in terms of classful network numbers. 'mask' The network mask defining the routing prefix in dotted quad notation. Throughout this document, we refer to the size of allocation and assignments in terms of 'bits of address space' and add the length of the route prefix in parentheses wherever appropriate.
[ lir-wg Archives ]