Summary

  • Remco van Mook and Marco Hogewoning wrote RIPE 2010-06 to replace a vague IPv6 End User registration obligation with a choice: record individual assignments or publish an aggregate inet6num object marked AGGREGATED-BY-LIR and its assignment-size. Assignments larger than /48 still required separate records.
  • The LIR had to retain counts for an audit or a later allocation request, so RIPE NCC could verify the HD ratio. The proposal was accepted on 3 February 2011 and RIPE NCC said by 15 February that the database feature and related processes were implemented.

One thousand customers, one public card

What should a public Internet registry know about a broadband provider's customers? In 2010, the IPv6 policy had a grand answer and a blurry instruction. It required End User assignment information in a database accessible to RIRs, without defining exactly which database or what had to appear in it. That left providers guessing how much to publish and reviewers guessing what to ask for. The final proposal by Remco van Mook and Marco Hogewoning turned that fog into two fields and a record-keeping obligation.

Their RIPE-513 document gives a deliberately plain example. A provider serving 1,000 customers with /56 IPv6 assignments could register a single /46 pool object with status: AGGREGATED-BY-LIR and assignment-size: 56. The public entry describes the pool and the size of each assignment. It does not need 1,000 separate customer cards to calculate address-use efficiency. Anyone hoping for a customer directory would find a filing cabinet labelled “aggregate”.

That did not send the evidence into a shredder. The adopted section 5.5 lets LIRs register individual assignments instead, but if they choose aggregation they must show the number of assignments inside the pool when RIPE NCC audits them or considers another allocation. Those counts let the registry calculate the HD ratio, its measure of how efficiently the allocated space has been assigned. An assignment larger than /48 must be registered separately as ASSIGNED. The contract is precise: public data can be coarse; the arithmetic behind a resource request must still stand up.

The authors also named the price of this compromise. Publishing assignment-size can expose clues about a provider's customer base and potentially assist targeted attacks. Hiding individual customer names is not the same thing as hiding the structure of the business. The proposal chose a level of disclosure that was useful for registry verification and stopped short of a public roll call. That choice mattered when IPv6 broadband assignments were heading from small experiments toward routine service.

The RIPE archive dates acceptance to 3 February 2011. RIPE-513 followed on 7 February, and a RIPE NCC implementation notice said by 15 February that the feature was in the database and relevant processes. This is a small story about a database field with a large habit behind it: asking what a registry truly needs to know before requiring every operator to publish the rest.

RIPE originals