This policy proposal has been accepted
The new RIPE Document is: ripe-553
This 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:
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.
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.
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:
On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:
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:
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.
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.
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.
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.
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.
A. RIPE NCC's Understanding of the Proposed Policy
The RIPE NCC understands this policy as follows:
Each organisation that receives an assignment under this policy may only hold a single IPv4 prefix for the purpose of running an IXP peering LAN. Any IPv4 PI space the organisation may previously have received to operate their peering LAN must then be returned. Any IPv4 prefixes returned under this policy will become part of the pool reserved for IPv4 IXP assignments even if not part of the last /8.
This policy applies the exact same criteria for determining when an organisation is an IXP as defined in section two of the RIPE policy document “IPv6 Address Space for Internet Exchange Points”.
B. Impact of Policy on Registry and Addressing System
Address/Internet Number Resource Consumption:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
Fragmentation/Aggregation:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
C. Impact of Policy on RIPE NCC Operations/Services
Registration Services:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
Billing/Finance Department:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
RIPE Database:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
D. Legal Impact of Policy
After analysing the data that is currently available, the RIPE NCC does not anticipate that the implementation of this proposed policy will cause any significant legal implications.