Summary of Proposal

Abandonment of the Minimum (Sub-) Allocation Size concept in the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" document, currently ripe-606.

Policy Text

[The following text will update sections 5.1 , 5.4 and 5.5 in the RIPE Policy Document “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”, if the proposal reaches consensus.]

a. Current policy text

"5.1 Allocations made by the RIPE NCC to LIRs

The RIPE NCC's minimum allocation size is /22.

Details of how to join the RIPE NCC [...]"

b. New policy text

"5.1 Allocations made by the RIPE NCC to LIRs

[]

Details of how to join the RIPE NCC [...]"

c. Current policy text

"5.4 Sub-allocations

[...] should contact the RIPE NCC by email at lir-help@ripe.net Link: mailto:lir-help@ripe.net .

The minimum size of a sub-allocation is /24. This is the smallest prefix length that can be reverse delegated and allows for a reasonable number of small assignments to be made by a downstream network operator.

LIRs may make sub-allocations [...]

d. New policy text

"5.4 Sub-allocations

[...] should contact the RIPE NCC by email at lir-help@ripe.net Link: mailto:lir-help@ripe.net .

[]

LIRs may make sub-allocations [...]"

e. Current policy text

"5.5 Transfers of Allocations

[...] or otherwise through the Regional Internet Registry System.

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 block size at the time of re-allocation.

Re-allocation must be reflected [...]"

f. d. New policy text

"5.5 Transfers of Allocations

[...] or otherwise through the Regional Internet Registry System.

Address space may only be re-allocated to another LIR that is also a member of the RIPE NCC. []

Re-allocation must be reflected [...]"

Rationale

a. Arguments supporting the proposal

• The Minimum Allocation Size concept no longer makes any sense, makes no sense any longer, in the light of the strict allocation size of only one (last) /22 per (new) LIR. It LIR, it has lost its originally intended purpose of enforcing the RIPE NCC to hand out no less than 1024 IPv4 addresses per allocation.
• The Minimum Allocation Size as a lower boundary appears to be artificial now, keeping it could be understood as the RIPE NCC patronising to patronise LIRs in using their address space – whether it is PI or PA; see next two arguments.
• The proposal would end incongruencies because it is currently not possible to convert PI assigned address space of LIRs into PA allocated address space for PI assignments smaller than a /22.
• The proposal would enable the LIR-to-LIR transfer of PA allocated address space smaller than a /22.
• The proposal corollary obsoletes the Minimum Sub-Allocation Size concept as well.

b. Arguments opposing the proposal

• It might be argued that abandoning the Minimum Allocation Size for IPv4 could lead to very small allocations. However, whether such small allocations would be still usable for LIRs should be determined by the concerned LIRs and not by a RIPE Policy: policy: e.g. as an LIR, keeping address space as PI assigned for infrastructure purposes would equally make perfect sense as converting it into PA allocated to then transfer it away.

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 proposal might have if it is accepted and implemented.

A. RIPE NCC's Understanding of the Proposed Policy

It is the RIPE NCC's understanding that this proposal would remove the minimum size for IPv4 allocations and sub-allocations.

The proposal would allow LIRs to split their existing allocations to any size, and to create more specific sub-allocations of any size. It would also make it possible for LIRs to transfer allocated PA address space smaller than a /22. The RIPE NCC would not be responsible for the fact that small allocations may not be globally routable.

There are currently 1,260 LIRs with a combined total of 2,066 infrastructure PI assignments smaller than a /22. If this policy is accepted, these assignments may be converted into PA allocations, provided they are correctly registered with the RIPE NCC to the same legal entity that is registered as an LIR.

The RIPE NCC will continue issuing /22 allocations according to section 5.1 of “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Link: http://www.ripe.net/ripe/docs/ipv4-policies#51 ”.

B. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption:

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.

Fragmentation/Aggregation:

When looking at IPv4 transfers conducted before 23 April 2014, only 5% (14 out of 317) involved the transfer of a single /22 block. Had the proposed policy already been in place, some of these requests might have been filled with blocks smaller than a /22.

Given the low number of /22 transfers, the risk of an explosion in routing table size due to the transfer of smaller address blocks appears to be low.

C. Impact of Policy on RIPE NCC Operations/Services

The RIPE NCC could receive complaints from operators who encounter usability issues regarding small allocations that are unable to achieve global reachability due to route filters applied by third parties. These complaints will be beyond the RIPE NCC’s scope to resolve.

Registration Services:

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.

Billing/Finance Department:

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.

RIPE Database:

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.

D. Legal Impact of Policy

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.

E. Implementation

The RIPE NCC estimates that this proposal would be straightforward to implement if it is accepted.

Existing processes, supporting software and documentation (including legal documents) would need to be updated to remove the size limitation for allocations and sub-allocations. As allocations smaller than a /24 would be possible, the RIPE NCC would provide classless delegation for Provider Aggregatable (PA) address space.