Summary

  • Tore Anderson and Jeroen Lauwers authored RIPE proposal 2023-04, accepted on 15 April 2024. It added AGGREGATED-BY-LIR to IPv4 PA assignment registration.
  • An LIR can group contiguous assignments with a common purpose and contact in one database object. It must still be able to supply statistics on the individual assignments during an audit.

A ledger with two awkward columns

The RIPE Database's August 2023 snapshot offered a peculiar pair of numbers. It contained 546,402 IPv4 PA assignments of size /32: one address per record. It also had 19,221 PA allocations with no child assignment records, held by 10,052 local internet registries. One side of the ledger looked like a mountain of receipts. The other looked like a blank page. Neither made an operator's life easier.

Tore Anderson and Jeroen Lauwers put those figures in RIPE proposal 2023-04. Their subject was the humble INETNUM record, where an LIR documents how it assigns Provider Aggregatable IPv4 space to its own network or to customers. Entering every small, changing assignment separately can mean a great deal of repetitive work. Some LIRs had been registering no child assignments; others created a sea of /32 objects. The proposal took that split as a problem in registry design rather than a reason to ask operators to type faster.

The solution borrowed a status already used for IPv6. An LIR could place contiguous IPv4 PA assignments in one object marked AGGREGATED-BY-LIR, provided their purpose and contact details were consistent. A dynamic pool serving the same purpose could have one outer record. The operator would still track the assignments inside it and, under the adopted text, provide counts during a RIPE NCC audit. The database would show the boundary and responsible contact; the LIR would keep the operational detail needed to answer a question about use.

The fine print was the interesting part. Individual IPv4 assignments inside a group may be different sizes. The IPv6 version calls for an assignment-size attribute because that number matters to its growth calculation. Anderson and Lauwers left that attribute optional for IPv4. They also tied aggregation to a shared purpose and shared contact. This was a way to collapse repetition, not a blank cheque to hide unrelated uses behind one neat rectangle.

There was a real objection. If a single registry object carries the LIR's contact, how visible is the end user behind one of its assignments? The proposal's discussion records that concern and RIPE NCC's view that some LIR-contact arrangements already met the existing rule. The accepted change left detailed contact-policy reform for another debate. It chose a measurable operational bargain: fewer repeated public objects, with consistent outer information and an audit trail inside the LIR.

RIPE accepted 2023-04 on 15 April 2024. The original 2023 counts explain why the choice mattered; they are a snapshot, not a tally of later adoption. Anderson's contribution was to give the registry a middle drawer. A good ledger can say who is responsible for a block without demanding a separate filing cabinet for every single address.

Original records