Remove mandatory IPv4 PA assignment registration in the RIPE Database

Summary of Proposal

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

Introduction

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.

Policy Text

a. Current policy text ^[2]

4.0 Registration Requirements

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

b. New Policy Text

4.0 Registration Requirements

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.

What about legacy space?

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.

Rationale

a. Arguments supporting the proposal

• One of the main reasons for registering IPv4 PA assignments was that LIRs could show their use of IPv4 and thus justify the request for an additional IPv4 allocation from the RIPE NCC. However, this requirement has become obsolete since the RIPE NCC ran out of IPv4 addresses in 2019. 

• The application of IPv4 assignment registration policies in the RIPE Database is inconsistent. Some resource holders flood the database with tiny assignments (e.g. assignments for individual IP addresses), while many others do not register any assignments.
  
  
• This proposal is in line with the data consistency and data minimisation principles (as defined in the DBTF report ^[3]:
  • Data stored in the RIPE Database should be adequate, relevant, and limited to only what is necessary.
  • It is recommended that resource registration requirements are applied consistently.
• Reduce the risk of LIRs registering personal data in the public database for no longer beneficial administrative/policy reasons.
  
  
• More flexibility: LIRs can choose for themselves which information they think is necessary to document and which is not, making it easier to adapt to different situations.

b. Arguments opposing the proposal

• Risk of inefficient abuse handling. 

[3] https://www.ripe.net/publications/docs/ripe-767 

Attribution

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.