Skip to main content
  • Legend
  • Added
  • Deleted

Summary of proposal:

Summary of Proposal

Increase the reserved pool for IXPs to a /15 and finetune assignment criteria.

IXPs need globally unique address space – not for the sake of their own networks, but for the sake of the networks connecting to it. Since creating the reserved pool for IXPs in 2012, about half of it has been assigned. Given continued growth of the IXP ecosystem, the role it plays in developing the global Internet, and its dependence on globally-unique (but not necessarily globally-routed) IPv4 space, it makes sense to increase the pool size and tweak the assignment options to ensure longevity of the IXP pool.

Policy text

Current policy text:

5.1 Allocations made by the RIPE NCC to LIRs

[…]

On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:

  1. The size of the allocation made will be exactly one /22.

  2. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).

  3. The LIR must confirm it will make assignment(s) from the allocation.

All address blocks smaller than a /24 will be held by the RIPE NCC and are declared unallocatable until the missing fragments are received/recovered by the RIPE NCC.

Once an equivalent of a /22 can no longer be allocated, the RIPE NCC will start allocating IPv4 resources based on a first-come-first-serve waiting list. […]

5.1bis Allocations made by the RIPE NCC to LIRs when using a Waiting List

[…]

In case an allocation of a single /24 as per clause 1 can no longer be made, no allocation is to be made until the RIPE NCC recovers enough address space to allocate contiguous /24 allocations again.
All address blocks smaller than the allocation size will be held by the RIPE NCC and are declared unallocatable until the missing fragments are received/recovered by the RIPE NCC and they can be allocated as a contiguous allocation as per clause 2.

5.3 Address Recycling

Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1.

This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself.

Text

a. Current Policy Text (ripe-720 Link: /publications/docs/ripe-720/ )

6.1. Assignments to Internet Exchange Points Point

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

  • This space will be used to run an IXP peering LAN; other uses are forbidden.

  • 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".

  • IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment.

  • New IXPs will be assigned a /24. Should they require a larger assignment, they must return their current assignment (or existing PI used as an IXP peering LAN) and receive a replacement /23 or /22. After one year the utilisation of the new assignment must be at least 50%, unless special circumstances are defined.

  • IP space returned by IXPs will be added to the reserved pool maintained for IXP use.

  • Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN.

New Policy text:

5.1 Allocations made by the RIPE NCC to LIRs

[…]

On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:

  1. The size of the allocation made will be exactly one /22.

  2. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).

  3. The LIR must confirm it will make assignment(s) from the allocation.

[paragraph removed]

Once an equivalent of a /22 can no longer be allocated, the RIPE NCC will start allocating IPv4 resources based on a first-come-first-serve waiting list. […]

5.1bis Allocations made by the RIPE NCC to LIRs when using a Waiting List

[…]

In case an allocation of a single /24 as per clause 1 can no longer be made, no allocation is to be made until the RIPE NCC recovers enough address space to allocate contiguous /24 allocations again.

[paragraph removed]

[…]

5.3 Address Recycling

Any IPv4 address space that was originally assigned by the RIPE NCC for exclusive use by Internet Exchange Points (IXPs) will be added to the reserved IXP pool upon return.

Other address space blocks of a /24 or larger that are returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1 – smaller blocks will be put into the reserved pool for IXP use.

This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself.

b. New Policy Text

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 "IPv6 Address Space for Internet Exchange Points Link: http://www.ripe.net/publications/docs/ipv6-policy-ixp ". 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 Should 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. /23. 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.
upon depletion of the reserved pool, assignments down to a /27 can be made.
  1. 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. 

  2. Any IPv4 space returned by IXPs will be added to the reserved pool maintained for IXP use.

  3. Any assignments made previously from this pool will remain unchanged.

Rationale

a. Arguments Supporting the Proposal

  • These changes will ensure long term availability of the IXP pool for establishing new IXPs and growing existing ones;
  • It provides a use for IPv4 inventory of the RIPE NCC that is impractical to be used in the global routing table.

b. Arguments Opposing the Proposal

  • It no longer provides for IXPs that need more than a /23 of IPv4 space;It moves depletion of the RIPE NCC IPv4 free pool forward by about a week.

A. RIPE NCC's Understanding of the Proposal

As the RIPE NCC understands it, this proposed policy change extends the RIPE NCC’s reserved IPv4 pool for IXP use from the existing /16 to a /15. This extension is based on the original IPv4 pool size reserved for IXPs, and not the currently available space in this pool. Therefore, the RIPE NCC will add a /16 to the reserved IPv4 pool for IXPs if this proposal reaches consensus.

A contiguous /16 range will be added to the IXP pool, if such a range is available if and when this policy change reaches final consensus. This will ensure easier identification of IXP ranges from well-known prefixes, such as the current 185.1.0.0/16 for IXP use. If there is no such contiguous range available when consensus is reached, multiple ranges will be added to the IXP pool, amounting to a /16.

This proposed address space will be taken from the RIPE NCC’s pool for IPv4 allocations. Consequently, the pool will have less address space available for IPv4 allocation requests. If this policy is accepted, the overall pool for IPv4 allocations is likely to be exhausted one week earlier than previously forecast, assuming IPv4 allocation requests continue at the same rate as at present.

It is important to note that the RIPE NCC will not be able to extend the IXP pool to a /15 if consensus is reached after its pool for IPv4 allocations is exhausted. Currently, the RIPE NCC estimates that the IPv4 pool for allocations will be exhausted towards late 2019.

If this policy change reaches rough consensus, meaning the proposal is in the Last Call phase, around the same time that the IPv4 pool for allocations is almost exhausted, the RIPE NCC might consider reserving a /16 for this policy change. If final consensus is achieved, the /16 will be used as per the policy proposal, and alternatively, if the proposal is withdrawn, the address space will be returned to the IPv4 pool for allocations.

The proposed policy further states that returned IPv4 blocks smaller than a /24 in size should be added to the IXP pool. Currently these ranges are part of the general IPv4 pool but are considered ‘unallocatable’. At the moment of writing this analysis, the RIPE NCC holds around 6,000 IPv4 addresses in ranges smaller than a /24. If this policy is accepted, these IPs will be added to the IXP pool in addition to the /16.

The default assignment size for an IXP request will remain a /24. Larger assignments up to a /22 can be requested based on utilisation, as it stands in the current policy. On request or in case no more assignments of /24 (or larger) are available, IXPs can also receive smaller assignments down to a /27.

As per this policy proposal, ranges of /29s and /28s will also be added to the IXP pool. Such small ranges will be held in the IXP pool but not assigned, until neighbouring fragments are recovered to allow the creation of a contiguous /27 at the very least.

The proposed policy moves the rules about returned IXP space to the general section 5.3 Address Recycling. Despite this move, which increases clarity about what happens with returned IPv4 space, there is no actual change in the policy requirements for returned IXP space.

B. Impact of Policy on Registry and Addressing System

Over half of the address space has been assigned since the RIPE NCC created the reserved IPv4 pool for IXPs in 2012. There are currently around 29,000 IPv4 addresses left (~/18,/19,/20). This address space appears to be sufficient for another four to five years based on the consumption rate of the past months. Adding a /16 to the IXP pool will extend the lifetime of the pool by roughly 10 years until 2033.

Since IXP assignments are usually not announced (in contrast to IPv4 allocations), we do not expect any impact on the routing table.

C.1 Impact of Policy on RIPE NCC Operations/Services

No significant or immediate impact is expected on the workload of Registration Services if this proposal reaches consensus, mainly because the requirements for IXP assignments remain largely the same. The proposed policy change extends the lifetime of the IXP pool by about 10 years, meaning the RIPE NCC will be required to provide this service accordingly. All the same, the actual workload will be low, based on the current request rate of one or two requests per week.

C.2 RIPE NCC Board’s input

As matter of clarification: One of the proposers, Remco van Mook, is also a member of the RIPE NCC Executive Board. He has refrained from any intervention in this proposal in his capacity as a Board member.

D. Legal Impact of Policy

There is no significant legal impact expected if this policy reaches consensus.

E. Implementation

With the information currently available, it is expected that the implementation of the proposal would take around one month in terms of the IPv4 pool management and adjusting request forms to facilitate the policy changes in internal RIPE NCC systems. Internal and external processes and documentation would also need to be updated.