Summary

  • A recent LACNIC Blog article distinguishes martian address space, bogons arising from resource status, and routes that are RPKI Invalid. The article is an expert contribution, and it expressly says that its views do not necessarily represent LACNIC’s.
  • The three labels can sensibly appear in filtering policy, but they do not draw their meaning from one source or one timestamp: special-purpose registry data, resource-status data, and validated-route data each change on their own terms.
  • RFC 6811 defines an Invalid route in relation to the validated ROA payload available to a relying party; it does not prescribe one operational response, and it does not make origin validation a substitute for path validation.
  • A useful aggregate can remain private and safe if its receipt preserves the category, source version, retrieval time, scope, direction and local action without exposing a prefix, customer, peer, configuration or contact.

One filter decision, three factual questions

The temptation to place martians, bogons and RPKI Invalids in a single operational bucket is understandable. An ingress policy may need a compact way to count work, set a capacity alert or explain why a route did not proceed. LACNIC’s recent blog article on the terms is useful precisely because it starts by separating them. It describes martians as addresses reserved for special purposes, other bogons as space whose allocation status matters, and RPKI Invalids as routes whose origin authorization does not match the relevant ROA conditions.

That distinction should not be inflated into a claim about LACNIC policy, a regional condition, or the practice of any network. The author, Sergio Kleiman, identifies the piece as a personal contribution and says at its close that the views do not necessarily represent LACNIC’s. Nor does the article report a regional incident, a current count, an identified prefix, or a common rule that operators must use. Its value is narrower and more durable: it gives an operator-facing vocabulary for asking what kind of fact a filter decision was based on.

Those facts have different clocks. The first clock is the IANA IPv4 Special-Purpose Address Registry. Its entries define properties of special-purpose space. A filter based on such a property needs to be able to say which registry version or retrieval time it relied on. The relevant question is not merely whether a packet met a rule; it is whether the rule was evaluated against the applicable special-purpose record at that time and for the address family in question.

The second clock concerns ordinary resource status. The blog explains that a bogon can reflect space that has not been delegated or assigned, and that this condition changes as registries make resources available or delegate them. A useful operational record therefore needs a resource-status snapshot and a time. A list generated yesterday can be a poor witness for an event today; a later allocation can make an earlier filter result understandable without making it retrospectively wrong. “Bogon” is not a timeless property of a prefix in the same way that a syntactic error is.

The third clock is the validation view used for RPKI origin validation. RFC 6811 defines Invalid in relation to validated cache payload: a route may be covered by a validated ROA payload while no valid route-origin authorization matches its prefix and origin AS. The same RFC notes that different local caches can differ according to when they were updated or what they fetched. It also makes two boundaries explicit. The policy action after a validation result is local, rather than commanded by the protocol, and origin validation does not perform path validation.

These are not pedantic distinctions. A flat dashboard label such as “bad routes blocked” can give an operator a useful total, while still being unable to answer a basic review question: which source changed, when was it observed, and what local rule turned that observation into an action? The answer may be different for a special-purpose range, an allocation-status list and a route-origin result. A single count cannot establish that the cases shared a cause, that they were equally risky, or that they deserve the same repair path.

The missing object is a receipt, not a larger blacklist

The response is not to expose routing tables, customer records, peer names, tickets or configuration fragments. Those disclosures could create new operational and privacy risks without improving the explanation. The response is a small, privacy-preserving receipt for an aggregate.

For each category, that receipt can record the data source and version or snapshot identifier; the time of retrieval and the observation time; IPv4 or IPv6 scope; inbound or outbound direction; a broad neighbor-role class; the local action and known exception class; an aggregate count; and the responsible repair or correction channel. It can separately state when a list is regenerated or when a validation cache is refreshed. Nothing in that list requires publishing a prefix, an ASN, a customer, a peer, a device, a contact, or a rule stanza.

Such a receipt would also stop a category error from becoming an attribution claim. A resource-status mismatch might call for a list refresh; an RPKI Invalid may invite investigation of an authorization relationship or a local policy exception; special-purpose space calls for a different check again. The public evidence should preserve that difference even if the operational screen starts with one aggregate row.

Sources