Summary

  • In an inet6num object with status: AGGREGATED-BY-LIR, assignment-size states the prefix length of the individual End User assignments represented by that aggregate.
  • The difference between the aggregate prefix and the assignment size yields a number of possible slots. It does not establish how many slots are allocated, in use, online, advertised, or associated with distinct subscribers.

Precise arithmetic, bounded evidence

RIPE NCC’s current guidance gives a clear example: an inet6num covering a /46, marked AGGREGATED-BY-LIR and carrying assignment-size: 56, describes an aggregate that can contain 1,024 /56 assignments. The number follows from ten additional prefix bits. It is useful for understanding the registration design and the maximum subdivision represented by the object.

The same example does not report 1,024 active customers. Some potential /56 slots may never have been assigned; some may have been returned, reserved, staged, or temporarily unused. One customer may receive more than one assignment over time, and an assignment may serve a household, business, access node, lab, pool, or other deployment unit. The registry object supplies no session counter, billing ledger, device inventory, address-usage telemetry or liveness test.

That boundary is the heart of the field. assignment-size is a statement about granularity within one registration object, not a census of the people or systems behind it.

Why the aggregate exists

RIPE-513 introduced AGGREGATED-BY-LIR and assignment-size so Local Internet Registries could document multiple same-sized IPv6 End User assignments with a less-specific object. The policy explains that efficiency calculations need the number and size of assignments, while individual personal data need not be published. Aggregation therefore serves a deliberate data-minimisation and registration function.

The alternative is to register individual assignments with status: ASSIGNED. RIPE NCC explains that such records can identify individual End Users and carry different contact information. An aggregated object intentionally does not provide that per-assignment catalogue. Analysts should not reconstruct a missing customer list by treating every mathematically available sub-prefix as an observed customer.

The database enforces structural rules. The assignment size must be longer than the containing prefix. Only one assignment-size value may appear in an object, and the field is required with AGGREGATED-BY-LIR. Different assignment sizes are represented through separate objects. These checks make the registered granularity internally coherent; they do not observe deployment.

Separate registration from network state

Nothing in assignment-size identifies a BGP origin or shows whether the aggregate or any more-specific prefix is advertised. It does not establish RPKI authorisation, route-object creation rights, reachability, traffic volume, latency, access technology, equipment ownership or physical geography. Those claims require sources designed for those layers: time-aligned BGP observations, applicable RPKI and IRR records, active measurements, operator evidence, and commercial or legal records where relevant.

Nor does the field identify who can alter the database object. RIPE object templates place maintainers, contacts, organisation references, routing maintainers and assignment size in separate attributes. A correct analysis preserves those distinctions instead of allowing a numeric field to borrow authority from neighbouring fields.

A reproducible reading

Record the exact queried prefix, the containing inet6num key, its status, assignment-size, retrieval time and source. Calculate the theoretical slot count explicitly as 2^(assignment-size − aggregate-prefix-length), and label the result “possible same-sized assignments represented by the aggregate.” Do not label it customers, active lines, households or deployed prefixes.

If a subscriber or utilisation estimate is needed, obtain time-bounded operational evidence and document its coverage. Compare it with the registry snapshot rather than substituting one for the other. A later change to the aggregate, status or assignment size is a registration event that warrants investigation; it is not, by itself, proof of a simultaneous change in live service.

Sources