IPv4 Maximum Allocation Period

This proposal is to have the RIPE NCC allocate address space to Local Internet Registries (LIRs) based on their one-year needs. In other words, it suggests setting a maximum allocation period of 12 months.

This proposal is to have the RIPE NCC allocate address space to Local Internet Registries (LIRs) based on their one-year needs. In other words, it suggests setting a maximum allocation period of 12 months.

Rationale:

• LACNIC allocates for three months
• ARIN allocates for three or six months
• APNIC allocates for one year
• AfriNIC allocates for two years

In the interest of fairness, all regions should have a harmonised maximum allocation period. Although policies differ in many areas according to the specific needs of a region, the general principle is to have fair and responsible distribution of Internet resources.

Having different allocation periods could be seen as offering advantages to LIRs in one region over those in another. With a shorter allocation period, an LIR can only plan for the short term, whereas others will have more flexibility in terms of their planning.

LIRs in the RIPE NCC service region may appear to have an unfair advantage over those in other regions. It is both fair and responsible to harmonise maximum allocation periods in all regions. This will mean that all LIRs will plan their address space needs within the same time frames.

There is no special need to have different time frames for allocations among regions. Address planning by an LIR requires consideration of similar parameters in all regions. LIRs in all five regions should be able to plan and utilise the address space over the same period.

We think that address space planning for periods longer than a year usually does not take account of a world where changes happen frequently. Planning for less than a year can be short-sighted and cause extra administration. One year is a reasonable time frame to set as the maximum allocation period.

The RIPE NCC’s experience is that majority of the LIRs are making their realistic addressing plans for a year nowadays. This policy will document this situation.

Currently there is a similar proposal in the LACNIC region to have the allocation period to be set to a year. You can see this proposal at:
http://lacnic.net/documentos/lacnicix/LAC-2006-03-EN.pdf (PDF)

We hope to have similar proposals in other regions to harmonise the allocation periods.

b. Arguments Opposing the Proposal

One can argue that allocating for 12 months instead of 24 months can increase fragmentation of address space. We are not aware of any reports of this being a significant problem in other regions where the RIRs allocate for 12 months or shorter time period (APNIC, ARIN and LACNIC).

Harsha Narayan presented a report in 2003, during RIPE 45, which indicated that allocation practices of RIRs do not have much effect on routing table since the vast majority of prefixes seen in the routing table were a result of de-aggregation at the time.

Additional Supporting Information:

During the Address Policy Working Group session at RIPE 53, the RIPE NCC was asked to provide a projection of how changing the IPv4 Maximum Allocation Period would affect IPv4 consumption and routing table fragmentation.

The RIPE NCC produced a simulation to compare the effect of the current policy with the proposed policy (2006-06). The simulation projects what would have happened if the policy proposal had been in place between 2000 and 2005.

The simulation used historical allocation data (from the RIPE NCC registration records) and was run using a set of assumptions. These assumptions can be found in the appendix to this document.

IPv4 Consumption

The simulation suggests that, if the policy proposal had been in place from 2000 onwards, IPv4 consumption would have been reduced by approximately one /8 by July 2005.

Fragmentation

The simulation suggests that if the policy proposal had been in place from 2000 onwards, 3,000 more separate prefixes would have been allocated by July 2005.

Reservation Scheme

The simulation also ran a scenario where reservation allowed the RIPE NCC to reduce fragmentation. This was simulated by giving each /19, /20 and /21 allocation an identical reserved block. These were then combined to a single double size allocation when the
next simulated request was processed.

The simulation suggests that, if a one year allocation period where reservations are made up to a /19 had been in place since 2000:

• IPv4 consumption would have been reduced by approximately two thirds of one /8 by July 2005
• 250 more separate prefixes would have been allocated by July 2005

Appendix A: Set of Assumptions

As with all simulations, it is important to note that the results are inevitably based on a simplified model of how things work in practise. The simulation used the following assumptions:

• It is assumed that, under the proposed policy, every LIR qualifies for only half the amount of the IP addresses handed out in each (historical) allocation unless this is already the minimum allocation (/21 = 2048 IPs). Exactly 1 year after the simulated first allocation, the simulation “hands out” the second half of the historically allocated IP block.
• A historic allocation is only split in half (1 per year) when the next allocation is more than 18 months after the one under consideration and the allocated block is larger than the current minimum allocation (/21).

Rationale: We considered those LIRs who come back for further IP address space in less than 18 months as those LIRs who would be able to plan for one year.

• The simulation reduces the last allocation of a LIR to 75% of the historical allocation size when more than 3 years have passed since the time of this last historical allocation.

Rationale: For the LIRs which did not come back for further allocation for more than 3 years we assumed that they hadn’t used up 80% of their address space (criteria to qualify for further allocation). Consequently, the simulation calculated that they could have only used, on average, 75% of their allocated address space.