This policy proposal has been accepted
The new RIPE Document is: ripe-553
You're looking at an older version: 1
The current (published) version is 3This policy proposal will permit the operators in the RIPE NCC service region to continue building successful Internet Exchange Point communities after IPv4 depletion.
This policy proposal will permit the operators in the RIPE NCC service region to continue building successful Internet Exchange Point communities after IPv4 depletion.
[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.]
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:
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.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.
[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.]
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:
Allocations for LIRs from the last /8
On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:
Assignments to Internet Exchange Points
A /16 will be held in reserve for 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 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.
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.