<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""> <div class="">Dear community,</div> <div class=""><br class=""> </div> <div class="">My name is Jeroen and I am new to the community. Ripe 84 is gonna be for me the first in-person Ripe meeting. </div> <div class=""><br class=""> </div> <div class="">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.</div> <div class=""><br class=""> </div> <div class="">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. </div> <div class=""><br class=""> </div> <div class="">Feel free to reach me.</div> <div class=""><br class=""> </div> <div class="">Kind regards,</div> <div class=""><br class=""> </div> <div class="">Jeroen Lauwers</div> <div class=""><br class=""> </div> <div class=""><br class=""> </div> <div class=""> <div class=""><br class=""> </div> <div class=""><b class="">#### Policy Draft Proposal ####</b></div> <div class=""><br class=""> </div> <div class=""> <div class=""><b class="">Remove mandatory IPv4 PA Self assignment registration in the RIPE Database.</b></div> <div class=""><br class=""> </div> <div class="">Number: </div> <div class="">Author: <span class="Apple-tab-span" style="white-space: pre;"> </span> Jeroen Lauwers </div> <span class=""><span class="Apple-tab-span" style="white-space:pre"></span><a href="mailto:jlauwers@a2b-internet.com" class="">jlauwers@a2b-internet.com</a><br class=""> </span><span class=""><span class="Apple-tab-span" style="white-space:pre"></span>A2B Internet<br class=""> </span> <div class="">Proposal Version:</div> <div class="">Submission Date:</div> <div class="">Suggested RIPE WG: <span class="Apple-tab-span" style="white-space: pre;"> </span>Address Policy </div> <div class="">Proposal Type: <span class="Apple-tab-span" style="white-space: pre;"> </span>Modification </div> <div class="">Policy Term: <span class="Apple-tab-span" style="white-space: pre;"> </span>Indefinite</div> <div class=""><br class=""> </div> <div class=""><b class="">Summary of Proposa</b>l</div> <div class=""><br class=""> </div> <div class="">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.</div> <div class=""><br class=""> </div> <div class="">[1] <a href="https://www.ripe.net/publications/docs/ripe-767#612" class="">https://www.ripe.net/publications/docs/ripe-767#612</a> </div> <div class=""><br class=""> </div> <div class=""><b class="">Policy</b></div> <div class=""><br class=""> </div> <div class=""><b class="">1.0 Introduction</b></div> <div class=""><br class=""> </div> <div class="">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.</div> <div class=""><br class=""> </div> <div class="">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.</div> <div class=""><br class=""> </div> <div class="">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).</div> <div class=""> </div> <div class=""><b class="">2.0 Policy Text</b></div> <div class=""><br class=""> </div> <div class="">Current policy text [ 2 ]</div> <div class="">4.0 Registration Requirements</div> <div class="">All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations.</div> <div class=""><br class=""> </div> <div class="">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).</div> <div class=""><br class=""> </div> <div class="">New Policy Text</div> <div class="">4.0 Registration Requirements</div> <div class="">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. </div> <div class=""><br class=""> </div> <div class="">This is necessary to ensure uniqueness and to support network operations.</div> <div class="">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.</div> <div class=""><br class=""> </div> <div class="">[ 2 ] <a href="https://www.ripe.net/publications/docs/ripe-733#4" class="">https://www.ripe.net/publications/docs/ripe-733#4</a></div> <div class=""><br class=""> </div> <div class=""><b class="">3.0 What about legacy space?</b></div> <div class=""><br class=""> </div> <div class="">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.</div> <div class=""><br class=""> </div> <div class=""><b class="">4.0 Attribution</b></div> <div class=""><br class=""> </div> <div class="">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.</div> <div class=""><br class=""> </div> <div class="">Rationale</div> <div class="">a. Arguments supporting the proposal</div> <div class=""><span class="Apple-tab-span" style="white-space: pre;"></span>• 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.</div> <div class=""><span class="Apple-tab-span" style="white-space: pre;"></span>• 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.</div> <div class=""><span class="Apple-tab-span" style="white-space: pre;"></span>• Resource holders of a /24 allocation are required to create at least two assignments (/25 or smaller).</div> <div class=""><span class="Apple-tab-span" style="white-space: pre;"></span>• This is in line with the data consistency and data minimization principles (as defined in the DBTF report):</div> <div class=""><span class="Apple-tab-span" style="white-space: pre;"></span>– Data stored in the RIPE Database should be adequate, relevant, and limited to only what is necessary.</div> <div class=""><span class="Apple-tab-span" style="white-space: pre;"></span>– It is recommended that resource registration requirements are applied consistently.</div> <div class=""><span class="Apple-tab-span" style="white-space: pre;"></span>• More flexibility</div> <div class=""><br class=""> </div> <div class="">b. Arguments opposing the proposal</div> <div class=""><span class="Apple-tab-span" style="white-space: pre;"></span>• An exception to the main rule does not make the overall policy more understandable.</div> <div class=""><span class="Apple-tab-span" style="white-space: pre;"></span>• It is questionable whether other arguments for public tracking of the use of designated prefixes are weak enough to move from “must” to “may”.</div> <div class=""><br class=""> </div> <div class=""><br class=""> </div> <div class=""> <div class=""><br class=""> </div> <div class=""><b class=""><br class=""> </b></div> </div> <div class=""><br class=""> </div> </div> </div> </body> </html>