Summary

  • A RIPE NCC WHOIS test added on 10 September expects both AS64495-AS131071 and AS131070-AS131072 to be reserved, although the first extends one number below the configured interval and the second extends one number above it.
  • The implementation uses any range overlap, and the RDAP mapper converts that Boolean result into one object-level status. The status is therefore a warning about the block, not proof that every ASN in it has the same IANA disposition.

The revealing numbers sit at opposite ends of the same interval. In the new test, 64496-131071 is configured as reserved. The exact span passes. So does AS64495-AS131071, which reaches one number below it. And so does AS131070-AS131072, which reaches one number beyond the upper edge.

Those are not typographical curiosities. In IANA’s current registry, AS64495 is at the end of a range assigned to RIPE NCC, while AS64496 begins documentation space. At the other end, AS131071 is reserved and AS131072 begins a range assigned to APNIC. The two test blocks are mixed at the boundary, yet each receives the same answer: reserved.

The reason is explicit in the implementation. ReservedResources.isReservedAsBlock parses the candidate key into a numeric interval and checks whether any configured reserved range overlaps it. It does not ask whether the reserved range contains the whole candidate, nor whether every number in the candidate is reserved. RdapObjectMapper then uses that result to select RESERVED rather than ACTIVE for an AS-BLOCK object.

This is a defensible conservative choice. A containment-only test would call a mixed object active even when it swallowed a reserved core. For a guard deciding whether a block deserves special treatment, any overlap is often the safer predicate. The trouble begins only when the resulting label travels farther than the predicate that produced it.

An RDAP consumer may store the object key, type and status together. A less careful pipeline may explode the range into individual ASNs and copy the block’s one status onto every row. At that point AS64495 or AS131072 can inherit “reserved” from their neighbour, even though IANA places them in assigned ranges. The source review found no evidence that a named consumer does this. The risk is structural: a coarse object label can be mistaken for constituent truth once the boundary and rule provenance are discarded.

RIPE Database documentation gives AS-BLOCK objects a specific administrative role. They divide AS-number space among registries or mark ranges as reserved; their parent-maintainer fields also help control who may create aut-num objects beneath them. Only RIPE Database administrators create the blocks. That context explains why a conservative classification may be useful, but it does not turn the mapper’s status into an allocation decision, a BGP-origin verdict or a statement about reachability.

The timing needs the same discipline. Edward Shryane’s 10 September commit adds 53 lines of tests and no production implementation change. The overlap method and mapper already exist in the reviewed tree. The most recent captured tag, WHOIS 1.124.1, was published on 31 August, before the test commit. That proves the test is newer than the tag; it does not prove when the underlying behaviour entered production, whether the test commit has been deployed, or whether a mixed-boundary AS-BLOCK exists in the live database.

The practical reading is therefore narrow. RIPE NCC has now made the boundary semantics executable and reviewable: overlap is enough. The useful next step is not to replace that conservative rule with a blunter one. It is to preserve the intersection that caused the result—candidate range, matched reserved interval, registry revision and mapper version—so downstream systems can distinguish “this object touches reserved space” from “every number in this object is reserved.”

Sources