Changes to IPv6 Sub-assignment Clarification
| Legend | (+) Added | (-) Deleted |
|---|---|---|
| Changed | Tag Added | Tag Deleted |
Summary of Proposal
Luckily insert: <strong> Preamble: insert: </strong> The primary focus of this proposal was the IPv6 PI related part of the address policy. During the development of the proposal, as we discussed various ideas on how to move forward in the process, the idea emerged to broaden the proposal’s scope. This would serve to clarify and thereby unify both the meaning of the terms “assignment” and “sub-assignment” and the rules associated with these processes. The proposal thus aims to fix the current IPv6 PI policy with respect to sub-assignments and unify the terms for PA and PI space. Given the primary focus on IPv6 PI, large parts of this rationale are based on thoughts about PI space. insert: </p>
insert: <p>Luckily, more and more people are (thinking about) deploying IPv6 in their networks. Some of these networks Of these, some may already have IPv4 PI assignments and are thereby already being be multi-homed and/or independent from one an entity providing upstream services – and wish to continue services. In such instances, a multi-homed setup would need to be continued for IPv6. Some In other instances, some may want to rethink old habits of IPv4 networking and start fresh, independent and multi-homed for IPv6. The community should encourage and support people who are doing so.
Today, Usually organisation networks usually today include some kind of guest networks, (public) WIFI hotspots hot-spots in their offices, PNI or PTP-VPN links to customers’ customers sites, or anything similar alike where devices of non-members of the organisation would get assigned an IP out of the organisation’s prefix. Strictly following the current RIPE policy regarding eligibility for IPv6 PI space, organisations aren't allowed to be provided with PI space when this is the case.
As a consequence, There are several consequences to all this: people may opt to postpone an IPv6 migration, IPv6 migration; they might be unspecific less specific or less honest when requesting IPv6 PI and answering the RIPE NCC’s questions, or related questions from the RIPE NCC; some might ask to become an LIR LIR, or ask an existing LIR for less flexible PA space and possibly encounter space, leading to potential problems with multi-homing. None of All these options courses of action are ideal. problematic and none of them represents the best solution. A strict interpretation of Section 2.6 of ripe-684 might even disallow the use of a PA assignment from an LIR for use in public WIFIs, etc.
As an example, some Freifunk Communities in Germany have been had their PI request declined PI space because some 1-digit-number of subnets would have been used as IPv6 prefixes on a v6 prefix in public WIFIs. This usage of the IP space in the End User’s an end-user’s infrastructure has been interpreted as a sub-assignment of a /128 prefix. This would have been "assigned" "(sub-)assigned" to a user device of within the public WIFI network as the device would get an IP address via SLAAC (or any other means means, for that matter).
This interpretation seems rather extreme and history shows that it's not even shared by every member of the RIPE NCC. As discussed in the AP-WG meeting, at the Address Policy WG during RIPE 72, RIPE72 and RIPE74, there have been some other Freifunk communities as well as others getting allocations for the same usage patters. patterns. Even the IPv6 prefixes used on the at RIPE72 to RIPE74 WIFI at RIPE 72 were ASSIGNED-PI. So had been ASSIGNED-PI – as the RIPE NCC cannot become a member of itself. As a result, there's currently there's an unequal treatment of people being honest and specific in what they want to do and those giving only high-level, incomplete, or even wrong answers to the RIPE NCC when requesting IPv6 PI.
Being more specific in the policy about what a sub-assignment is and setting it to a “/64 or shorter” Explicitly allowing another entity to be provided with addresses from a subnet operated by the assignment holder solves this problem in a simple way - for both IPv6 PI and PA assignments - and will help a number of (not only non-profit) organisations to smoothly design and set up independent and multi-homed IPv6 networks. Disallowing sub-assignments for “/64 or shorter” Sub-assignments for networks (= whole subnets) that are not under the control of the assignment holder are still not allowed, which will still prevent ISPs from using “cheap” PI space for their subscribers. delete: </p> delete: <p> A subnet in the spirit of this policy is a prefix from the PI/PA assignment with a prefix length of /64 or longer according to current IPv6 standards and BCPs. insert: </p>
insert: <p>Intended use cases for IPv6 PI space in the spirit of this policy proposal are the use in (public) WIFI networks (like the WIFI at RIPE meetings), as transfer networks on PNIs or other PTP-links/VPNs to users or customers, or for housing/hosting for servers in data centres. The use of IPv6 PI space for DSL/cable/FFTH/etc. subscribers is explicitly not an intended use case for this policy proposal.
Policy Text
a. Current policy text
delete: <h4> IPv6 Address Allocation and Assignment Policy delete: </h4>7. IPv6 Provider Independent (PI) Assignments 2.6. Assign
To qualify for IPv6 PI “assign” means to delegate address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”. delete: </p> delete: <p> The RIPE NCC will assign the prefix directly to the space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. delete: </p> delete: <p> [...] delete: </p> delete: <p> delete: </p> delete: <p> delete: </p> delete: <h4> Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region delete: </h4> delete: <h5> 2.0 Contractual Responsibilities of End Users and LIRs delete: </h5> delete: <p> [...] delete: </p> delete: <p> The details of any such contracts and are outside the scope of this document. delete: </p> delete: <p> However, at the minimum, all contracts must include: delete: </p> delete: <p> [...] delete: </p> delete: <p> * Notice that none of the provider independent resources may not to be sub-assigned to a third party delete: </p> other parties. insert: </p>
insert: <p>[…] insert: </p>
insert: <h4>7. IPv6 Provider Independent (PI) Assignments insert: </h4>
[...] insert: </p>
insert: <p>The PI assignment cannot be further assigned to other organisations.
b. New policy text
delete: <h4> IPv6 Address Allocation and Assignment Policy delete: </h4>7. IPv6 Provider Independent (PI) Assignments 2.6. Assign
To qualify for IPv6 PI “assign” means to delegate address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”. delete: </p> delete: <p> Within the context of these policies, a sub-assignment is an assignment of a length of /64 space to an ISP or shorter. delete: </p> delete: <p> The RIPE NCC will assign the prefix directly to the End User organisation upon a request properly submitted to the RIPE NCC, either directly for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. insert: </p>
insert: <p>Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or through a sponsoring LIR. delete: </p> appliance to an assignment holder's network and setting up point-to-point links with 3rd parties. insert: </p>
insert: <p>[…] insert: </p>
insert: <h4>7. IPv6 Provider Independent (PI) Assignments insert: </h4>
[...] insert: </p>
insert: <p>The PI assignment cannot be further sub-assigned to other organisations.
Rationale
a. Arguments supporting the proposal
With this clarification in place, place there will be no more room for interpretation regarding whether using PI space in (public) WIFIs or installations is alike will be in conflict with the policy. As a /64 is the smallest meaningful prefix length to use in non-PTP links, there should be no worries of people misusing PI space for sub-assigned customer prefixes.
This will even resolve some current policy violations – - depending on the interpretation of the current policy – - and avoid further ones regarding this that point. This may even help to further IPv6 deployment, deployment as there seem to be some people and / organisations who would like want to use IPv6 PI space but have been denied.
Although the IPv6 address space is huge, it's still finite. Users only needing a /48 (or less) for their organisations organisation would also block a full /29 prefix when forced to become LIRs. This LIR which seems unproportional. unproportioned.
b. Arguments opposing the proposal
The boundary of "/64 or shorter" has been chosen as this This proposal consciously opens up the allowed use cases for IPv6 PI space - the intention is the smallest meaningful prefix for IPv6. In theory, this policy change allows to spread IPv6 deployments. One could argue that some of the newly allowed use cases will prevent people to hand out /80 or smaller prefixes to their users/customers, but the risk of IPv6 PI misuse seems to be rather low here. Prefixes longer than a /64 are of no big use in reality and nobody in their right mind would use such a prefix for their paying users. from becoming an LIR which they should then providing hosting/housing services etc. This isn't considered a great risk.
Increasing the number of PI assignments probably will increase the number of entries in the global v6 routing table. Some people might worry about an increase in the table size in the foreseeable future. Not going forward with this policy change will likely result in people getting /48 / 48 to /40 sub-assignments from an LIR or maybe becoming LIRs themselves, become an LIR of their own resulting in at least the same number of routes, maybe even more (aggregate routes for the PA space + sub-assignments). assignments + TE prefixes e.g.).
insert: <a id="impact-analysis"> insert: </a> Impact Analysis
delete: <p> Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented. delete: </p>A. RIPE NCC's Understanding of the Proposed Policy
If this proposal is accepted, it is the RIPE NCC’s understanding that for IPv6 PI an IPv6 assignment, the provision of separate addresses to customers of the assignment requests, subnets in the addressing plan smaller than holder will not be considered a sub-assignment. In IPv6 terms, a single address is a /128. There are cases where a /64 will is needed per customer to provide a separate address, for instance by using dedicated (v)lans to connect Wifi customers or other configuration insert: <a href="https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-12"> mechanisms insert: </a> discussed in the technical community. The RIPE NCC will consider such mechanisms as being in line with this policy and not a sub-assignment as long as the subnet size does not exceed a /64. insert: </p>
insert: <p>It is the RIPE NCCs understanding that assignments as described above are dynamic in nature, either by varying the prefix or interface identifier (IID) over time. Any permanent and static assignments of a prefix would still be exempt from being considered sub-assignments. a sub-assignment as per clause 2.6, “Assign” of the IPv6 address allocation and assignment policy. Consequently the RIPE NCC will not provide IPv6 PI assignments for such deployment plans. insert: </p>
insert: <p> This definition of sub-assignments will apply for assignments within IPv6 allocations and for IPv6 Provider Independent (PI) Assignments. insert: <br />
While LIRs have to consider this definition when providing assignments, the RIPE NCC will apply this understanding during the evaluation of IPv6 PI requests and when reviewing assignments within allocations during a potential audit of an LIR.
The RIPE NCC has been receiving an increasing amount of IPv6 PI requests where an organisation plans to use IPv6 PI to provide connectivity or other services to End Users with a /128 or other small prefix for each customer. Users, by using single IPv6 addresses for End User devices and services. If this policy change is accepted, the RIPE NCC will provide IPv6 PI assignments to these requesters, provided no subnets of a /64 or larger prefixes will be provided to entities outside of the requesting organisation. delete: </p> delete: <p> While this other entities. insert: </p>
This policy change will likely help with the deployment of IPv6 for organisations that provide services to customers, some customers. Further this new proposal version addresses several side effects that would have occurred with the previous version. For example, there is no longer a difference between sub-assignment rules for PI assignments and assignments within allocations. The risk of conflicts with several RFCs has also been minimised. insert: </p>
insert: <p>It should be noted: delete: </p> delete: <ul> delete: <li> Several RFCs refer to a /64 as the minimum size per End Site ( delete: <a href="https://tools.ietf.org/html/rfc6177"> RFC6177 delete: </a> ) or as necessary for interface identifiers used noted that with the Global Unicast Address range ( delete: <a href="https://tools.ietf.org/html/rfc4291"> RFC4291 delete: </a> ). While the examples described in this proposal seem to be within these RFCs, the RIPE NCC would also need to accept requests that are in conflict with RFCs as long as the subnets to customers are not /64 or bigger. There is no requirement that RFCs match RIPE policies, however the RIPE community has traditionally aimed to keep these aligned and often uses RFCs for guidance. This policy change has the potential to increase the number of IPv6 deployments conflicting with RFCs. Assignments that are not in accordance with normative references, such as Standards Track RFCs, might be more difficult to implement technically by the End User. delete: </li> delete: <li> delete: <a href="../../../../../publications/docs/ripe-655#assignment_size"> Section 5.4.1 of the RIPE IPv6 policy delete: </a> mandates a /64 as the minimum assignment size per End Site within IPv6 allocations, while this policy change will make subnets smaller than a /64 per customer possible within IPv6 PI assignments. This difference might confuse organisations change, as with the current policy, there is still the risk that start with IPv6 PI and later go on to become LIRs and receive IPv6 allocations. delete: </li> delete: <li> In order to qualify for IPv6 PI assignments, organisations might assign subnet sizes per customer that later turn out to be too small for optimal use of the various IPv6 features. Alternatively, organisations the requesting party might provide incorrect information about the subnet size amount of IPv6 they actually plan to provide. delete: </li> delete: <li> provide to customers in order to receive IPv6 PI. insert: </p>
insert: <p> Further it is possible that, despite the intention of the proposer, broadband providers will request and receive IPv6 PI assignments as long they comply with the requirement to only provide separate addresses to customers. insert: <br />
To use an extreme example, even a broadband provider with millions of customers would qualify for an IPv6 PI assignment as long as he would follow the policy requirements. While the RIPE NCC cannot predict how many of such requests it will receive, there is the potential that broadband providers will provide too little IPv6 space to their customers, only to qualify for IPv6 PI assignment instead of using allocated address space. insert: <br />
The RIPE NCC would make any such requester aware that such IPv6 deployment is against IPv6 best current RIPE Database business rules prevent the creation of more specific objects under an object with the status “ASSIGNED PI”, therefore these small subnets used by customers of the requesting organisation cannot be documented in the RIPE Database. delete: </li> delete: </ul> practices and the intent of this policy change, but ultimately it could not deny such an IPv6 PI request. insert: </p>
B. Impact of Policy on Registry and Addressing System
If this proposal is accepted, organisations with services that include the provision of small amounts of IPv6 per customer separate IPv6 addresses to customers can request IPv6 PI, resulting in an expected increase of IPv6 PI assignments. Currently the RIPE NCC assigns around 250 IPv6 PI assignments per year, the vast majority of which are a /48. Some organisations that would become LIRs and request an IPv6 allocation (minimum size /32) under the current policy, might instead choose opt for an IPv6 PI assignment instead (minimum size /48). This would have a slowing effect on the overall IPv6 consumption rate.
Overall, the RIPE NCC estimates that neither of these effects will have a significant impact on the RIPE NCC IPv6 pool.
C. Impact of Policy on RIPE NCC Operations/Services Operations/Services
A faster processing of An increase of approved IPv6 PI requests is expected by Registration Services, as evaluation will focus on the requester’s documentation and the condition that no sub-assignments of /64 or bigger prefixes will be provided to other organisations.
The RIPE NCC might need to spend exert more effort during request evaluations, training and other outreach activities to explain the importance of sufficient subnet sizes for customers and the relevance of RFC recommendations for the deployment of IPv6. delete: </p> delete: <h4> Implementation delete: </h4> intent of this policy change and its limits. The examples mentioned in the policy text will help the RIPE NCC for their educational activities. insert: </p>
insert: <h3>D. Implementation insert: </h3>
With the information currently available, it is expected that implementation of the proposal would have a low impact in terms of the software development needed to facilitate the policy changes in internal RIPE NCC systems. Internal and external processes and documentation would also need to be updated.
How to read this draft document:
This document relates to the policy proposal 2016-04, “ IPv6 PI sub-assignment Sub-assignment clarification ”. If approved, it will modify ripe-655, ripe-684, “ delete: <a href="../../../../../resolveuid/1a389ad7cec44e179a5532c3fdff46b9" data-linktype="internal" data-val="1a389ad7cec44e179a5532c3fdff46b9"> Autonomous insert: <a href="../../../../../resolveuid/58ce5b148666476698a1888cd8373101" data-linktype="internal" data-val="58ce5b148666476698a1888cd8373101"> IPv6 Address Allocation and Assignment Policy ”.
To show you how the new document would be different to the old one, we have highlighted any new text or changes to the existing text.
We indicate changes to existing text in the document like this:
| ORIGINAL TEXT delete: </th> delete: <th> insert: </td> | insert: <td> NEW TEXT delete: </th> insert: </td> |
| The text from the current policy document that will be replaced is displayed here. | The proposed text change will be displayed here. |
Abstract
delete: <p class="WW-Default"> insert: <p>This document defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations. It was developed through joint discussions among the APNIC, ARIN and RIPE communities.
Contents Contents
1. Introduction
1.1. Overview
2. Definitions
2.1. Internet Registry (IR)
2.2. Regional Internet Registry (RIR)
2.3. National Internet Registry (NIR)
2.4. Local Internet Registry (LIR)
2.5. Allocate
2.6. Assign
2.7. Utilisation
2.8. HD-Ratio
2.9. End Site
3. Goals of IPv6 address space management
3.1. Goals
3.2. Uniqueness
3.3. Registration
3.4. Aggregation
3.5. Conservation
3.6. Fairness
3.7. Minimised Overhead
3.8. Conflict of Goals
4. IPv6 Policy Principles
4.1. Address space not to be considered property
4.2. Routability not guaranteed
4.3. Minimum Allocation
4.4. Consideration of IPv4 Infrastructure
5. Policies for allocations and assignments
5.1. Initial allocation delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.1.1. Initial allocation criteria delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.1.2. Initial allocation size delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.2. Subsequent allocation delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.2.1. Subsequent allocation criteria delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.2.2. Applied HD-Ratio delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.2.3. Subsequent Allocation Size delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.3. LIR-to-ISP allocation delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.4. Assignment delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.4.1. Assignment address space size delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.4.2. Assignments shorter than a /48 to a single End Site delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.4.3. Assignment to operator's infrastructure delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.5. Registration delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> delete: <br /> 5.6. Reverse lookup delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
5.7. Existing IPv6 address space holders delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
6. Anycasting TLD and Tier 0/1 ENUM Nameservers delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
7. IPv6 Provider Independent (PI) Assignments delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
7.1. IPv6 Provider Independent (PI) Assignments for LIRs delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
8. Transfer of IPv6 resources delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
9. References
10. Appendix A: HD-Ratio delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
11. Appendix B: Background information delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
11.1. Background delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
11.2. Why a joint policy? delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
11.3. The size of IPv6's address space delete: </a> delete: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack">
11.4. Acknowledgment
1. Introduction
1.1. Overview
delete: <p class="WW-Default"> insert: <p>This document describes policies for the allocation and assignment of globally unique Internet Protocol version 6 (IPv6) address space.
delete: <p class="WW-Default"> insert: <p>[ RFC 4291 ] designates 2000::/3 to be global unicast address space that the Internet Assigned Numbers Authority (IANA) may allocate to the RIRs. In accordance with [ RFC 4291 ], IANA allocated initial ranges of global unicast IPv6 address space from the 2000::/3 address block to the RIRs. This document concerns the initial and subsequent allocations of the 2000::/3 unicast address space, for which RIRs formulate allocation and assignment policies. All bits to the left of /64 are in scope.
delete: <p class="WW-Default"> insert: <p>This policy is subject to future review and potential revision, subject to continuing experience in the administration of IPv6.
2. Definitions
insert: <strong> [Note: insert: </em> insert: </strong> [Note: some of these definitions will be replaced by definitions insert: <em> some insert: </em> insert: </strong> insert: <strong> insert: <em> of insert: </em> insert: </strong> insert: <strong> insert: <em> these insert: </em> insert: </strong> insert: <strong> insert: <em> definitions insert: </em> insert: </strong> insert: <strong> insert: <em> will insert: </em> insert: </strong> insert: <strong> insert: <em> be insert: </em> insert: </strong> insert: <strong> insert: <em> replaced insert: </em> insert: </strong> insert: <strong> insert: <em> by insert: </em> insert: </strong> insert: <strong> insert: <em> definitions insert: </em> insert: </strong> insert: <strong> insert: <em> from other RIR Documents in order to be more consistent.] insert: </em> insert: <strong> insert: <em> other insert: </strong> insert: <strong> insert: <em> RIR insert: </em> insert: </strong> insert: <strong> insert: <em> documents insert: </em> insert: </strong> insert: <strong> insert: <em> in insert: </em> insert: </strong> insert: <strong> insert: <em> order insert: </em> insert: </strong> insert: <strong> insert: <em> to insert: </em> insert: </strong> insert: <strong> insert: <em> be insert: </em> insert: </strong> insert: <strong> insert: <em> more insert: </em> insert: </strong> insert: <strong> insert: <em> consistent.] insert: </em> insert: </strong>
The following terms and their definitions are of particular importance to the understanding of the goals, environment and policies described in this document.
delete: <p class="WW-Default"> insert: <p>Responsibility for management of IPv6 address spaces is distributed globally in accordance with the hierarchical structure shown below.
delete: <p class="WW-Default"> insert: <p>
2.1. Internet Registry (IR)
delete: <p class="WW-Default"> insert: <p>An Internet Registry is an organisation that is responsible for distributing IP address space to its members or customers and for registering those distributions. IRs are classified according to their primary function and territorial scope within the hierarchical structure depicted in the figure above.
2.2. Regional Internet Registry (RIR)
delete: <p class="WW-Default"> insert: <p>Regional Internet Registries are established and authorised by respective regional communities and recognised by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions.
2.3. National Internet Registry (NIR)
delete: <p class="WW-Default"> insert: <p>A National Internet Registry primarily allocates address space to its members or constituents, which are generally LIRs organised at a national level. NIRs exist mostly in the Asia Pacific region.
2.4. Local Internet Registry (LIR)
delete: <p class="WW-Default"> insert: <p>A Local Internet Registry is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs.
2.5. Allocate
delete: <p class="WW-Default"> insert: <p>To “allocate” means to distribute address space to IRs for the purpose of subsequent distribution by them.
insert: <table class="plain">2.7. Utilisation
delete: <p class="WW-Default"> insert: <p>The actual usage of addresses within each assignment may be low when compared to IPv4 assignments. In IPv6, "utilisation" is only measured in terms of the bits to the left of the efficiency measurement unit (/56). In other words, "utilisation" effectively refers to the assignment of network prefixes to End Sites and not the number of addresses assigned within individual End Site assignments.
delete: <p class="WW-Default"> insert: <p>Throughout this document, the term "utilisation" refers to the assignment of network prefixes to End Sites and not the number of addresses assigned within individual subnets within those End Sites.
2.8. HD-Ratio
delete: <p class="WW-Default"> insert: <p>The HD-Ratio is a way of measuring the efficiency of address assignment [ RFC 3194 ]. It is an adaptation of the H-Ratio originally defined in [ RFC 1715 ] and is expressed as follows:
Log (number of allocated objects)delete: <p class="WW-Default"> insert: <p>
HD = ----------------------------------------------
Log (maximum number of allocatable objects)
where (in the case of this document) the objects are IPv6 site addresses assigned from an IPv6 prefix of a given size.
2.9. End Site
delete: <p class="WW-Default"> insert: <p>An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) 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 User to other sites
- that service provider carrying the End User's traffic
- that service provider advertising an aggregate prefix route that contains the End User's assignment
3. Goals of IPv6 address space management
3.1. Goals
delete: <p class="WW-Default"> insert: <p>IPv6 address space is a public resource that must be managed in a prudent manner with regards to the long-term interests of the Internet. Responsible address space management involves balancing a set of sometimes competing goals. The following are the goals relevant to IPv6 address policy.
3.2. Uniqueness
delete: <p class="WW-Default"> insert: <p>Every assignment and/or allocation of address space must guarantee uniqueness worldwide. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified.
3.3. Registration
delete: <p class="WW-Default"> insert: <p>Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users.
delete: <p class="WW-Default"> insert: <p>The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws.
3.4. Aggregation
delete: <p class="WW-Default"> insert: <p>Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs and to limit the expansion of Internet routing tables.
delete: <p class="WW-Default"> insert: <p>This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing.
delete: <p class="WW-Default"> insert: <p>IPv6 address policies should seek to avoid fragmentation of address ranges.
delete: <p class="WW-Default"> insert: <p>Further, RIRs should apply practices that maximise the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation.
3.5. Conservation
delete: <p class="WW-Default"> insert: <p>Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided.
3.6. Fairness
delete: <p class="WW-Default"> insert: <p>All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size, or any other factor.
3.7. Minimised overhead
delete: <p class="WW-Default"> insert: <p>It is desirable to minimise the overhead associated with obtaining address space. Overhead includes the need to go back to RIRs for additional space too frequently, the overhead associated with managing address space that grows through a number of small successive incremental expansions rather than through fewer, but larger, expansions.
3.8. Conflict of goals
delete: <p class="WW-Default"> insert: <p>The goals described above will often conflict with each other, or with the needs of individual IRs or End Users. All IRs evaluating requests for allocations and assignments must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole.
delete: <p class="WW-Default"> insert: <p>In IPv6 address policy, the goal of aggregation is considered to be the most important.
4. IPv6 Policy Principles
delete: <p class="WW-Default"> insert: <p>To address the goals described in the previous section, the policies in this document discuss and follow the basic principles described below.
4.1. Address space not to be considered property
delete: <p class="WW-Default"> insert: <p>It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.
delete: <p class="WW-Default"> insert: <p>The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license.
delete: <p class="WW-Default"> insert: <p>RIRs will generally renew licenses automatically, provided requesting organisations are making a “good faith” effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organisation is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license. Note that when a license is renewed, the new license will be evaluated under and governed by the applicable IPv6 address policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment.
4.2. Routability not guaranteed
delete: <p class="WW-Default"> insert: <p>There is no guarantee that any address allocation or assignment will be globally routable.
delete: <p class="WW-Default"> insert: <p>However, RIRs must apply procedures that reduce the possibility of fragmented address space which may lead to a loss of routability.
4.3. Minimum allocation
delete: <p class="WW-Default"> insert: <p>The minimum allocation size for IPv6 address space is /32.
4.4. Consideration of IPv4 infrastructure
delete: <p class="WW-Default"> insert: <p>Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure.
5. Policies for Allocations and Assignments
5.1. Initial allocation
5.1.1. Initial allocation criteria
delete: <p class="WW-Default"> insert: <p>To qualify for an initial allocation of IPv6 address space, an organisation must:
delete: <p class="WW-Default"> insert: <p class="WW-Default" style="padding-left: 30px;">a) be an LIR;
delete: <p class="WW-Default"> insert: <p class="WW-Default" style="padding-left: 30px;">b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years.
5.1.2. Initial allocation size
Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary.
Organisations may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of the allocation.
5.2. Subsequent allocation
delete: <p class="WW-Default"> insert: <p>Organisations that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies.
5.2.1. Subsequent allocation criteria
delete: <p class="WW-Default"> insert: <p>Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies ISP/LIR): insert: </p>
insert: <p style="padding-left: 30px;"> a) Satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The /56. To this end, the HD-Ratio [ RFC 3194 ] is used to determine the utilisation thresholds that thresholds. insert: <br />
insert: <br />
or insert: </p>
b) Can justify the new needs (which can't be satisfied within the previous allocation), according to the initial allocation of additional address size criteria as described below. in section 5.1.2.
5.2.2. Applied HD-Ratio
delete: <p class="WW-Default"> insert: <p>The HD-Ratio value of 0.94 is adopted as indicating an acceptable address utilisation for justifying the allocation of additional address space. Appendix A provides a table showing the number of assignments that are necessary to achieve an acceptable utilisation value for a given address block size.
5.2.3. Subsequent allocation size
delete: <p class="WW-Default"> insert: <p>When an organisation has achieved an acceptable utilisation for its allocated address space, meets the subsequent allocation criteria, it is immediately eligible to obtain an additional allocation that results in a doubling of the address space allocated to it. Where possible, the allocation will be made from an adjacent address block, meaning that its existing allocation is extended by one bit to the left.
delete: <p class="WW-Default"> insert: <p>If an organisation needs more address space, it must provide documentation justifying its requirements for a two-year period. new requirements, as described in section 5.1.2. The allocation made will be based on this requirement. the relevant documentation. insert: </p>
insert: <p>
5.3. LIR-to-ISP allocation
delete: <p class="WW-Default"> insert: <p>There is no specific policy for an organisation (LIR) to allocate address space to subordinate ISPs. Each LIR organisation may develop its own policy for subordinate ISPs to encourage optimum utilisation of the total address block allocated to the LIR. However, all /48 assignments to End Sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary.
5.4. Assignment
delete: <p class="WW-Default"> insert: <p>LIRs must make IPv6 assignments in accordance with the following provisions.
5.4.1. Assignment address space size
delete: <p class="WW-Default"> insert: <p>End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site).
5.4.2. Assignments shorter than a /48 to a single End Site
delete: <p class="WW-Default"> insert: <p>When a single End Site requires an assignment shorter than a /48, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional prefixes exceeding a /48 assignment for a single End Site will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level.
delete: <p class="WW-Default"> insert: <p>Note: There is no experience at the present time with the assignment of multiple network prefixes to the same End Site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.
5.4.3. Assignment to operator's infrastructure
delete: <p class="WW-Default"> insert: <p>An organisation (i.e. ISP/LIR) may assign a network prefix per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator.
5.5 Registration
When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database.
These registrations can either be made as individual assignments or by inserting a object with a status value of 'AGGREGATED-BY-LIR' where the assignment-size attribute contains the size of the individual assignments made to End Users.When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED'.
In case of an audit or when making a request for a subsequent allocation, the LIR must be able to present statistics showing the number of individual assignments made in all objects with a status of 'AGGREGATED-BY-LIR' in such a way the RIR is able to calculate and verify the actual HD-ratio.
5.6. Reverse lookup
delete: <p class="WW-Default"> insert: <p>When an RIR/NIR delegates IPv6 address space to an organisation, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organisation should properly manage its reverse lookup zone. When making an address assignment, the organisation must delegate to an assignee organisation, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address.
5.7. Existing IPv6 address space holders
LIRs that hold one or more IPv6 allocations are able to request extension of each of these allocations up to a /29 without providing further documentation.
The RIPE NCC should allocate the new address space contiguously with the LIRs’ existing allocations and avoid allocating non-contiguous space under this policy section.
6. Anycasting TLD and Tier 0/1 ENUM Nameservers
The organisations applicable under this policy are TLD managers, as recorded in the IANA's Root Zone Database and ENUM administrators, as assigned by the ITU. The organisation may receive up to four /48 prefixes per TLD and four /48 prefixes per ENUM. These prefixes must be used for the sole purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in BCP126/ RFC 4786 .
Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled " Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region ".
Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for infrastructure providing authoritative TLD or ENUM Tier 0/1 DNS lookup services any longer.
delete: <table class="plain"> delete: <colgroup> delete: <col width="50%"> delete: <col width="50%"> delete: </colgroup> delete: <tbody> delete: <tr> delete: <td>7. IPv6 Provider Independent (PI) Assignments
delete: <p class="WW-Default"> insert: <p>To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “ delete: <a href="../../../../../resolveuid/43d2336a361c4c6f8394cd6146943e84" data-linktype="internal" data-val="43d2336a361c4c6f8394cd6146943e84"> insert: <a href="http://www.ripe.net/ripe/docs/contract-req"> Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region ”.
delete: <p class="WW-Default"> insert: <p>The RIPE NCC will assign the prefix directly to the End User organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR.
delete: <p class="WW-Default"> insert: <p>The minimum size of the assignment is a /48. Organisations requesting a larger assignment (shorter prefix) must provide documentation justifying the need for additional subnets.
delete: <p class="WW-Default"> insert: <p>Additional assignments may also be made when the need is demonstrated and documented based on address usage, or because different routing requirements exist for additional assignments. When possible, these further assignments will be made from an adjacent address block.
delete: <p class="WW-Default"> insert: <p>Assignments will be made from a separate 'designated block' to facilitate filtering practices.
delete: <p class="WW-Default"> insert: <table class="plain">| insert: <p> The PI assignment cannot be further assigned to other organisations. delete: </td> delete: <td> delete: <h2> 7. IPv6 Provider Independent (PI) Assignments delete: </h2> delete: <p class="WW-Default"> To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “ delete: <a href="../../../../../resolveuid/43d2336a361c4c6f8394cd6146943e84" data-linktype="internal" data-val="43d2336a361c4c6f8394cd6146943e84"> Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region delete: </a> ”. delete: </p> delete: <p> delete: <span class="newdifftext"> Within the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter. delete: </span> delete: </p> delete: <p class="WW-Default"> The RIPE NCC will assign the prefix directly to the End User organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. delete: </p> delete: <p class="WW-Default"> The minimum size of the assignment is a /48. Organisations requesting a larger assignment (shorter prefix) must provide documentation justifying the need for additional subnets. delete: </p> delete: <p class="WW-Default"> Additional assignments may also be made when the need is demonstrated and documented based on address usage, or because different routing requirements exist for additional assignments. When possible, these further assignments will be made from an adjacent address block. delete: </p> delete: <p class="WW-Default"> Assignments will be made from a separate 'designated block' to facilitate filtering practices. delete: </p> delete: <p class="WW-Default"> insert: </td> | insert: <td> insert: <p> The PI assignment cannot be further assigned insert: <span class="newdifftext"> sub-assigned insert: </span> to other organisations. |
insert: </p>
7.1 IPv6 Provider Independent (PI) Assignments for LIRs
delete: <p class="WW-Default"> insert: <p>LIRs can qualify for an IPv6 PI assignment for parts of their own infrastructure that are not used for customer end sites. Where an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment.
delete: <p class="WW-Default"> insert: <p>The LIR should return the IPv6 PI assignment within a period of six months if the original criteria on which the assignment was based are no longer valid.
8. Transfer of IPv6 resources
delete: <div class="page" title="Page 10"> delete: <div class="section"> delete: <div class="layoutArea"> delete: <div class="column"> delete: <p> Any holder of IPv6 address space insert: <p>The transfer of Internet number resources is allowed to transfer complete or partial blocks of IPv6 address space that were previously allocated or assigned to them governed by the RIPE NCC or otherwise through the Regional Internet Registry system. delete: </p> delete: <p> Address space may only be re-allocated to another LIR that is also a member of the RIPE NCC. The block that is to be re-allocated must not be smaller than the minimum allocation size at the time of re-allocation. delete: </p> delete: <p> Provider Independent (PI) address space may only be re-assigned in accordance with the RIPE Document, “ delete: <a class="internal-link" title="" href="resolveuid/43d2336a361c4c6f8394cd6146943e84" target="_self" data-linktype="internal" data-val="43d2336a361c4c6f8394cd6146943e84"> Contractual Requirements for Provider Independent " insert: <a href="http://www.ripe.net/publications/docs/transfer-policies" data-val="http://www.ripe.net/publications/docs/transfer-policies" data-linktype="external"> RIPE Resource Holders in the RIPE NCC Service Region delete: </a> ”. The block that is to be re-assigned must not be smaller than the minimum assignment block size at the time of re-assignment. delete: </p> delete: <p> Transfers must be reflected in the RIPE Database. This transfer may be on either a permanent or non-permanent basis. delete: </p> delete: <p> The RIPE NCC will record the change of address space after the transfer. delete: </p> delete: <p> The RIPE NCC will publish a list of all allocations and assignments transferred under this section. The publication shall occur on monthly basis or more frequently if the RIPE NCC so chooses. delete: </p> delete: <p> The list will contain information about approved and non-approved transfers. The following information will be published for approved transfers: delete: </p> delete: <ul> delete: <li> delete: <p> The name of the transferring party delete: </p> delete: </li> delete: <li> delete: <p> The block originally held by the transferring party delete: </p> delete: </li> delete: <li> delete: <p> The name(s) of the receiving party or parties delete: </p> delete: </li> delete: <li> delete: <p> Each subdivided prefix (each partial block derived from that original block) transferred delete: </p> delete: </li> delete: <li> The date each prefix was transferred delete: </li> delete: </ul> delete: <p> Non-approved transfers will be published in an aggregate statistics. In the statistics the following information will be published: delete: </p> delete: <ul> delete: <li> delete: <p> The number of requested transfers not approved after the RIPE NCC’s evaluation delete: </p> delete: </li> delete: <li> delete: <p> The sum of the number of addresses included in the requested transfers delete: </p> delete: <p> Neither the blocks nor the organisations involved will be identified in these statistics. delete: </p> delete: </li> delete: </ul> delete: </div> delete: </div> delete: </div> delete: </div> delete: <div class="page" title="Page 11"> delete: <div class="section"> delete: <div class="layoutArea"> delete: <div class="column"> delete: <p> The transferring party always remains responsible for the entire address block it receives from the RIPE NCC until the transfer of address space to another party is completed or the address space is returned. The transferring party must ensure that all policies are applied. delete: </p> delete: <p> Transferred address blocks are no different from the allocations or assignments made directly by the RIPE NCC and so they must be used by the receiving party according to the policies described in this document. delete: </p> delete: </div> delete: </div> delete: </div> delete: </div> delete: <p class="WW-Default"> Transfer Policies insert: </a> ".
9. References
delete: <p class="WW-Default"> insert: <p>[RFC 1715] "The H Ratio for Address Assignment Efficiency", C. Huitema. November 1994, ftp://ftp.ripe.net/rfc/rfc1715.txt
delete: <p class="WW-Default"> insert: <p>[RFC 2026] "The Internet Standards Process -- Revision 3 IETF Experimental RFC ftp://ftp.ripe.net/rfc/rfc2026.txt see Sec. 4.2.1
delete: <p class="WW-Default"> insert: <p>[RFC 2462] "IPv6 Stateless Address Autoconfiguration", S. Thomson, T. Narten, 1998, ftp://ftp.ripe.net/rfc/rfc2462.txt
delete: <p class="WW-Default"> insert: <p>[RFC 4291] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. February 2006, ftp://ftp.ripe.net/rfc/rfc4291.txt
delete: <p class="WW-Default"> insert: <p>[RFC 2928] "Initial IPv6 Sub-TLA ID Assignments", R. Hinden, S. Deering, R. Fink, T. Hain. September 2000 ftp://ftp.ripe.net/rfc/rfc2928.txt
delete: <p class="WW-Default"> insert: <p>[RFC 3194] "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", A. Durand, C. Huitema. November 2001, ftp://ftp.ripe.net/rfc/rfc3194.txt
delete: <p class="WW-Default"> insert: <p>[RFC 4291] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. February 2006, ftp://ftp.ripe.net/rfc/rfc4291.txt
delete: <p class="WW-Default"> insert: <p>[RFC 4786] "Operation of Anycast Services", J. Abley, K. Lindqvist. December 2006, ftp://ftp.ripe.net/rfc/rfc4786.txt
10. Appendix A: HD-Ratio
delete: <p class="WW-Default"> insert: <p>The utilisation threshold T, expressed as a number of individual /56 prefixes to be allocated from IPv6 prefix P, can be calculated as:
T = 2 ((56-P)*HD)
delete: <p class="WW-Default"> insert: <p>Thus, the utilisation threshold for an organisation requesting subsequent allocation of IPv6 address block is specified as a function of the prefix size and target HD ratio. This utilisation refers to the use of /56s as an efficiency measurement unit, and does not refer to the utilisation of addresses within those End Sites. It is an address allocation utilisation ratio and not an address assignment utilisation ratio.
delete: <p class="WW-Default"> insert: <p>In accordance with the recommendations of [ RFC 3194 ], this document adopts an HD-Ratio of 0.94 as the utilisation threshold for IPv6 address space allocations.
delete: <p class="WW-Default"> insert: <p>The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.94.
delete: <p class="WW-Default"> insert: <p>
| Prefix | Total /56s | /56s HD 0.94 | Util % |
| 10 | 70368744177664 | 10388121308479 | 14.76 |
| 11 | 35184372088832 | 5414630391777 | 15.39 |
| 12 | 17592186044416 | 2822283395519 | 16.04 |
| 13 | 8796093022208 | 1471066903609 | 16.72 |
| 14 | 4398046511104 | 766768439460 | 17.43 |
| 15 | 2199023255552 | 399664922315 | 18.17 |
| 16 | 1099511627776 | 208318498661 | 18.95 |
| 17 | 549755813888 | 108582451102 | 19.75 |
| 18 | 274877906944 | 56596743751 | 20.59 |
| 19 | 137438953472 | 29500083768 | 21.46 |
| 20 | 68719476736 | 15376413635 | 22.38 |
| 21 | 34359738368 | 8014692369 | 23.33 |
| 22 | 17179869184 | 4177521189 | 24.32 |
| 23 | 8589934592 | 2177461403 | 25.35 |
| 24 | 4294967296 | 1134964479 | 26.43 |
| 25 | 2147483648 | 591580804 | 27.55 |
| 26 | 1073741824 | 308351367 | 28.72 |
| 27 | 536870912 | 160722871 | 29.94 |
| 28 | 268435456 | 83774045 | 31.21 |
| 29 | 134217728 | 43665787 | 32.53 |
| 30 | 67108864 | 22760044 | 33.92 |
| 31 | 33554432 | 11863283 | 35.36 |
| 32 | 16777216 | 6183533 | 36.86 |
11. Appendix B: Background information
11.1. Background
delete: <p class="WW-Default"> insert: <p>The impetus for revising the 1999 provisional IPv6 policy started with the APNIC meeting held in Taiwan in August 2001. Follow-on discussions were held at the October 2001 RIPE and ARIN meetings. During these meetings, the participants recognised an urgent need for more detailed, complete policies. One result of the meetings was the establishment of a single mailing list to discuss a revised policy together with a desire to develop a general policy that all RIRs could use. This document does not provide details of individual discussions that lead to policies described in this document; detailed information can be found in the individual meeting minutes at the www.apnic.net, www.arin.net, and www.ripe.net web sites.
delete: <p class="WW-Default"> insert: <p>In September 2002 at the RIPE 43 Meeting in Rhodes, Greece, the RIPE community approved the policy allowing Internet experiments to receive temporary assignments. As a result, Section 6 was added to this document in January 2003.
11.2. Why a joint policy?
delete: <p class="WW-Default"> insert: <p>IPv6 addresses are a public resource that must be managed with consideration to the long-term interests of the Internet community. Although regional registries adopt allocation policies according to their own internal processes, address policies should largely be uniform across registries. Having significantly varying policies in different regions is undesirable because it can lead to situations where "registry shopping" can occur as requesting organisations request addresses from the registry that has the most favorable policy for their particular desires. This can lead to the policies in one region undermining the efforts of registries in other regions with regards to prudent stewardship of the address space. In cases where regional variations from the policy are deemed necessary, the preferred approach is to raise the issue in the other regional registries in order to develop a consensus approach that all registries can support.
11.3. The size of IPv6's address space
delete: <p class="WW-Default"> insert: <p>Compared to IPv4, IPv6 has a seemingly endless amount of address space. While superficially true, short-sighted and wasteful allocation policies could also result in the adoption of practices that lead to premature exhaustion of the address space.
delete: <p class="WW-Default"> insert: <p>It should be noted that the 128-bit address space is divided into three logical parts, with the usage of each component managed differently. The rightmost 64 bits, the Interface Identifier [RFC 4291], will often be a globally unique IEEE identifier (e.g., mac address). Although an "inefficient" way to use the Interface Identifier field from the perspective of maximizing the number of addressable nodes, the numbering scheme was explicitly chosen to simplify Stateless Address Autoconfiguration [ RFC 2462 ].
delete: <p class="WW-Default"> insert: <p>The middle bits of an address indicate the subnet ID. This field may often be inefficiently utilised, but the operational benefits of a consistent width subnet field were deemed to be outweigh the drawbacks. This is a variable length field, determined by each LIR's local assignment policy.
delete: <h3 class="WW-Default"> delete: <strong> insert: <h3>delete: <a name="ack" data-val="c60d8c3d36f6d062befd7f2f9cfc03b1" data-linktype="internal"> delete: </a> 11.4. delete: </strong> delete: <strong> delete: </strong> delete: <strong> Acknowledgment delete: </strong>
delete: <p class="WW-Default"> insert: <p>The initial version of this document was produced by the JPNIC IPv6 policy drafting team consisting of Akihiro Inomata, Akinori Maemura, Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and Toshiyuki Yamasaki. Special thanks goes out to this team, who worked over a holiday in order to produce an initial document quickly.
delete: <p class="WW-Default"> insert: <p>An editing team was then organised by representatives from each of the three RIRs (Takashi Arano, Chair of APNIC's Policy SIG, Thomas Narten, Chair of ARIN's IPv6 WG, and David Kessens, Chair of the RIPE IPv6 Working Group).
The editing team would like to acknowledge the contributions to this document of Takashi Arano, John Crain, Steve Deering, Gert Doering, Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam Kuehne, Anne Lord, Jun Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Dave Pratt, Stuart Prevost, Barbara Roseman, Gerard Ross, Paul Wilson, Cathy Wittbrodt and Wilfried Woeber.
The final editing of the initial version of this document was done by Thomas Narten.