Dear community,

My name is Jeroen and I am new to the community. Ripe 84 is gonna be for me the 
first in-person Ripe meeting.

I thought it would be nice as a newcomer to contribute something to the Ripe 
Community. In consultation with some of the chairs, we decided I could try to 
pick up the recommendation from the RIPE Database Requirements Task Force.

Last November the DBTF recommended changing the address policy for IPv4 PA  
assignments (for own usage) from mandatory to recommended. Before I would send 
it as an official proposal to the RIPE NCC I would like to share it with the 
community to see what they think about it. I also would give a short 
presentation about it on RIPE 84 Where there would be space for discussion and 
feedback. You can find the draft version down in this mail.

Feel free to reach me.

Kind regards,

Jeroen Lauwers



#### Policy Draft Proposal ####

Remove mandatory IPv4 PA Self assignment registration in the RIPE Database.

Number:
Author:  Jeroen Lauwers
[email protected]<mailto:[email protected]>
A2B Internet
Proposal Version:
Submission Date:
Suggested RIPE WG:  Address Policy
Proposal Type:  Modification
Policy Term:  Indefinite

Summary of Proposal

In its final report, the RIPE Database Requirements Task Force (DBTF) 
recommended dropping IPv4 PA assignment(s) as a policy requirement [ 1 ]. This 
recommendation was motivated by the fact that existing LIRs are no longer 
eligible to request additional IPv4 prefixes from the RIPE NCC. This partially 
obsoletes the requirement for LIRs to document the assignment of used/reserved 
prefixes in the RIPE Database. This proposal aims to change the policy on 
assigned IPv4 PA space from “must" to "may", which will address the issue of 
unnecessary registration and verification of certain prefixes for LIRs and the 
RIPE NCC. However, it would still be possible (and recommended) for LIRs to 
register PA assignments.

[1] https://www.ripe.net/publications/docs/ripe-767#612

Policy

1.0 Introduction

In the past, LIRs could request a new IPv4 prefix when their current pool was 
sufficiently used. However, since the RIPE NCC started to run out of IPv4, LIRs 
with existing IPv4 prefixes have not been eligible to receive additional IPv4 
prefixes from the RIPE NCC. 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 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 you must register a PA assignment for each 
prefix that an LIR uses. If this specific policy were changed from “must” to 
“may” for IPv4 PA assignments, the RIPE NCC would not need to spend resources 
on enforcing compliance with LIRs that have not followed this policy. This 
policy change would also serve the goal to keep the database limited to what is 
needed.

However, it would still be recommended and possible to register IPv4 PA 
assignments in the RIPE Database. Also, LIRs would still be obligated to make 
assignments in the database when they want to sub-allocate or partition part of 
their IPv4 resources to another entity (sub-allocated PA/assignments).

2.0 Policy Text

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).

New Policy Text
4.0 Registration Requirements
Allocations and assignments to third parties must be registered in the RIPE 
Database to be considered valid. For IPv4 PA assignments used for the LIR's own 
network infrastructure, registration is recommended but not mandatory.

This is necessary to ensure uniqueness and to support network operations.
Registration of objects in the database is the final step in making an 
allocation or assignment. Registration data (range, contact information, 
status, etc.) which filled in the database, must be correct at all times.

[ 2 ] https://www.ripe.net/publications/docs/ripe-733#4

3.0 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.

4.0 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.

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 an additional IPv4 allocation 
from the RIPE NCC. However, this requirement has become obsolete since the IPv4 
run-out.
• 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.
• Resource holders of a /24 allocation are required to create at least two 
assignments (/25 or smaller).
• This is in line with the data consistency and data minimization principles 
(as defined in the DBTF report):
– 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.
• More flexibility

b. Arguments opposing the proposal
• An exception to the main rule does not make the overall policy more 
understandable.
• It is questionable whether other arguments for public tracking of the use of 
designated prefixes are weak enough to move from “must” to “may”.





-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/address-policy-wg

Reply via email to