Extension of the Minimum Size for IPv6 Initial Allocation

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.

Summary of proposal

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.

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.

If this proposal reaches consensus, the RIPE NCC will expand up to a /29 all the /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”.

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.

Policy text

Current

[Following text is to be modified from the RIPE Policy Document “IPv6 Address Allocation and Assignment Policy”, if the proposal reaches consensus. This would result in a new policy section.]

5.1.2. Initial allocation size

Organisations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32.

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.

[Following text is to be removed from the RIPE Policy Document “IPv6 Address Allocation and Assignment Policy”, if the proposal reaches consensus.]

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.

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.

New

[Following text will replace the part of the RIPE Policy Document “IPv6 Address Allocation and Assignment Policy”, if the proposal reaches consensus.]

5.1.2. Initial allocation size

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. 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.

Rationale

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 is a viable way for ISPs to offer their customers production quality IPv6 service without redesigning and replacing existing infrastructure.

Unlike traditional “hub and spoke” tunnelling approaches, 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 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 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.

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.

During early discussions in the community, there was objection to calling out 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.

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.