IPv4 Allocation and Assignments to Facilitate IPv6 Deployment

The last IPv4 /8 that the RIPE NCC will hold is proposed to be dedicated to facilitate deployment of IPv6. Allocations and assignments from this block will be made based on demonstrated need, but the size will be downscaled taking into account existing transition technologies (for example dual-stack lite, NAT464, successors of NAT-PT). The proposed minimum allocation size is to be a /27 for such allocations and assignments.

Summary of Proposal:

The last IPv4 /8 that the RIPE NCC will hold is proposed to be dedicated to facilitate deployment of IPv6. Allocations and assignments from this block will be made based on demonstrated need, but the size will be downscaled taking into account existing transition technologies (for example dual-stack lite, NAT464, successors of NAT-PT). The proposed minimum allocation size is to be a /27 for such allocations and assignments.

Allocations and assignments from this block will also be justified by demonstrating that the requirements of the transition plan as specified in RFC5211 are met.

Policy Text

New

The last /8 of the IPv4 address space that the RIPE NCC holds is reserved to facilitate IPv6 deployment. The distribution of the address space from this block under this policy will be done in accordance with the existing "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" with few exceptions and the extra criteria as follows:

- This policy applies to all IPv4 Provider Aggregatable (PA) allocations to LIRs and IPv4 Provider Independent (PI) Assignments to End Users.

- The minimum size for allocations and assignments from this block is /27.

- All allocations and assignments made from this block must be justified by demonstrating that the requirements of the transition plan as specified in RFC5211 are met. In particular:

A. When an organisation requests the first allocation or assignment, they have to demonstrate that they have to meet the requirements of the preparation phase of RFC5211. For example, they have to demonstrate that they offer pilot IPv6-based Internet Service to their Internet customers and they have IPv6-based Internet connectivity for any Internet-facing servers (e.g., web, email, and domain name servers).

B. When an organisation requests an additional allocation or assignment, they have to demonstrate meeting the requirements of the transition phase of RFC5211. For example they must offer IPv6-based Internet Service to their Internet customers and must arrange for IPv6-based Internet connectivity for any Internet-facing servers (e.g., web, email, and domain name servers).

C. Organisations that do not hold any address number resources yet will be required to request an initial IPv6 allocation or assignment in accordance with relevant policies.

The intention of the proposal is to support the new deployments and their growth during the gradual transition to IPv6 after the IPv4 pool as we know it is depleted. The intention of the proposal is to stimulate native IPv6 deployment as much as possible, while supporting the need for future networks to communicate with the IPv4 world. This proposal also facilitates entrance of new, IPv6-based ISP into the market after the free IPv4 pool is depleted.

All current transition mechanisms being discussed at the IETF presume use of some kind of IPv4 multiplexing as a window to the IPv4 world. These technologies (NAT is one of them) introduce higher utilisation of IP address space. The efficiency of IPv4 multiplexing needs some research, but looking at the levels of NAT currently deployed and number of concurrent connections per host/user, a downscaling factor of 64 seems to be a reasonable round number. Accordingly, the downscaled minimum allocation and assignment size is proposed to be a /27, downscaling the current minimum allocation size /21.

Arguments supporting the proposal

With the depletion of the free IPv4 address pool, it is reasonable to expect that rationing of IPv4 resources will become more strict. The common practise currently to accomplish this is to use part of the 16-bit space of port numbers to extend the available address space to identify distinct connections. Still, to support new deployments, unallocated IPv4 address space will be required, which may be available through address trading. However, it is uncertain what the uptake of the trading and how liquid the market will be. This proposal adds more predictability with regards to the supply of unallocated IPv4 addresses and provides based on need opportunity for new players.

While use of one or another form of IPv4 multiplexing is inevitable after depletion of the free IPv4 address pool, further deployment may or may not support IPv6 (e.g. NAT444 deployments). This proposal facilitates IPv6 support.

Taking into account the downscaling factor, one /8 will be equivalent to 64 /8. This amount should be sufficient to support transition to IPv6 for several years. A /8 will also allow to more clearly establish a separate filtering policy, with a /27 as a minimum allocation size.

b. Arguments Opposing the Proposal

Setting the minimum allocation and assignment size to a /27 will have an impact on the routing tables. One should consider that this will only happen on the last block and this impact will be limited.