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. proposes an incentive to implement the exchange of IPv4 routing information over IPv6 for IXPs.
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:
[...]
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 will 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 free market [2].
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.
At the same time, it is obvious that IPv4 is a limited resource and IPv6 provides a technical solution to the IPv4 address shortage. This policy implements an incentive for IXPs to adopt the exchange of IPv4 routing information over IPv6, requiring its implementation and public documentation for requesting an assignment larger than a /24.
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.
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 Link: /publications/docs/ripe-733/ ” will be updated, and a new version of the RIPE Document will be published reflecting this change.
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.
None.
None.
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.