IPv6 Address Allocation and Assignment Assignment Policy

This document defines registry policies for the assignment and allocation of globally-unique IPv6 addresses to ISPs and other organizations. This document obsoletes the "Provisional IPv6 assignment and allocation policy document". This document was developed jointly by the communities of APNIC, ARIN, and RIPE.

Comments 0

Document transcript

IPv6 Address Allocation and Assignment Assignment PolicyStatus of this MemoThis document was developed through joint discussions among theAPNIC, ARIN and RIPE communities.AbstractThis document defines registry policies for the assignment andallocation of globally-unique IPv6 addresses to ISPs and otherorganizations. This document obsoletes the "Provisional IPv6assignment and allocation policy document".This document was developed jointly by the communities of APNIC,ARIN, and RIPE.ContentsStatus of this Memo.......................................... 11. Introduction............................................. 11.1. Overview............................................ 12. Definitions.............................................. 12.1. Internet Registry (IR).............................. 12.2. Regional Internet Registry (RIR).................... 12.3. National Internet Registry (NIR).................... 12.4. Local Internet Registry (LIR)....................... 12.5. Allocate............................................ 12.6. Assign.............................................. 12.7. Utilization......................................... 12.8. HD-Ratio............................................ 12.9. End site............................................ 13. Goals of IPv6 address space management................... 13.1. Goals............................................... 13.2. Uniqueness.......................................... 13.3. Registration........................................ 13.4. Aggregation......................................... 13.5. Conservation........................................ 13.6. Fairness............................................ 13.7. Minimized Overhead.................................. 13.8. Conflict of goals................................... 14. IPv6 Policy Principles................................... 14.1. Address space not to be considered property......... 14.2. Routability not guaranteed.......................... 14.3. Minimum Allocation.................................. 14.4. Consideration of IPv4 Infrastructure................ 15. Policies for allocations and assignments................. 15.1. Initial allocation.................................. 15.1.1. Initial allocation criteria.................... 15.1.2. Initial allocation size........................ 15.2. Subsequent allocation............................... 15.2.1. Subsequent allocation criteria................. 15.2.2. Applied HD-Ratio............................... 15.2.3. Subsequent Allocation Size..................... 15.3. LIR-to-ISP allocation............................... 15.4. Assignment.......................................... 15.4.1. Assignment address space size.................. 15.4.2. Assignment of multiple /48s to a single end site 15.4.3. Assignment to operator's infrastructure........ 15.5. Registration........................................ 15.6. Reverse lookup...................................... 15.7. Existing IPv6 address space holders................. 16. References............................................... 17. Appendix A: HD-Ratio..................................... 18. Appendix B: Background information....................... 18.1. Background.......................................... 18.2. Why a joint policy.................................. 18.3. The size of IPv6's address space.................... 18.4. Acknowledgment...................................... 11. Introduction1.1. OverviewThis document describes policies for the allocation and assignment ofglobally-unique Internet Protocol Version 6 (IPv6) address space. Itupdates and obsoletes the existing Provisional IPv6 Policies ineffect since 1999 [RIRv6-Policies]. Policies described in thisdocument are are intended to be adopted by each registry. However,adoption of this document does not preclude local variations in eachregion or area.[RFC2373, RFC2373bis] designate 2000::/3 to be global unicast addressspace that IANA may allocate to the RIRs. In accordance with[RFC2928, RFC2373bis, IAB-Request], IANA has allocated initial rangesof global unicast IPv6 address space from the 2001::/16 address blockto the existing RIRs. This document concerns the initial andsubsequent allocations of the 2000::/3 unicast address space, forwhich RIRs formulate allocation and assignment policies. Because endsites will generally be given /48 assignments [RFC 3177, RIRs-on-48s], the particular emphasis of this document is on policiesrelating the bits within 2000::/3 to the left of the /48 boundary.However, since some end sites will receive /64 and /128 assignments,all bits to the left of /64 are in scope.This policy is considered to be an interim policy. It will bereviewed in the future, subject to greater experience in theadministration of IPv6.2. Definitions[note: some of these definitions will be replaced by definitions fromother RIR documents in order to be more consistent.]The following terms and their definitions are of particularimportance to the understanding of the goals, environment, andpolicies described in this document.Responsibility for management of IPv6 address spaces is distributedglobally in accordance with the hierarchical structure shown below.+--------+| IANA |+--------+|+-----------+| |+--------+ +--------+| RIR | | RIR | Regional Internet+--------+ +--------+ Registries (APNIC, ARIN, RIPE NCC,| | plus possible future RIRs)| || +-----+| | NIR | National Internet| +-----+ Registries (AP region)| |+--------+ +--------+|LIR/ISP | |LIR/ISP | Local Internet+--------+ +--------+ Registries (ISPs)| |+--------+ || | |+-------+ +----+ +----+|EU(ISP)| | EU | | EU | End users+-------+ +----+ +----+2.1. Internet Registry (IR)An Internet Registry (IR) is an organization that is responsible fordistributing IP address space to its members or customers and forregistering those distributions. IRs are classified according totheir primary function and territorial scope within the hierarchicalstructure depicted in the figure above.2.2. Regional Internet Registry (RIR)Regional Internet Registries (RIRs) are established and authorized byrespective regional communities, and recognized by the IANA to serveand represent large geographical regions. The primary role of RIRsis to manage and distribute public Internet address space withintheir respective regions.2.3. National Internet Registry (NIR)A National Internet Registry (NIR) primarily allocates address spaceto its members or constituents, which are generally LIRs organized ata national level. NIRs exist mostly in the Asia Pacific region.2.4. Local Internet Registry (LIR)A Local Internet Registry (LIR) is an IR that primarily assignsaddress space to the users of the network services that it provides.LIRs are generally ISPs, whose customers are primarily end users andpossibly other ISPs.2.5. AllocateTo allocate means to distribute address space to IRs for the purposeof subsequent distribution by them.2.6. AssignTo assign means to delegate address space to an ISP or end-user, forspecific use within the Internet infrastructure they operate.Assignments must only be made for specific purposes documented byspecific organizations and are not to be sub-assigned to otherparties.2.7. UtilizationUnlike IPv4, IPv6 is generally assigned to end sites in fixed amounts(/48). The actual usage of addresses within each assignment will bequite low, when compared to IPv4 assignments. In IPv6, "utilization"is only measured in terms of the bits to the left of the /48boundary. In other words, utilization refers to the assignment of/48s to end sites, and not the number of addresses assigned withinindividual /48s at those end sites.Throughout this document, the term utilization refers to theallocation of /48s to end sites, and not the number of addressesassigned within individual /48s within those end sites.2.8. HD-RatioThe HD-Ratio is a way of measuring the efficiency of addressassignment [RFC 3194]. It is an adaptation of the H-Ratio originallydefined in [RFC1715] and is expressed as follows:Log (number of allocated objects)HD = ------------------------------------------------Log (maximum number of allocatable objects)where (in the case of this document) the objects are IPv6 siteaddresses (/48s) assigned from an IPv6 prefix of a given size.2.9. End siteAn end site is defined as an end user (subscriber) who has a businessrelationship with a service provider that involves:- that service provider assigning address space to the end user- that service provider providing transit service for the end userto other sites- that service provider carrying the end user's traffic.- that service provider advertising an aggregate prefix route thatcontains the end user's assignment3. Goals of IPv6 address space management3.1. GoalsIPv6 address space is a public resource that must be managed in aprudent manner with regards to the long-term interests of theinternet. Responsible address space management involves balancing aset of sometimes competing goals. The following are the goalsrelevant to IPv6 address policy.3.2. UniquenessEvery assignment and/or allocation of address space must guaranteeuniqueness worldwide. This is an absolute requirement for ensuringthat every public host on the Internet can be uniquely identified.3.3. RegistrationInternet address space must be registered in a registry databaseaccessible to appropriate members of the Internet community. This isnecessary to ensure the uniqueness of each Internet address and toprovide reference information for Internet troubleshooting at alllevels, ranging from all RIRs and IRs to end users.The goal of registration should be applied within the context ofreasonable privacy considerations and applicable laws.3.4. AggregationWherever possible, address space should be distributed in ahierarchical manner, according to the topology of networkinfrastructure. This is necessary to permit the aggregation ofrouting information by ISPs, and to limit the expansion of Internetrouting tables.This goal is particularly important in IPv6 addressing, where thesize of the total address pool creates significant implications forboth internal and external routing.IPv6 address policies should seek to avoid fragmentation of addressranges.Further, RIRs should apply practices that maximize the potential forsubsequent allocations to be made contiguous with past allocationscurrently held. However, there can be no guarantee of contiguousallocation.3.5. ConservationAlthough IPv6 provides an extremely large pool of address space,address policies should avoid unnecessarily wasteful practices.Requests for address space should be supported by appropriatedocumentation and stockpiling of unused addresses should be avoided.3.6. FairnessAll policies and practices relating to the use of public addressspace should apply fairly and equitably to all existing and potentialmembers of the Internet community, regardless of their location,nationality, size or any other factor.3.7. Minimized OverheadIt is desirable to minimize the overhead associated with obtainingaddress space. Overhead includes the need to go back to RIRs foradditional space too frequently, the overhead associated withmanaging address space that grows through a number of smallsuccessive incremental expansions rather than through fewer, butlarger, expansions.3.8. Conflict of goalsThe goals described above will often conflict with each other, orwith the needs of individual IRs or end users. All IRs evaluatingrequests for allocations and assignments must make judgments, seekingto balance the needs of the applicant with the needs of the Internetcommunity as a whole.In IPv6 address policy, the goal of aggregation is considered to bethe most important.4. IPv6 Policy PrinciplesTo address the goals described in the previous section, the policiesin this document discuss and follow the basic principles describedbelow.4.1. Address space not to be considered propertyIt is contrary to the goals of this document and is not in theinterests of the Internet community as a whole for address space tobe considered freehold property.The policies in this document are based upon the understanding thatglobally-unique IPv6 unicast address space is licensed for use ratherthan owned. Specifically, IP addresses will be allocated andassigned on a license basis, with licenses subject to renewal on aperiodic basis. The granting of a license is subject to specificconditions applied at the start or renewal of the license.RIRs will generally renew licenses automatically, provided requestingorganizations are making a good-faith effort at meeting the criteriaunder which they qualified for or were granted an allocation orassignment. However, in those cases where a requesting organizationis not using the address space as intended, or is showing bad faithin following through on the associated obligation, RIRs reserve theright to not renew the license.Note that when a license is renewed, the new license will beevaluated under and governed by the applicable IPv6 address policiesin place at the time of renewal, which may differ from the policy inplace at the time of the original allocation or assignment.4.2. Routability not guaranteedThere is no guarantee that any address allocation or assignment willbe globally routable.However, RIRs must apply procedures that reduce the possibility offragmented address space which may lead to a loss of routability.4.3. Minimum AllocationRIRs will apply a minimum size for IPv6 allocations, to facilitateprefix-based filtering.The minimum allocation size for IPv6 address space is /32.4.4. Consideration of IPv4 InfrastructureWhere an existing IPv4 service provider requests IPv6 space foreventual transition of existing services to IPv6, the number ofpresent IPv4 customers may be used to justify a larger request thanwould be justified if based solely on the IPv6 infrastructure.5. Policies for allocations and assignments5.1. Initial allocation5.1.1. Initial allocation criteriaTo qualify for an initial allocation of IPv6 address space, anorganization must:a) be an LIR;b) not be an end site;c) plan to provide IPv6 connectivity to organizations to which itwill assign /48s, by advertising that connectivity through itssingle aggregated address allocation; andd) have a plan for making at least 200 /48 assignments to otherorganizations within two years.5.1.2. Initial allocation sizeOrganizations that meet the initial allocation criteria are eligibleto receive a minimum allocation of /32.Organizations may qualify for an initial allocation greater than /32by submitting documentation that reasonably justifies the request.If so, the allocation size will be based on the number of existingusers and the extent of the organization's infrastructure.5.2. Subsequent allocationOrganizations that hold an existing IPv6 allocation may receive asubsequent allocation in accordance with the following policies.5.2.1. Subsequent allocation criteriaSubsequent allocation will be provided when an organization (ISP/LIR)satisfies the evaluation threshold of past address utilization interms of the number of sites in units of /48 assignments. The HD-Ratio [RFC 3194] is used to determine the utilization thresholds thatjustify the allocation of additional address as described below.5.2.2. Applied HD-RatioThe HD-Ratio value of 0.8 is adopted as indicating an acceptableaddress utilization for justifying the allocation of additionaladdress space. Appendix A provides a table showing the number ofassignments that are necessary to achieve an acceptable utilizationvalue for a given address block size.5.2.3. Subsequent Allocation SizeWhen an organization has achieved an acceptable utilization for itsallocated address space, it is immediately eligible to obtain anadditional allocation that results in a doubling of the address spaceallocated to it. Where possible, the allocation will be made from anadjacent address block, meaning that its existing allocation isextended by one bit to the left.If an organization needs more address space, it must providedocumentation justifying its requirements for a two-year period. Theallocation made will be based on this requirement.5.3. LIR-to-ISP allocationThere is no specific policy for an organization (LIR) to allocateaddress space to subordinate ISPs. Each LIR organization may developits own policy for subordinate ISPs to encourage optimum utilizationof the total address block allocated to the LIR. However, all /48assignments to end sites are required to be registered either by theLIR or its subordinate ISPs in such a way that the RIR/NIR canproperly evaluate the HD-Ratio when a subsequent allocation becomesnecessary.5.4. AssignmentLIRs must make IPv6 assignments in accordance with the followingprovisions.5.4.1. Assignment address space sizeAssignments are to be made in accordance with the existing guidelines[RFC3177,RIRs-on-48], which are summarized here as:- /48 in the general case, except for very large subscribers- /64 when it is known that one and only one subnet is needed bydesign- /128 when it is absolutely known that one and only one device isconnecting.RIRs/NIRs are not concerned about which address size an LIR/ISPactually assigns. Accordingly, RIRs/NIRs will not request thedetailed information on IPv6 user networks as they did in IPv4,except for the cases described in Section 4.4 and for the purposes ofmeasuring utilization as defined in this document.5.4.2. Assignment of multiple /48s to a single end siteWhen a single end site requires an additional /48 address block, itmust request the assignment with documentation or materials thatjustify the request. Requests for multiple or additional /48s willbe processed and reviewed (i.e., evaluation of justification) at theRIR/NIR level.Note: There is no experience at the present time with the assignmentof multiple /48s to the same end site. Having the RIR review allsuch assignments is intended to be a temporary measure until someexperience has been gained and some common policies can be developed.In addition, additional work at defining policies in this space willlikely be carried out in the near future.5.4.3. Assignment to operator's infrastructureAn organization (ISP/LIR) may assign a /48 per PoP as the serviceinfrastructure of an IPv6 service operator. Each assignment to a PoPis regarded as one assignment regardless of the number of users usingthe PoP. A separate assignment can be obtained for the in-houseoperations of the operator.5.5. RegistrationWhen an organization holding an IPv6 address allocation makes IPv6address assignments, it must register assignment information in adatabase, accessible by RIRs as appropriate (information registeredby an RIR/NIR may be replaced by a distributed database forregistering address management information in future). Informationis registered in units of assigned /48 networks. When more than a/48 is assigned to an organization, the assigning organization isresponsible for ensuring that the address space is registered in anRIR/NIR database.RIR/NIRs will use registered data to calculate the HD-Ratio at thetime of application for subsequent allocation and to check forchanges in assignments over time.IRs shall maintain systems and practices that protect the security ofpersonal and commercial information that is used in requestevaluation, but which is not required for public registration.5.6. Reverse lookupWhen an RIR/NIR delegates IPv6 address space to an organization, italso delegates the responsibility to manage the reverse lookup zonethat corresponds to the allocated IPv6 address space. Eachorganization should properly manage its reverse lookup zone. Whenmaking an address assignment, the organization must delegate to anassignee organization, upon request, the responsibility to manage thereverse lookup zone that corresponds to the assigned address.5.7. Existing IPv6 address space holdersOrganizations that received /35 IPv6 allocations under the previousIPv6 address policy [RIRv6-Policies] are immediately entitled to havetheir allocation expanded to a /32 address block, without providingjustification, so long as they satisfy the criteria in Section 5.1.1.The /32 address block will contain the already allocated smalleraddress block (one or multiple /35 address blocks in many cases) thatwas already reserved by the RIR for a subsequent allocation to theorganization. Requests for additional space beyond the minimum /32size will be evaluated as discussed elsewhere in the document.6. References[RFC1715] "The H Ratio for Address Assignment Efficiency", C.Huitema.November 1994, RFC 1715.[IAB-Request] "Email from IAB to IANA",http://www.iab.org/iab/DOCUMENTS/IPv6addressspace.txt.[RFC2373] "IP Version 6 Addressing Architecture", R. Hinden, S.Deering. July 1998, RFC 2373.[RFC2373bis] draft-ietf-ipngwg-addr-arch-v3-07.txt.[RFC2928] "Initial IPv6 Sub-TLA ID Assignments", R. Hinden, S.Deering, R. Fink, T. Hain. September 2000, RFC 2928.[RFC3177] "IAB/IESG Recommendations on IPv6 Address". IAB, IESG.September 2001, RFC 3177.[RFC3194] "The H-Density Ratio for Address Assignment Efficiency AnUpdate on the H ratio", A. Durand, C. Huitema. November2001, RFC 3194.[RIRs-on-48]http://www.arin.net/library/guidelines/ipv6_initial.html,[RIRv6-Policies]http://www.arin.net/regserv/ipv6/ipv6guidelines.html,http://www.ripe.net/ripe/docs/ripe-196.html,http://www.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html.7. Appendix A: HD-RatioThe HD-Ratio is not intended to replace the traditional utilizationmeasurement that ISPs perform with IPv4 today. Indeed, the HD-Ratiostill requires counting the number of assigned objects. The primaryvalue of the HD-Ratio is its usefulness at determining reasonabletarget utilization threshold values for an address space of a givensize. This document uses the HD-Ratio to determine the thresholds atwhich a given allocation has achieved an acceptable level ofutilization and the assignment of additional address space becomesjustified.The utilization threshold T, expressed as a number of individual /48prefixes to be allocated from IPv6 prefix P, can be calculated as:((48-P)*HD)T = 2Thus, the utilization threshold for an organization requestingsubsequent allocation of IPv6 address block is specified as afunction of the prefix size and target HD ratio. This utilizationrefers to the allocation of /48s to end sites, and not theutilization of those /48s within those end sites. It is an addressallocation utilization ratio and not an address assignmentutilization ratio.In accordance with the recommendations of [RFC 3194], this documentadopts an HD-Ratio of 0.8 as the utilization threshold for IPv6address space allocations.The following table provides equivalent absolute and percentageaddress utilization figures for IPv6 prefixes, corresponding to anHD-Ratio of 0.8P 48-P Total /48s Threshold Util%48 0 1 1 100.0%47 1 2 2 87.1%46 2 4 3 75.8%45 3 8 5 66.0%44 4 16 9 57.4%43 5 32 16 50.0%42 6 64 28 43.5%41 7 128 49 37.9%40 8 256 84 33.0%39 9 512 147 28.7%38 10 1024 256 25.0%37 11 2048 446 21.8%36 12 4096 776 18.9%35 13 8192 1351 16.5%34 14 16384 2353 14.4%33 15 32768 4096 12.5%32 16 65536 7132 10.9%31 17 131072 12417 9.5%30 18 262144 21619 8.2%29 19 524288 37641 7.2%28 20 1048576 65536 6.3%27 21 2097152 114105 5.4%26 22 4194304 198668 4.7%25 23 8388608 345901 4.1%24 24 16777216 602249 3.6%23 25 33554432 1048576 3.1%22 26 67108864 1825677 2.7%21 27 134217728 3178688 2.4%20 28 268435456 5534417 2.1%19 29 536870912 9635980 1.8%18 30 1073741824 16777216 1.6%17 31 2147483648 29210830 1.4%16 32 4294967296 50859008 1.2%15 33 8589934592 88550677 1.0%14 34 17179869184 154175683 0.9%13 35 34359738368 268435456 0.8%12 36 68719476736 467373275 0.7%11 37 137438953472 813744135 0.6%10 38 274877906944 1416810831 0.5%9 39 549755813888 2466810934 0.4%8 40 1099511627776 4294967296 0.4%7 41 2199023255552 7477972398 0.3%6 42 4398046511104 13019906166 0.3%5 43 8796093022208 22668973294 0.3%4 44 17592186044416 39468974941 0.2%8. Appendix B: Background information8.1. BackgroundThe impetus for revising the 1999 Provisional IPv6 policy startedwith the APNIC meeting held in Taiwan in August 2001. Follow-ondiscussions were held at the October, 2001 RIPE and ARIN meetings.During these meetings, the participants recognized an urgent need formore detailed, complete policies. One result of the meetings was theestablishment of a single mailing list to discuss a revised policytogether with a desire to develop a general policy that all RIRscould use. This document does not provide details of individualdiscussions that lead to policies described in this document;detailed information can be found in the individual meeting minutesat the www.apnic.net, www.arin.net, and www.ripe.net web sites.8.2. Why a joint policyIPv6 addresses are a public resource that must be managed withconsideration to the long-term interests of the internet community.Although regional registries adopt allocation policies according totheir own internal processes, address policies should largely beuniform across registries. Having significantly varying policies indifferent regions is undesirable because it can lead to situationswhere "registry shopping" can occur as requesting organizationsrequest addresses from the registry that has the most favorablepolicy for their particular desires. This can lead to the policiesin one region undermining the efforts of registries in other regionswith regards to prudent stewardship of the address space. In caseswhere regional variations from the policy are deemed necessary, thepreferred approach is to raise the issue in the other regionalregistries in order to develop a consensus approach that allregistries can support.8.3. The size of IPv6's address spaceCompared to IPv4, IPv6 has a seemingly endless amount of addressspace. While superficially true, short-sighted and wastefulallocation policies could also result in the adoption of practicesthat lead to premature exhaustion of the address space.It should be noted that the 128-bit address space is divided intothree logical parts, with the usage of each component manageddifferently. The rightmost 64 bits, the Interface Identifier[RFC2373], will often be a globally-unique IEEE identifier (e.g., macaddress). Although an "inefficient" way to use the InterfaceIdentifier field from the perspective of maximizing the number ofaddressable nodes, the numbering scheme was explicitly chosen tosimplify Stateless Address Autoconfiguration [RFC2462].The middle 16 bits of an address indicate the subnet ID. Per [RFC3177, RIRs-on-48s], this field will often be inefficiently utilized,but the operational benefits of a consistent width subnet field weredeemed to be outweigh the drawbacks.The decisions to inefficiently utilize the bits to the right of /48were made under the knowledge and assumption that the bits to theleft of /48 would be managed prudently and that if done so, will beadequate for the expected lifetime of IPv6 [RFC3177].8.4. AcknowledgmentThe initial version of this document was produced by The JPNIC IPv6policy drafting team consisting of Akihiro Inomata, Akinori Maemura,Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, andToshiyuki Yamasaki. Special thanks goes out to this team, who workedover a holiday in order to produce an initial document quickly.An editing team was then organized by representatives from each ofthe three RIRs (Takashi Arano, Chair of APNIC's Policy SIG, ThomasNarten, Chair of ARIN's IPv6 WG, and David Kessens, Chair of RIPENCC's IPv6 WG).The editing team would like to acknowledge the contributions to thisdocument of Takashi Arano, John Crain, Steve Deering, Gert Doering,Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam Kuehne, AnneLord, Jun Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Dave Pratt,Stuart Prevost, Barbara Roseman, Gerard Ross, Paul Wilson, CathyWittbrodt and Wilfried Woeber.The final editing of this document was done by Thomas Narten.