Safeguarding future IXPs with IPv4 space

This policy proposal will permit the operators in the RIPE NCC service region to continue building successful Internet Exchange Point communities after IPv4 depletion.

Summary of Proposal:

This policy proposal will permit the operators in the RIPE NCC service region to continue building successful Internet Exchange Point communities after IPv4 depletion.

Policy Text:

Current

[Following text is to be modified in the RIPE Policy Document “IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region”, if the proposal reaches consensus. This would result in a new policy section.]

5.6 Use of last /8 for PA Allocations

The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:

1. Allocations for LIRs from the last /8
   On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:
   1. LIRs may only receive one allocation from this /8.  The size of the allocation made under this policy will be exactly one /22.
   2. LIRs receive only one /22, even if their needs justify a larger allocation.
   3. LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application.
   4. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.

1. Unforeseen circumstances

   A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen.  Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it. In the event that this /16 remains unused at the time the remaining /8 covered by this policy has been distributed, it returns to the pool to be distributed as per clause 1.

1. Post-depletion Address Recycling

   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.

   1. Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in clause 1.
   2. Minimum allocation sizes for the relevant /8 blocks will be updated if necessary

1. Insufficient address space

   In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.

New

[Following text will replace section 5.6 in the RIPE Policy Document “IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region” , if the proposal reaches consensus. This would result in a new policy section. NOTE: renumbered paragraph 5.6.2 to 5.6.3 and added new text in paragraph 5.6.2]

5.6 Use of last /8 for PA Allocations

The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:

1. Allocations for LIRs from the last /8

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

1. LIRs may only receive one allocation from this /8.  The size of the allocation made under this policy will be exactly one /22.
2. LIRs receive only one /22, even if their needs justify a larger allocation.
3. LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application.
4. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.

1. Assignments to Internet Exchange Points

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

   • This space will be used to run an Internet Exchange Point peering LAN, other uses are forbidden.
   • Organisations receiving space under this policy must be Internet Exchange Points 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 Internet Exchange points will be assigned a /24. Internet exchange points may return this /24 (or existing PI used as an IXP peering LAN) should they run out of space and receive a larger (/23, or /22 if utilisation requires) assignment.
   • IP space returned by Internet Exchange Points will be added to the reserved pool maintained for Internet Exchange Point use.
   • Assignments will only be made to IXPs who have already applied for, or received an IPv6 assignment for their peering LAN.

1. Unforeseen circumstances

   A /16 will be held in reserve for some future uses, as yet unforeseen. The Internet is a disruptive technology and we cannot predict what might happen.  Therefore it is prudent to keep a /16 in reserve, just in case some future requirement makes a demand of it. In the event that this /16 remains unused at the time the remaining /8 covered by this policy has been distributed, it returns to the pool to be distributed as per clause 1.

1. Post-depletion Address Recycling

   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.

1. Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in clause 1.
2. Minimum allocation sizes for the relevant /8 blocks will be updated if necessary

1. Insufficient address space

   In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.

Rationale:

a. Arguments supporting the proposal

Much of the work that goes into creating Internet Exchange Points today is done in regions of the world where there is no Internet Exchange Point yet. Opening an IXP helps to develop the Internet and Internet community in that region, so the work really is 'good of the Internet'. Starving these regions of an opportunity to build a simple open Internet Exchange Point would be severely damaging to Internet users in regions under-served by IXPs.

This idea was supported unanimously and approved as beneficial in the EIX Working Group at RIPE 62, and in a discussion between Internet Exchange Point operators in Euro-IX.

The need for special cases for IXP LANs has already been accepted and accommodated for the IPv6 assignment policy.

Although it is possible to do IPv4 prefix-exchange over an IPv6 transport, IXPs still need to set an IPv4 next-hop to allow routing to occur.

It is not possible to use unannounced or RFC1918 address space for IXP peering lans, as this breaks URPF and ICMP communication, and breaks the opportunity for debugging of connections over the Exchange for connected and non-connected networks due to the IX path missing from traceroutes, and peering routers not getting the ability to set reverse DNS.

b. Arguments opposing the proposal

None.