This policy proposal has been accepted
The new RIPE Document is: ripe-822
This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. This status is already implemented in the IPv6 policy1.
The implementation of this proposal would respond to the RIPE Database Requirements Task Force recommendation2 to apply registration requirements consistently to all Internet number resources, regardless of their type or status.
[1] https://www.ripe.net/publications/docs/ripe-738#registration2
[2] https://www.ripe.net/publications/docs/ripe-767
Some LIRs do not register any IPv4 assignments at all, while others make a large number of tiny assignments. Community feedback of the current policy made it clear that making assignments is a needlessly repetitive and time-consuming task.
As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs, while there were 546,402 IPv4 PA assignments of size /32 in the RIPE Database, possibly maintained by automated systems.
Since the RIPE Database Requirements Task Force published their report in May 2021, the PA allocations without any child assignment have grown by 18.4 percent.
The current policy (ripe-804) requires LIRs to register each individual IPv4 assignment in the RIPE Database, with the exception of IPv4 addresses which are “used solely for the connection of an End User to a service provider (e.g. point-to- point links)”, as these can be included in the assignments made to the provider’s infrastructure.
Some LIRs apply this exception to addresses used for other purposes as well, like those addresses assigned by cloud computing providers to virtual machines, or addresses assigned to broadband subscribers who use them for running public services such as personal web servers. This, although not compliant with the policy, is an alternative to creating a huge number of small (and most likely frequently changing) individual assignments.
It would be more efficient to remove the ‘solely for the connection’ limitation stated in the current policy, and to allow the creation of a single INETNUM object with status AGGREGATED-BY-LIR, then use this status for dynamic pools, grouping the IPv4 assignments used for the same purpose when they share the same contact information.
This would save LIRs the repetitive work of filling in contact information for every single customer assignment, while facilitating their compliance with the policy assignment registration requirements and with GDPR.
The current IPv6 policy mandates that INET6NUM objects with AGGREGATED-BY- LIR status must include the “assignment-size” attribute. This attribute is helpful to calculate the HD-ratio, which is used when the LIR requests a subsequent allocation.
The wording of the proposed policy text is in line with the one currently used in the IPv6 policy, however the references to the HD-Ratio and the “assignment-size” attribute are not required, since LIRs can only receive a one-time IPv4 allocation from the RIPE NCC.
Furthermore, due to the scarcity of IPv4 addresses, LIRs are likely to want to right- size each assignment, rather than issue a series of large ‘one size fits all- assignments’ as is commonly done with IPv6.
For these reasons, this proposal does not make the “assignment-size” attribute mandatory, nor does it mention the HD-ratio. Other than that, this proposal uses the exact wording currently used in the IPv6 policy.
[...]
IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users.
An explanation of how to register objects in the database can be found in the "RIPE Database User Manual Getting Started" found at:
https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation
[...]
[...]
[...]
[...]
When an LIR holding an IPv4 address allocation makes IPv4 address assignments, it must register these assignments in the RIPE Database.
These registrations can either be made as individual assignments or by inserting an object with a status value of 'AGGREGATED-BY-LIR'.
In case of an audit, the LIR must be able to present statistics showing the number of individual assignments made in all objects with a status of 'AGGREGATED-BY-LIR.
[...]
[...]
[...]
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.
This document was developed by the RIPE community, and more specifically by Jeroen Lauwers and Tore Anderson, based on the findings of the RIPE Database Requirements Task Force.
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.
It is the RIPE NCC’s understanding that this proposal, if accepted, will offer to members the option to register contiguous IPv4 PA assignments under a single INETNUM object with the status AGGREGATED-BY-LIR when these assignments have identical purpose and contact details.
The size of the IPv4 assignments in the AGGREGATED-BY-LIR range can be different; hence, the “assignment-size” attribute will be optional. As the INETNUM object with the status AGGREGATED-BY-LIR may include assignments to different end users, the contact details registered in the object must be valid for all of them.
Acceptance of this proposal will not change the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this will remain their decision.
If the proposal is accepted, a new policy document, “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” will obsolete the current document ripe-804.
Address/Internet Number Resource Consumption:
After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact in this area if this proposal is implemented.
Fragmentation/Aggregation:
After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact in this area if this proposal is implemented.
Software Engineering:
Software development will be needed to update our systems to add the new status AGGREGATED-BY-LIR for IPv4 assignments. This will be similar to the status used for IPv6 assignments, with the difference that the “assignment-size” attribute will be optional instead of mandatory.
Registration Services:
RIPE NCC Registration Services does not anticipate any significant impact if this proposal is implemented.
It is possible that members will have questions about the requirements for applying the new status, especially during ARCs. The RIPE NCC will clarify that the member might be requested to provide up-to-date utilisation details for the AGGREGATED-BY-LIR range during audits.
The network intended to be announced using a requested AS Number must be registered within a more specific assignment when it is part of an AGGREGATED-BY-LIR range.
After analysing the data that is currently available, the RIPE NCC does not anticipate any significant impact in this area if this proposal is implemented.
However, the RIPE NCC would like to note that it is solely the responsibility of the member to choose which contact details to insert in the INETNUM object. Inserting any personal data in the RIPE Database must be in compliance with the RIPE Database Terms and Conditions, even when it relates to the contact details of the member’s own contact person(s). In particular, before anyone updates the RIPE Database with personal data, they must obtain the contact person’s informed and expressed consent and ensure this data is kept accurate and up-to-date.
With the information currently available, it is expected that implementation of the proposal would have a low impact in terms of the software development needed to facilitate the policy changes in the RIPE NCC’s internal systems. Internal and external processes and documentation, including material for training and exams, would also need to be updated and approved internally for publication.