You are here: Home > Participate > Policy Development > Policy Proposals > Extension of the Minimum Size for IPv6 Initial Allocation

Changes to Extension of the Minimum Size for IPv6 Initial Allocation

Legend (+) Added (-) Deleted
Changed Tag Added Tag Deleted

delete: <b> insert: <strong> This proposal modifies the eligibility for an organisation to receive an initial IPv6 allocation up to a /29. This is in order to enable small LIRs to deploy IPv6 using “IPv6 Rapid Deployment”, also known as  “6rd”, as defined in RFC 5969 in a manner that does not encourage issuing a single /64 to end customers when an LIR has a minimum allocation of /32. delete: </b> insert: </strong>

delete: <b> Summary of proposal delete: </b> proposal:

delete: <span> This proposal modifies the eligibility for an organisation to receive an initial IPv6 allocation up to a /29. This is delete: </span> delete: <span> in order to enable small LIRs to deploy IPv6 using “IPv6 Rapid Deployment”, also known as “6rd”, as defined in RFC 5969 in a manner that does not encourage issuing a single /64 to end customers when an LIR has a minimum allocation of /32. delete: </span> delete: </p> delete: <p> delete: <span> insert: </p>

insert: <p>

This proposal also facilitates small LIRs that currently will only qualify for a /32 but may require a bigger allocation for an appropriate addressing plan that considers using bits in order to identify areas within their networks, fulfilling the aggregation vs conservation goal of IPv6 allocation policies. delete: </span> delete: </p> delete: <p> delete: <span> insert: </p>

insert: <p>

If this proposal reaches consensus, the RIPE NCC will expand up to a /29 all the delete: </span> delete: <span> /32 IPv6 address blocks allocated under the previous IPv6 address policy without providing further justification as long as they satisfy the criteria in section 5.1.1 of the RIPE policy document “IPv6 Address Allocation and Assignment Policy”. delete: </span> delete: </p> delete: <p> delete: <span> insert: </p>

insert: <p>

The extended address block will contain the already allocated smaller address block (one or multiple /32 address blocks in many cases) since it was already reserved for a subsequent allocation. Requests for additional space beyond the /29 size will be evaluated as discussed elsewhere in the same policy document. delete: </span> insert: <br />
insert: <br />

delete: <b> Policy text delete: </b> text:

Current

[Following text is to be modified from the RIPE Policy Document “ delete: </i> delete: <a class="external-link" href="../../../docs/ipv6-policies"> delete: <i> delete: <span> insert: <a class="external-link" href="http://www.ripe.net/docs/ipv6-policies"> IPv6 Address Allocation and Assignment Policy delete: </span> delete: </i> delete: <i> ”, if the proposal reaches consensus. This would result in a new policy section. section.] delete: <i> ] delete: </i> delete: </p> delete: <h4 class="western"> insert: </p>

insert: <h3>

5.1.2. Initial allocation size delete: </h4> insert: </h3>

Organisations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32. delete: </p> delete: <p> insert: <br />
Organisations may qualify for an initial allocation greater than /32 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure.

delete: <p> delete: <i> [Following text is to be removed from the RIPE Policy Document “ delete: </i> delete: <a class="external-link" href="../../../docs/ipv6-policies"> delete: <i> delete: <span> IPv6 Address Allocation and Assignment Policy delete: </span> delete: </i> delete: </a> delete: <i> ”, if the proposal reaches consensus.] delete: </i> delete: </p> delete: <h3 class="western"> insert: <h3>

5.7. Existing IPv6 address space holders

Organisations that received /35 IPv6 allocations under the previous IPv6 address policy are immediately entitled to have their allocation expanded to a /32 address block without providing justification so long as they satisfy the criteria in Section 5.1.1. delete: </p> delete: <p> insert: <br />
The /32 address block will contain the already allocated smaller address block (one or multiple /35 address blocks in many cases) that was already reserved by the RIR for a subsequent allocation to the organisation. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in the document.

insert: <br />
New

[Following text will replace the part of the RIPE Policy Document “ delete: </i> delete: <a class="external-link" href="../../../docs/ipv6-policies"> delete: <i> delete: <span> insert: <a class="external-link" href="http://www.ripe.net/docs/ipv6-policies"> IPv6 Address Allocation and Assignment Policy delete: </span> delete: </i> delete: <i> ”, if the proposal reaches consensus.] insert: <br />

delete: <h4 class="western"> insert: <h3>

5.1.2. Initial allocation size delete: </h4> delete: <p> delete: <span> insert: </h3>

insert: <p>

Organisations that meet the initial allocation criteria are eligible to receive an initial allocation of resources from /32 to /29, depending on what initial size they request. delete: </span> /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 existing users and the extent of the organisation's infrastructure.

insert: <h3>

5.7. Existing IPv6 allocation holders insert: </h3>

insert: <p>

LIRs that hold one or more IPv6 Allocations are able to request extension of these allocations up to a total of a /29 without providing further documentation. insert: </p>

insert: <p>

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. insert: <br />
insert: <br />
insert: </p>

delete: <b> Rationale delete: </b>

a. Arguments supporting the proposal

6rd is currently in operation and at the time of this writing is responsible for the largest IPv6-enabled residential broadband Internet service in the RIPE region and the world. The success of 6rd the initial deployments of 6rd has led to many ISPs and operators including it in their deployment plans.

6rd allows an operator to deploy IPv6 alongside IPv4 without updating operational and access infrastructure. There are a vast number of DSLAMs and aggregation equipment that has been installed, will not be replaced or changed for years, and do not support IPv6. 6RD 6rd is a viable way for ISPs to offer their customers production quality IPv6 service without redesigning and replacing existing infrastructure.

delete: <span> Unlike traditional “hub and spoke” tunnelling approaches, 6RD 6rd maps an existing IPv4 address into the upper 64 bits of an IPv6 prefix. While 6rd allows for more efficient mapping, the simplest operationally incorporates the full 32 bits of an IPv4 address into the IPv6 prefix. Given the default minimum /32 IPv6 allocation size available to all operators, it is very temping tempting to utilize the simplest mapping mode and deploy IPv6 via 6rd within a /32 by mapping the 32 bits of an IPv4 address and automatically assigning a 64 bit prefix to each user. In order for the operator to assign a shorter prefix to users, either a more complicated mapping algorithm must be used (increasing operational overhead), or more IPv6 space is needed. A /29 prefix allows, for example, a /30 prefix for a 6RD 6rd domain which, after mapping of 32 bits of IPv4, allows a /62 prefix to each subscriber. A /62 prefix in turn allows for four distinct /64 subnets in the home. The remaining /30 prefix that comes with the /29 can then be used for native deployment of IPv6 in core, services, or native IPv6 deployement. While 4 subnets in the home is not ideal, it is vastly superior to a single /64 which requires CPE manufacturers to limit themselves to a single bridged LAN in the home or development of IPv6 NAT. delete: </span> delete: </p> delete: <p> delete: <span> L delete: </span> delete: <span> egacy insert: <br />
Legacy /32 allocations were allocated with a /29 of “reserved for future expansion” space in mind and can very easily be expanded within that /29. As such, a move from /32 to /29 does not impact negatively RIPE NCC, nor will it lead to discrimination among existing allocations. As the reserved space is already present and would not be allocated to anyone else other than the holder of the /32 already allocated, it seems reasonable to go ahead and let LIRs use the full /29 of space if they need it. delete: </span> delete: </p> delete: <p> delete: <span> insert: </p>

insert: <p>

During early discussions in the community, there was objection to calling out 6RD 6rd specifically within our policy due to the possibility of various negative side effects, however unintended. Counter-arguments to this view argued that special-treatment for a standards track IETF protocol with a proven record of success was a high enough bar to not invite a long list of other special cases and that the negative side effects would not appear. In any case, the proposal of allowing /29 for those who ask for it contained herein seems to be a workable compromise for individuals on both sides of this argument. delete: </span> delete: </p> delete: <p> insert: <br />
insert: <br />
b. Arguments opposing the proposal

There is concern from some that allowing a /29 for the asking is a waste of space vs. the current /32 minimum allocation policy. Also, there are opponents to 6rd, suggesting that making IPv6 more readily deployable via 6rd will delay deployment of native IPv6.

insert: <p>

  insert: </p>

insert: <h3>

Impact Analysis: insert: </h3>

insert: <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. insert: </p>

insert: <h3>

A. RIPE NCC's Understanding of the Proposed Policy insert: </h3>

insert: <p>

This proposal defines the size of the initial IPv6 allocation LIRs can receive. If this proposal will be implemented, LIRs currently eligible for a /32 will be eligible for up to a /29. insert: </p>

insert: <p>

LIRs currently holding IPv6 address space allocations will be eligible to expand their allocated space to a total of /29. insert: </p>

insert: <h3>

B. Impact of Policy on Registry and Addressing System insert: </h3>

insert: <p>

insert: <b> Address/Internet Number Resource Consumption: insert: </b> insert: <br />
It is theoretically possible that the total IPv6 address space allocated will increase to a maximum of 8 times. However, after analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented. insert: </p>

insert: <p>

insert: <b> Fragmentation/Aggregation: insert: </b> insert: <br />
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented. insert: </p>

insert: <h3>

C. Impact of Policy on RIPE NCC Operations/Services insert: </h3>

insert: <p>

insert: <b> Registration Services: insert: </b> insert: <br />
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented. insert: </p>

insert: <p>

insert: <b> Billing/Finance Department: insert: </b> insert: <br />
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented. insert: </p>

insert: <p>

insert: <b> RIPE Database: insert: </b> insert: <br />
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented. insert: </p>

insert: <h3>

D. Legal Impact of Policy insert: </h3>

insert: <p>

After analysing the data that is currently available, the RIPE NCC does not anticipate that the implementation of this proposed policy will cause any significant legal implications. insert: </p>

insert: <h2 class="western">

How to read this draft document: insert: </h2>

insert: <p>

  insert: </p>

insert: <p>

This document relates to the of RIPE policy proposal 2011-04, “ insert: <a class="internal-link" href="resolveuid/f8b461a2da217ca9900341658705b02e" data-val="f8b461a2da217ca9900341658705b02e" data-linktype="internal"> Extension of the minimum size for IPv6 Initial Allocation insert: </a> insert: <i> insert: </i> . If approved, it will modify insert: <a class="external-link" href="http://www.ripe.net/ripe/docs/ipv6-policies"> ripe-545 insert: </a> insert: <i> insert: </i> . 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. insert: </p>

insert: <h3 class="western">

insert: <b> We indicate additions to the document like this: insert: </b> insert: </h3>

insert: <p>

  insert: </p>

insert: <table class="listing grid"> insert: <colgroup>insert: <col width="276" />insert: <col width="270" />insert: </colgroup>insert: <tbody>insert: <tr>insert: <td>insert: <td>insert: </tr>insert: </tbody>insert: </table>
insert: <p align="CENTER">

insert: <b> ADDITION TO DOCUMENT >> insert: </b> insert: </p>

insert: </td>
insert: <p align="CENTER">

The new text is shown here in blue insert: </p>

insert: </td>
insert: <h3 class="western">

We indicate changes to existing text in the document like this: insert: </h3>

insert: <p>

  insert: </p>

insert: <table class="listing grid"> insert: <colgroup>insert: <col width="276" />insert: <col width="270" />insert: </colgroup>insert: <tbody>insert: <tr>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: </tr>insert: </tbody>insert: </table>
insert: <p align="CENTER">

insert: <b> ORIGINAL TEXT insert: </b> insert: </p>

insert: </td>
insert: <p align="CENTER">

insert: <b> NEW TEXT insert: </b> insert: </p>

insert: </td>
insert: <p>

The text from the current policy document that will be replaced is displayed here. insert: </p>

insert: </td>
insert: <p>

The proposed new text will be displayed here. insert: </p>

insert: </td>
insert: <p>

  insert: </p>

insert: <p>

All other text in the document will not be replaced. insert: </p>

insert: <p>

  insert: </p>

insert: <hr />
insert: <h2 class="western">

Abstract insert: </h2>

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. insert: </p>

insert: <hr />
insert: <h2 class="western">

Contents insert: </h2>

insert: <p>

insert: <a href="#intro"> 1. Introduction insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#overview"> 1.1. Overview insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#definitions"> 2. Definitions insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a class="anchor-link" href="#ir"> 2.1. Internet Registry (IR) insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#rir"> 2.2. Regional Internet Registry (RIR) insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#nir"> 2.3. National Internet Registry (NIR) insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#lir"> 2.4. Local Internet Registry (LIR) insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#allocate"> 2.5. Allocate insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#assign"> 2.6. Assign insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#utilisation"> 2.7. Utilisation insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#hd_ratio"> 2.8. HD-Ratio insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#end_site"> 2.9. End Site insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#3"> 3. Goals of IPv6 address space management insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#goals"> 3.1. Goals insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#uniqueness"> 3.2. Uniqueness insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#registration"> 3.3. Registration insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#aggregation"> 3.4. Aggregation insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#conservation"> 3.5. Conservation insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#fairness"> 3.6. Fairness insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#overhead"> 3.7. Minimised Overhead insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#conflict"> 3.8. Conflict of Goals insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#4"> 4. IPv6 Policy Principles insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#property"> 4.1. Address space not to be considered property insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#routability"> 4.2. Routability not guaranteed insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#minimum_allocation"> 4.3. Minimum Allocation insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#ipv4_infrastructure"> 4.4. Consideration of IPv4 Infrastructure insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#5"> 5. Policies for allocations and assignments insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#initial_allocation"> 5.1. Initial allocation insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#initial_criteria"> 5.1.1. Initial allocation criteria insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#initial_size"> 5.1.2. Initial allocation size insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#subsequent_allocation"> 5.2. Subsequent allocation insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#subsequent_criteria"> 5.2.1. Subsequent allocation criteria insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#applied_hd_ratio"> 5.2.2. Applied HD-Ratio insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#subsequent_size"> 5.2.3. Subsequent Allocation Size insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#lir_to_isp"> 5.3. LIR-to-ISP allocation insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#assignment"> 5.4. Assignment insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#assignment_size"> 5.4.1. Assignment address space size insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#assignments_shorter"> 5.4.2. Assignments shorter than a /48 to a single End Site insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#assignment_infra"> 5.4.3. Assignment to operator's infrastructure insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#registration_assignment"> 5.5. Registration insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#reverse"> 5.6. Reverse lookup insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#existing"> 5.7. Existing IPv6 address space holders insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#anycasting"> 6. Anycasting TLD and Tier 0/1 ENUM Nameservers insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#IPv6_PI_Assignments"> 7. IPv6 Provider Independent (PI) Assignments insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#IPv6_PI_Assignments_LIR"> 7.1. IPv6 Provider Independent (PI) Assignments for LIRs insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#references"> 8. References insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#appendixA"> 9. Appendix A: HD-Ratio insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#appendixB"> 10. Appendix B: Background information insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#background"> 10.1. Background insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#why_joint_policy"> 10.2. Why a joint policy? insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#size_ipv6_space"> 10.3. The size of IPv6's address space insert: </a> insert: <a href="http://test-www.ripe.net/ripe/docs/ripe-388.html#ack"> insert: <br />
insert: </a>
insert: <a href="#ack"> 10.4. Acknowledgment insert: </a> insert: </p>

insert: <p>

  insert: </p>

insert: <h2 class="western">

insert: <a name="intro"> insert: </a> 1. Introduction insert: </h2>

insert: <h3 class="western">

insert: <a name="overview"> insert: </a> 1.1. Overview insert: </h3>

insert: <p>

This document describes policies for the allocation and assignment of globally unique Internet Protocol version 6 (IPv6) address space. insert: </p>

insert: <p>

[ insert: <a href="#references"> RFC 4291 insert: </a> ] 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. insert: </p>

insert: <p>

This policy is subject to future review and potential revision, subject to continuing experience in the administration of IPv6. insert: </p>

insert: <p>

  insert: </p>

insert: <h2 class="western">

insert: <a name="definitions"> insert: </a> 2. Definitions insert: </h2>

insert: <p>

insert: <i> insert: <b> [Note: insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> some insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> of insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> these insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> definitions insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> will insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> be insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> replaced insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> by insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> definitions insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> from insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> other insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> RIR insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> documents insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> in insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> order insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> to insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> be insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> more insert: </b> insert: </i> insert: <i> insert: <b> insert: </b> insert: </i> insert: <i> insert: <b> consistent.] insert: </b> insert: </i> insert: </p>

insert: <p>

The following terms and their definitions are of particular importance to the understanding of the goals, environment and policies described in this document. insert: </p>

insert: <p>

Responsibility for management of IPv6 address spaces is distributed globally in accordance with the hierarchical structure shown below. insert: </p>

insert: <p>

insert: <img class="image-inline" src="resolveuid/c60d8c3d36f6d062befd7f2f9cfc03b1" /> insert: </p>

insert: <p>

  insert: </p>

insert: <h3 class="western">

insert: <a name="ir"> insert: </a> 2.1. Internet Registry (IR) insert: </h3>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="rir1"> insert: </a> 2.2. Regional Internet Registry (RIR) insert: </h3>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="nir1"> insert: </a> 2.3. National Internet Registry (NIR) insert: </h3>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="lir"> insert: </a> 2.4. Local Internet Registry (LIR) insert: </h3>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="allocate"> insert: </a> 2.5. Allocate insert: </h3>

insert: <p>

To “allocate” means to distribute address space to IRs for the purpose of subsequent distribution by them. insert: </p>

insert: <h3 class="western">

insert: <a name="assign"> insert: </a> 2.6. Assign insert: </h3>

insert: <p>

To “assign” means to delegate address 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 and are not to be sub-assigned to other parties. insert: </p>

insert: <h3 class="western">

insert: <a name="utilisation"> insert: </a> 2.7. Utilisation insert: </h3>

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. insert: </p>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="hd_ratio"> insert: </a> 2.8. HD-Ratio insert: </h3>

insert: <p>

The HD-Ratio is a way of measuring the efficiency of address assignment [ insert: <a href="#references"> RFC 3194 insert: </a> ]. It is an adaptation of the H-Ratio originally defined in [ insert: <a href="#references"> RFC1715 insert: </a> ] and is expressed as follows: insert: </p>

insert: <pre>
 Log (number of allocated objects)  insert: <br /> 
HD = ---------------------------------------------- insert: <br />
Log (maximum number of allocatable objects) insert: </pre>
insert: <p>

where (in the case of this document) the objects are IPv6 site addresses assigned from an IPv6 prefix of a given size. insert: </p>

insert: <h3 class="western">

insert: <a name="end_site"> insert: </a> 2.9. End Site insert: </h3>

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: insert: </p>

insert: <ul>
    insert: <li>
  • insert: <p>

    that service provider assigning address space to the End User insert: </p>

    insert: </li>
  • insert: <li>
  • insert: <p>

    that service provider providing transit service for the End User to other sites insert: </p>

    insert: </li>
  • insert: <li>
  • insert: <p>

    that service provider carrying the End User's traffic insert: </p>

    insert: </li>
  • insert: <li>
  • insert: <p>

    that service provider advertising an aggregate prefix route that contains the End User's assignment insert: </p>

    insert: </li>
  • insert: </ul>
insert: <h2 class="western">

insert: <a name="3"> insert: </a> 3. Goals of IPv6 address space management insert: </h2>

insert: <h3 class="western">

insert: <a name="goals"> insert: </a> 3.1. Goals insert: </h3>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="uniqueness"> insert: </a> 3.2. Uniqueness insert: </h3>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="registration"> insert: </a> 3.3. Registration insert: </h3>

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. insert: </p>

insert: <p>

The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws. insert: </p>

insert: <h3 class="western">

insert: <a name="aggregation"> insert: </a> 3.4. Aggregation insert: </h3>

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. insert: </p>

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. insert: </p>

insert: <p>

IPv6 address policies should seek to avoid fragmentation of address ranges. insert: </p>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="conservation"> insert: </a> 3.5. Conservation insert: </h3>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="fairness"> insert: </a> 3.6. Fairness insert: </h3>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="overhead"> insert: </a> 3.7. Minimised overhead insert: </h3>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="conflict"> insert: </a> insert: <a name="conflicts"> insert: </a> 3.8. Conflict of goals insert: </h3>

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. insert: </p>

insert: <p>

In IPv6 address policy, the goal of aggregation is considered to be the most important. insert: </p>

insert: <h2 class="western">

insert: <a name="4"> insert: </a> 4. IPv6 Policy Principles insert: </h2>

insert: <p>

To address the goals described in the previous section, the policies in this document discuss and follow the basic principles described below. insert: </p>

insert: <h3 class="western">

insert: <a name="property"> insert: </a> 4.1. Address space not to be considered property insert: </h3>

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. insert: </p>

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. insert: </p>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="routability"> insert: </a> 4.2. Routability not guaranteed insert: </h3>

insert: <p>

There is no guarantee that any address allocation or assignment will be globally routable. insert: </p>

insert: <p>

However, RIRs must apply procedures that reduce the possibility of fragmented address space which may lead to a loss of routability. insert: </p>

insert: <h3 class="western">

insert: <a name="minimum_allocation"> insert: </a> 4.3. Minimum allocation insert: </h3>

insert: <p>

The minimum allocation size for IPv6 address space is /32. insert: </p>

insert: <h3 class="western">

insert: <a name="ipv4_infrastructure"> insert: </a> 4.4. Consideration of IPv4 infrastructure insert: </h3>

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. insert: </p>

insert: <p>

  insert: </p>

insert: <h2 class="western">

insert: <a name="5"> insert: </a> 5. Policies for Allocations and Assignments insert: </h2>

insert: <h3 class="western">

insert: <a name="initial_allocation"> insert: </a> 5.1. Initial allocation insert: </h3>

insert: <h4 class="western">

insert: <a name="initial_criteria"> insert: </a> 5.1.1. Initial allocation criteria insert: </h4>

insert: <p>

To qualify for an initial allocation of IPv6 address space, an organisation must: insert: </p>

insert: <p>

a) be an LIR; insert: </p>

insert: <p>

b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years. insert: </p>

insert: <p>

insert: <br />
insert: <br />
insert: </p>

insert: <table class="listing grid"> insert: <colgroup>insert: <col width="276" />insert: <col width="270" />insert: </colgroup>insert: <tbody>insert: <tr>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: </tr>insert: </tbody>insert: </table>
insert: <p align="CENTER">

insert: <b> ORIGINAL TEXT insert: </b> insert: </p>

insert: </td>
insert: <p align="CENTER">

insert: <b> NEW TEXT insert: </b> insert: </p>

insert: </td>
insert: <h4 class="western">

5.1.2. Initial allocation size insert: </h4>

insert: <p>

Organisations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32. insert: </p>

insert: <p>

Organisations may qualify for an initial allocation greater than /32 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of existing users and the extent of the organisation's infrastructure. insert: </p>

insert: </td>
insert: <h4 class="western">

5.1.2. Initial allocation size insert: </h4>

insert: <p>

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. insert: </p>

insert: <p>

  insert: </p>

insert: <p>

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 existing users and the extent of the organisation's infrastructure. insert: </p>

insert: </td>
insert: <p>

  insert: </p>

insert: <h3 class="western">

insert: <a name="subsequent_allocation"> insert: </a> 5.2. Subsequent allocation insert: </h3>

insert: <p>

Organisations that hold an existing IPv6 allocation may receive a subsequent allocation in accordance with the following policies. insert: </p>

insert: <h4 class="western">

insert: <a name="subsequent_criteria"> insert: </a> 5.2.1. Subsequent allocation criteria insert: </h4>

insert: <p>

Subsequent allocation will be provided when an organisation (i.e. ISP/LIR) satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments. The HD-Ratio [ insert: <a href="#references"> RFC 3194 insert: </a> ] is used to determine the utilisation thresholds that justify the allocation of additional address as described below. insert: </p>

insert: <h4 class="western">

insert: <a name="applied_hd_ratio"> insert: </a> 5.2.2. Applied HD-Ratio insert: </h4>

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. insert: </p>

insert: <h4 class="western">

insert: <a name="subsequent_size"> insert: </a> 5.2.3. Subsequent allocation size insert: </h4>

insert: <p>

When an organisation has achieved an acceptable utilisation for its allocated address space, 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. insert: </p>

insert: <p>

If an organisation needs more address space, it must provide documentation justifying its requirements for a two-year period. The allocation made will be based on this requirement. insert: </p>

insert: <h3 class="western">

insert: <a name="lir_to_isp"> insert: </a> 5.3. LIR-to-ISP allocation insert: </h3>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="assignment"> insert: </a> 5.4. Assignment insert: </h3>

insert: <p>

LIRs must make IPv6 assignments in accordance with the following provisions. insert: </p>

insert: <h4 class="western">

insert: <a name="assignment_size"> insert: </a> 5.4.1. Assignment address space size insert: </h4>

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). insert: </p>

insert: <h4 class="western">

insert: <a name="assignments_shorter"> insert: </a> 5.4.2. Assignments shorter than a /48 to a single End Site insert: </h4>

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. insert: </p>

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. insert: </p>

insert: <h4 class="western">

insert: <a name="assignment_infra"> insert: </a> 5.4.3. Assignment to operator's infrastructure insert: </h4>

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. insert: </p>

insert: <h3>

insert: <a name="registration_assignment"> insert: </a> 5.5 Registration insert: </h3>

insert: <p>

When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database. insert: </p>

insert: <p>

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'. insert: </p>

insert: <p>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="reverse"> insert: </a> 5.6. Reverse lookup insert: </h3>

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. insert: </p>

insert: <p>

insert: <br />
insert: <br />
insert: </p>

insert: <table class="listing grid"> insert: <colgroup>insert: <col width="276" />insert: <col width="270" />insert: </colgroup>insert: <tbody>insert: <tr>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: </tr>insert: </tbody>insert: </table>
insert: <p align="CENTER">

insert: <b> ORIGINAL TEXT insert: </b> insert: </p>

insert: </td>
insert: <p align="CENTER">

insert: <b> NEW TEXT insert: </b> insert: </p>

insert: </td>
insert: <h3 class="western">

5.7. Existing IPv6 address space holders insert: </h3>

insert: <p>

  insert: </p>

insert: <p>

Organisations that received /35 IPv6 allocations under the previous IPv6 address policy are immediately entitled to have their allocation expanded to a /32 address block without providing justification so long as they satisfy the criteria in Section 5.1.1. insert: </p>

insert: <p>

The /32 address block will contain the already allocated smaller address block (one or multiple /35 address blocks in many cases) that was already reserved by the RIR for a subsequent allocation to the organisation. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in the document. insert: </p>

insert: </td>
insert: <h3 class="western">

insert: <span> 5.7. insert: </span> insert: <span> Existing insert: </span> insert: <span> insert: </span> insert: <span> IPv6 insert: </span> insert: <span> insert: </span> insert: <span> address insert: </span> insert: <span> insert: </span> insert: <span> space insert: </span> insert: <span> insert: </span> insert: <span> holders insert: </span> insert: </h3>

insert: <p>

  insert: </p>

insert: <p>

LIRs that hold one or more IPv6 allocations are able to request extension of these allocations up to a total of a /29 without providing further documentation. insert: </p>

insert: <p>

  insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

  insert: </p>

insert: <p>

  insert: </p>

insert: <p>

  insert: </p>

insert: <p>

  insert: </p>

insert: </td>
insert: <h2 class="western">

insert: <a name="anycasting"> insert: </a> 6. Anycasting TLD and Tier 0/1 ENUM Nameservers insert: </h2>

insert: <p>

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/ insert: <a href="#references"> RFC4786 insert: </a> . insert: </p>

insert: <p>

Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled " insert: <a href="http://www.ripe.net/ripe/docs/contract-req"> Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region insert: </a> ". insert: </p>

insert: <p>

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. insert: </p>

insert: <h2 class="western">

insert: <a name="IPv6_PI_Assignments"> insert: </a> 7. IPv6 Provider Independent (PI) Assignments insert: </h2>

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 “ insert: <a href="http://www.ripe.net/ripe/docs/contract-req"> Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region insert: </a> ”. insert: </p>

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. insert: </p>

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. insert: </p>

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. insert: </p>

insert: <p>

Assignments will be made from a separate 'designated block' to facilitate filtering practices. insert: </p>

insert: <p>

The PI assignment cannot be further assigned to other organisations. insert: </p>

insert: <h3 class="western">

insert: <a name="IPv6_PI_Assignments_LIR"> insert: </a> 7.1 IPv6 Provider Independent (PI) Assignments for LIRs insert: </h3>

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. insert: </p>

insert: <p>

The LIR must 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. insert: </p>

insert: <p>

If an organisation already received a PI assignment before becoming an LIR, the PI assignment should be returned upon receiving an IPv6 allocation if there are no specific routing requirements to justify both. insert: </p>

insert: <h2 class="western">

insert: <a name="references"> insert: </a> 8. References insert: </h2>

insert: <p>

[RFC 1715] "The H Ratio for Address Assignment Efficiency", C. Huitema. November 1994, insert: <a href="ftp://ftp.ripe.net/rfc/rfc1715.txt"> ftp://ftp.ripe.net/rfc/rfc1715.txt insert: </a> . insert: </p>

insert: <p>

[RFC 2026] "The Internet Standards Process -- Revision 3 IETF Experimental RFC insert: <a href="ftp://ftp.ripe.net/rfc/rfc2026.txt"> ftp://ftp.ripe.net/rfc/rfc2026.txt insert: </a> see Sec. 4.2.1 insert: </p>

insert: <p>

[RFC 2462] "IPv6 Stateless Address Autoconfiguration", S. Thomson, T. Narten, 1998, insert: <a href="ftp://ftp.ripe.net/rfc/rfc2462.txt"> ftp://ftp.ripe.net/rfc/rfc2462.txt insert: </a> insert: </p>

insert: <p>

[RFC 4291] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. February 2006, insert: <a href="ftp://ftp.ripe.net/rfc/rfc4291.txt"> ftp://ftp.ripe.net/rfc/rfc4291.txt insert: </a> insert: </p>

insert: <p>

[RFC 2928] "Initial IPv6 Sub-TLA ID Assignments", R. Hinden, S. Deering, R. Fink, T. Hain. September 2000 insert: <a href="ftp://ftp.ripe.net/rfc/rfc2928.txt"> ftp://ftp.ripe.net/rfc/rfc2928.txt insert: </a> insert: </p>

insert: <p>

[RFC 3194] "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", A. Durand, C. Huitema. November 2001, insert: <a href="ftp://ftp.ripe.net/rfc/rfc3194.txt"> ftp://ftp.ripe.net/rfc/rfc3194.txt insert: </a> insert: </p>

insert: <p>

[RFC 4291] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. February 2006, insert: <a href="ftp://ftp.ripe.net/rfc/rfc4291.txt"> ftp://ftp.ripe.net/rfc/rfc4291.txt insert: </a> insert: </p>

insert: <p>

[RFC 4786] "Operation of Anycast Services", J. Abley, K. Lindqvist. December 2006, insert: <a href="ftp://ftp.ripe.net/rfc/rfc4786.txt"> ftp://ftp.ripe.net/rfc/rfc4786.txt insert: </a> insert: </p>

insert: <h2 class="western">

insert: <a name="appendixA"> insert: </a> 9. Appendix A: HD-Ratio insert: </h2>

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: insert: </p>

insert: <dl>
insert: <dd class="western">
T = 2 insert: <sup> ((56-P)*HD) insert: </sup> insert: </dd>
insert: </dl>
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. insert: </p>

insert: <p>

In accordance with the recommendations of [ insert: <a href="#references"> RFC 3194 insert: </a> ], this document adopts an HD-Ratio of 0.94 as the utilisation threshold for IPv6 address space allocations. insert: </p>

insert: <p>

The following table provides equivalent absolute and percentage address utilisation figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.94. insert: </p>

insert: <p>

  insert: </p>

insert: <table class="listing grid"> insert: <colgroup>insert: <col width="71" />insert: <col width="146" />insert: <col width="146" />insert: <col width="127" />insert: </colgroup>insert: <tbody>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: <tr>insert: <td>insert: <td>insert: <td>insert: <td>insert: </tr>insert: </tbody>insert: </table>
insert: <p align="CENTER">

insert: <b> Prefix insert: </b> insert: </p>

insert: </td>
insert: <p align="CENTER">

insert: <b> Total /56s insert: </b> insert: </p>

insert: </td>
insert: <p align="CENTER">

insert: <b> /56s HD 0.94 insert: </b> insert: </p>

insert: </td>
insert: <p align="CENTER">

insert: <b> Util % insert: </b> insert: </p>

insert: </td>
insert: <p align="RIGHT">

10 insert: </p>

insert: </td>
insert: <p align="RIGHT">

70368744177664 insert: </p>

insert: </td>
insert: <p align="RIGHT">

10388121308479 insert: </p>

insert: </td>
insert: <p align="RIGHT">

14.76 insert: </p>

insert: </td>
insert: <p align="RIGHT">

11 insert: </p>

insert: </td>
insert: <p align="RIGHT">

35184372088832 insert: </p>

insert: </td>
insert: <p align="RIGHT">

5414630391777 insert: </p>

insert: </td>
insert: <p align="RIGHT">

15.39 insert: </p>

insert: </td>
insert: <p align="RIGHT">

12 insert: </p>

insert: </td>
insert: <p align="RIGHT">

17592186044416 insert: </p>

insert: </td>
insert: <p align="RIGHT">

2822283395519 insert: </p>

insert: </td>
insert: <p align="RIGHT">

16.04 insert: </p>

insert: </td>
insert: <p align="RIGHT">

13 insert: </p>

insert: </td>
insert: <p align="RIGHT">

8796093022208 insert: </p>

insert: </td>
insert: <p align="RIGHT">

1471066903609 insert: </p>

insert: </td>
insert: <p align="RIGHT">

16.72 insert: </p>

insert: </td>
insert: <p align="RIGHT">

14 insert: </p>

insert: </td>
insert: <p align="RIGHT">

4398046511104 insert: </p>

insert: </td>
insert: <p align="RIGHT">

766768439460 insert: </p>

insert: </td>
insert: <p align="RIGHT">

17.43 insert: </p>

insert: </td>
insert: <p align="RIGHT">

15 insert: </p>

insert: </td>
insert: <p align="RIGHT">

2199023255552 insert: </p>

insert: </td>
insert: <p align="RIGHT">

399664922315 insert: </p>

insert: </td>
insert: <p align="RIGHT">

18.17 insert: </p>

insert: </td>
insert: <p align="RIGHT">

16 insert: </p>

insert: </td>
insert: <p align="RIGHT">

1099511627776 insert: </p>

insert: </td>
insert: <p align="RIGHT">

208318498661 insert: </p>

insert: </td>
insert: <p align="RIGHT">

18.95 insert: </p>

insert: </td>
insert: <p align="RIGHT">

17 insert: </p>

insert: </td>
insert: <p align="RIGHT">

549755813888 insert: </p>

insert: </td>
insert: <p align="RIGHT">

108582451102 insert: </p>

insert: </td>
insert: <p align="RIGHT">

19.75 insert: </p>

insert: </td>
insert: <p align="RIGHT">

18 insert: </p>

insert: </td>
insert: <p align="RIGHT">

274877906944 insert: </p>

insert: </td>
insert: <p align="RIGHT">

56596743751 insert: </p>

insert: </td>
insert: <p align="RIGHT">

20.59 insert: </p>

insert: </td>
insert: <p align="RIGHT">

19 insert: </p>

insert: </td>
insert: <p align="RIGHT">

137438953472 insert: </p>

insert: </td>
insert: <p align="RIGHT">

29500083768 insert: </p>

insert: </td>
insert: <p align="RIGHT">

21.46 insert: </p>

insert: </td>
insert: <p align="RIGHT">

20 insert: </p>

insert: </td>
insert: <p align="RIGHT">

68719476736 insert: </p>

insert: </td>
insert: <p align="RIGHT">

15376413635 insert: </p>

insert: </td>
insert: <p align="RIGHT">

22.38 insert: </p>

insert: </td>
insert: <p align="RIGHT">

21 insert: </p>

insert: </td>
insert: <p align="RIGHT">

34359738368 insert: </p>

insert: </td>
insert: <p align="RIGHT">

8014692369 insert: </p>

insert: </td>
insert: <p align="RIGHT">

23.33 insert: </p>

insert: </td>
insert: <p align="RIGHT">

22 insert: </p>

insert: </td>
insert: <p align="RIGHT">

17179869184 insert: </p>

insert: </td>
insert: <p align="RIGHT">

4177521189 insert: </p>

insert: </td>
insert: <p align="RIGHT">

24.32 insert: </p>

insert: </td>
insert: <p align="RIGHT">

23 insert: </p>

insert: </td>
insert: <p align="RIGHT">

8589934592 insert: </p>

insert: </td>
insert: <p align="RIGHT">

2177461403 insert: </p>

insert: </td>
insert: <p align="RIGHT">

25.35 insert: </p>

insert: </td>
insert: <p align="RIGHT">

24 insert: </p>

insert: </td>
insert: <p align="RIGHT">

4294967296 insert: </p>

insert: </td>
insert: <p align="RIGHT">

1134964479 insert: </p>

insert: </td>
insert: <p align="RIGHT">

26.43 insert: </p>

insert: </td>
insert: <p align="RIGHT">

25 insert: </p>

insert: </td>
insert: <p align="RIGHT">

2147483648 insert: </p>

insert: </td>
insert: <p align="RIGHT">

591580804 insert: </p>

insert: </td>
insert: <p align="RIGHT">

27.55 insert: </p>

insert: </td>
insert: <p align="RIGHT">

26 insert: </p>

insert: </td>
insert: <p align="RIGHT">

1073741824 insert: </p>

insert: </td>
insert: <p align="RIGHT">

308351367 insert: </p>

insert: </td>
insert: <p align="RIGHT">

28.72 insert: </p>

insert: </td>
insert: <p align="RIGHT">

27 insert: </p>

insert: </td>
insert: <p align="RIGHT">

536870912 insert: </p>

insert: </td>
insert: <p align="RIGHT">

160722871 insert: </p>

insert: </td>
insert: <p align="RIGHT">

29.94 insert: </p>

insert: </td>
insert: <p align="RIGHT">

28 insert: </p>

insert: </td>
insert: <p align="RIGHT">

268435456 insert: </p>

insert: </td>
insert: <p align="RIGHT">

83774045 insert: </p>

insert: </td>
insert: <p align="RIGHT">

31.21 insert: </p>

insert: </td>
insert: <p align="RIGHT">

29 insert: </p>

insert: </td>
insert: <p align="RIGHT">

134217728 insert: </p>

insert: </td>
insert: <p align="RIGHT">

43665787 insert: </p>

insert: </td>
insert: <p align="RIGHT">

32.53 insert: </p>

insert: </td>
insert: <p align="RIGHT">

30 insert: </p>

insert: </td>
insert: <p align="RIGHT">

67108864 insert: </p>

insert: </td>
insert: <p align="RIGHT">

22760044 insert: </p>

insert: </td>
insert: <p align="RIGHT">

33.92 insert: </p>

insert: </td>
insert: <p align="RIGHT">

31 insert: </p>

insert: </td>
insert: <p align="RIGHT">

33554432 insert: </p>

insert: </td>
insert: <p align="RIGHT">

11863283 insert: </p>

insert: </td>
insert: <p align="RIGHT">

35.36 insert: </p>

insert: </td>
insert: <p align="RIGHT">

32 insert: </p>

insert: </td>
insert: <p align="RIGHT">

16777216 insert: </p>

insert: </td>
insert: <p align="RIGHT">

6183533 insert: </p>

insert: </td>
insert: <p align="RIGHT">

36.86 insert: </p>

insert: </td>
insert: <h2 class="western">

insert: <a name="appendixB"> insert: </a> 10. Appendix B: Background information insert: </h2>

insert: <h3 class="western">

insert: <a name="background"> insert: </a> 10.1. Background insert: </h3>

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. insert: </p>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="why_joint_policy"> insert: </a> 10.2. Why a joint policy? insert: </h3>

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. insert: </p>

insert: <h3 class="western">

insert: <a name="size_ipv6_space"> insert: </a> 10.3. The size of IPv6's address space insert: </h3>

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. insert: </p>

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 [RFC4291], 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 [ insert: <a href="#references"> RFC2462 insert: </a> ]. insert: </p>

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. insert: </p>

insert: <h3>

insert: <a name="ack" data-val="c60d8c3d36f6d062befd7f2f9cfc03b1" data-linktype="internal"> insert: </a> 10.4. Acknowledgment insert: </h3>

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. insert: </p>

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). insert: </p>

insert: <p>

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. insert: </p>

insert: <p>

The final editing of the initial version of this document was done by Thomas Narten. insert: </p>

DRAFT: IPv6 Address Allocation and Assignment Policy
Get Involved

The Address Policy Working Group develops policies relating to the allocation and registration of Internet number resources (IPv4 and IPv6 addresses and ASNs) by the RIPE NCC and its members. Anyone with an interest in Internet numbering issues is welcome to observe, participate and contribute to the WG. To post a message to the list, send an email to address-policy-wg@ripe.net. Please note that only subscribers can post messages.

RIPE Forum

The RIPE Forum is an additional way to participate in RIPE community mailing list discussions using a web-based interface rather than an email client.

Check out the forum

Please contact if you need more information.

Stay up to date!

Follow @PDO_RIPE_NCC on Twitter.