The current RIPE IPv4 policy requires resource holders to document the allocation of used/reserved prefixes in the RIPE Database. This requirement was originally introduced to justify the need for new allocations. However, since the RIPE NCC ran out of IPv4 addresses in 2019 [1], LIRs cannot request new IPv4 allocations if they have already received a sum of allocations from the RIPE NCC that reaches or exceeds a /24. This makes the requirement to document assignments to justify the need for new IPv4 resources obsolete and calls for a revision of the RIPE IPv4 policy.
This proposal aims to solve this problem by changing the registration of IPv4 assignments from mandatory to optional. This will reduce the administrative burden caused by unnecessary registration and verification of certain prefixes for LIRs and the RIPE NCC, while also reducing the amount of personal data in the database. However, it would still be recommended that LIRs register their assignments under certain conditions (sub-allocated PA/assignments).
[1] https://www.ripe.net/publications/docs/ripe-767#612
In the past, LIRs could request a new IPv4 prefix when their current pool was sufficiently used. However, since the RIPE NCC ran out of IPv4, LIRs already holding IPv4 resources have not been eligible to request additional IPv4 prefixes. This resulted in unnecessary efforts by LIRs to register IPv4 prefixes and by the RIPE NCC to ensure that LIRs complied with the policy. This has also led to inconsistencies in the RIPE Database, as some resource holders registered more information than necessary, while many others did not make any PA assignments. The RIPE Database Requirements Task Force (DBTF) reported that, in May 2021, there were 16,232 PA allocations without any child PA assignments and 9,986 LIRs held PA allocations containing no PA assignments.
The current policy states that LIRs must register a PA assignment for each prefix they use. If this proposal becomes policy, the RIPE NCC would not need to spend resources on enforcing compliance with LIRs that have not followed this policy.
However, it would still be highly recommended to register IPv4 PA assignments in the RIPE Database, especially when LIRs want to sub-allocate or assign to another entity (sub-allocated PA/assignments) parts of the IPv4 resources they hold.
The RIPE community has repeatedly pointed out in the past that the RIPE Database contains too much redundant, obsolete and unnecessary data. This proposal attempts to minimise this data by letting the LIRs decide whether or not to document IPv4 assignments. This will also reduce the administrative overhead for LIRs and the RIPE NCC, as they will save time by not having to register and verify unnecessary assignments.
All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations.
Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status, etc.) must be correct at all times (i.e. they have to be maintained).
[2] https://www.ripe.net/publications/docs/ripe-733#4
Registering sub-allocations and assignments in the RIPE Database is strongly recommended but not mandatory.
Registration of objects in the database is the final step in making an allocation or assignment.
LIRs are responsible for the address space that they received by the RIPE NCC and must ensure that the registration data (range, contact information, status, etc.) in the database is maintained correct at all times and that operations such as abuse handling can be performed efficiently.
As the RIPE NCC does not audit RIPE NCC members on their legacy space or how they use it, this policy change does not have an impact on legacy space or legacy space holders.
[3] https://www.ripe.net/publications/docs/ripe-767
This document was developed by the RIPE community, and more specifically by Jeroen Lauwers, based on the findings of the RIPE Database Requirements Task Force.