Add AGGREGATED-BY-LIR status for IPv4 PA assignments

Summary of Proposal

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 policy¹.
The implementation of this proposal would respond to the RIPE Database Requirements Task Force recommendation² 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

Introduction

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.

1.1 Simplifying and Optimising Assignment Registration

The current policy (ripe-733) 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.

1.2 Differences from IPv6 AGGREGATED-BY-LIR Status

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. 

Policy Text

a. Current policy text (ripe-733)

[...]

6.2 Network Infrastructure and End User Networks

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

[...]

7.0 Types of Address Space

[...] 

• ASSIGNED PA: This address space has been assigned to the issuing LIR infrastructure or an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR.
• ASSIGNED PI: This address space has been assigned to an End User for a specific purpose. It cannot be used to make further assignments to other parties.

[...]

b. New policy text 

[...]

6.2 Network Infrastructure and End User Networks

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.

[...]

7.0 Types of Address Space 

[...]

• ASSIGNED PA: This address space has been assigned to the issuing LIR infrastructure or an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR.
• AGGREGATED-BY-LIR: This address space has been assigned to different parts of the issuing LIR infrastructure or to End Users for use with services provided by the issuing LIR. The purpose and the contact details must be consistent throughout the whole assignment. It cannot be kept when terminating services provided by the LIR.
• ASSIGNED PI: This address space has been assigned to an End User for a specific purpose. It cannot be used to make further assignments to other parties.

[...]

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

• Reduced administrative workload for LIRs, since they no longer need to manually register many small assignments (or develop automated systems to do so)
• LIRs that currently practise ‘under-assignment’ (i.e. not creating assignments at all) will have fewer reasons to continue this practice
• Explicitly allowing aggregated assignments will help reduce ‘over-assignment’ 

b. Arguments opposing the proposal

• None

5.0 Attribution

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.