Skip to main content

Revised IPv4 assignment policy for IXPs

This policy proposal has been accepted and has been implemented

The new RIPE Document is: ripe-730

You're looking at an older version: 1

The current (published) version is 2
2019-05
State:
Accepted
Publication date
Affects
Draft document
Draft
Author(s)
Proposal Version
2.0 - 22 Jul 2019
All Versions
Accepted
10 Oct 2019
Implemented
20 Jan 2020
Working Group
Address Policy Working Group
Proposal type
  • Modify
Policy term
Indefinite
New RIPE Document(s)

Summary of Proposal

Increase the reserved pool for IXPs to a /15 and finetune assignment criteria.
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

a. Current Policy Text (ripe-720)

6.1. Assignments to Internet Exchange 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.

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 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. 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 /23. After one year, utilisation of the new assignment must be at least 50%, unless special circumstances are defined. On request or upon depletion of the reserved pool, assignments down to a /27 can be made.

  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.

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

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