Reducing IXP IPv4 assignment default size to a /26

Summary of Proposal

This proposal modifies the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the assignments previously issued for their IXP peering LAN.

Policy Text:

a) Current policy text (if modification):

6.1. Assignments to Internet Exchange Points

A /15 will be held in reserve for exclusive use by Internet Exchange Points (IXPs). On application for IPv4 resources, an IXP will receive a single number resource block according to the following:

1. Organisations receiving space under this policy must be IXPs and must meet the definition as described in section two of the RIPE Document "IPv6 Address Space for Internet Exchange Points".
2. This space will be used to run an IXP peering LAN only; other uses are forbidden.
3. Assignments will only be made to IXPs that have applied for an IPv6 assignment for their peering LAN (or have already received one).
4. New IXPs will be assigned a /24 by default. Once they require a larger assignment, they must return their current one (or existing PI used as an IXP peering LAN) and receive a replacement up to maximum of a /22. After one year, utilisation of the new assignment must be at least 50%, unless special circumstances are defined. On request or once there are no more assignments of /24 (or larger) available, assignments can be made down to /27.
5. IXPs holding other PI IPv4 space for their peering LAN (i.e., they are seeking a larger assignment), and any IPv4 space assigned from this pool that is no longer in use, must be returned to the pool within 180 days of disuse or a new assignment.

b) New policy text:

6.1. Assignments to Internet Exchange Points

[...]

1. New IXPs will be initially assigned a /26 by default. Once more than 50% of the initial assignment has been utilised, IXPs can request an assignment up to a /24. In this case, the IXP must return the existing assignment (or existing PI previously issued for their IXP peering LAN).
2. Once IXPs require an assignment larger than /24, they must return their current one (or existing PI previously issued for their IXP peering LAN) and receive a replacement up to a maximum of a /22. After one year, utilisation of the new assignment must be at least 50%, unless special circumstances are defined.
3. If there are no more assignments of /26 available, smaller assignments can be made.
4. IXPs holding other PI IPv4 space for their peering LAN (i.e. seeking for a larger assignment), and any IPv4 space assigned from this pool that is no longer in use, must be returned to the pool within 180 days of disuse or a new assignment.

Rationale:

a. Motivation for the proposal

At RIPE85, RIPE NCC Registration Services manager Marco Schmidt presented a forecast of the IXP IPv4 pool lifetime dedicated to peering LANs [1]. He predicted the pool would be depleted around 2029. A depleted IXP pool will lead to high upfront costs for new IXP projects, since they will have to purchase IPv4 addresses from brokers. Currently, a /24 IPv4 block required to found an IXP costs more than 11,000 USD when bought on the open market [2].

b. Arguments supporting the proposal

An analysis of PeeringDB [3] data by one of the authors [4] shows that the current practice of handing out a default /24 to new IXPs is wasting a large amount of valuable IPv4 space from the IXP pool. A majority (~70%) of all IXPs would fit into a /26, including 100% overprovisioning in terms of IPv4 addresses. Lowering the default assignment size to /26 would stretch the lifetime of the IXP pool by a factor of four assuming a constant burn rate.

c. Arguments opposing the proposal

Lowering the default assignment size increases the probability for IXP operators to outgrow their assigned IPv4 prefix in terms of connected devices. Once this happens, the IXP operator is forced to apply for a new assignment and to renumber all routers connected to the IXP. During the mailing list discussions preceding this proposal, IXP operators showed some support for a /26. However, this is a delicate trade-off which must be reviewed within a reasonable timeframe after implementing this policy.

[1] https://ripe85.ripe.net/wp-content/uploads/presentations/66-RIPE85-Feeback-from-RS.pdf[2] https://auctions.ipv4.global/prior-sales[3] https://www.peeringdb.com/[4] https://github.com/mwichtlh/address-policy-wg

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.

A. RIPE NCC's Understanding of the Proposal

It is the RIPE NCC's understanding that this proposed policy will change the current practice for IPv4 assignments to IXPs in terms of assignment size. Specifically, from the moment this proposal comes into effect, the default size of IPv4 assignments received by IXPs will be reduced to a /26 (currently a /24). Once the utilisation of the assigned /26 will exceed 50%, an IXP will qualify for requesting up to a /24, and the existing assignment will be returned to the IXP pool after renumbering. Assignments larger than a /24 up to a /22 will be requested based on utilisation as it stands in the current policy.

The criteria for defining an IXP described in the current policy remain unchanged.

Once the policy has become active, section 6.1 of the current RIPE policy, “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” will be updated, and a new version of the RIPE Document will be published reflecting this change.

B. Impact of Policy on Registry and Addressing System

Under the current policy, based on a linear extrapolation of trends observed over the last months, we expect the IXP IPv4 pool to become empty in the second half of 2029. Keeping in consideration the same parameters, the reduction of the assignment size could extend the lifetime of the IXP IPv4 pool into the 2030s, although the growth in the number of IXPs could increase at a higher rate.

C. Impact of Policy on RIPE NCC Operations/Services

None.

D. Legal Impact of Policy

None.

E. Implementation

With the information currently available, it is expected that implementation of the new specifications in the proposal would have a low impact in terms of  the software development to reflect the policy changes in internal RIPE NCC systems. Internal and external processes and documentation would also need to be updated.