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

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

[...]

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

• Changes to the contact registration requirements
  
  It was argued during the Discussion Phase that the proposed policy change would modify the current requirements for the registration of IPv4 PA assignments, introducing the option of creating “inetnum” database objects where the mandatory attributes “admin-c” and “tech-c” are delegated/outsourced to another party (typically the issuing LIR), and where nondelegated/outsourced contact information for End Users is not found in any other optional attribute.
  
  Counter-argument: It is already possible to create such assignments under the current address policy. The RIPE NCC confirmed that they consider these assignments to be policy compliant and do not require them to be modified during audits. Therefore, the proposed policy change simply leaves the status quo unchanged. Changes to the contact registration requirements should be dealt with in a separate policy proposal.

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.

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.

A. RIPE NCC's Understanding of the Proposed Policy

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.

B. Impact of Policy on Registry and Addressing System

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. 

C. Impact of Policy on RIPE NCC Operations/Services

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. 

D. Legal Impact of Policy

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. 

E. Implementation

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.