BGP and registry intelligence — RPKI origin validation (is this announcement authorised?), RDAP registry ownership and abuse contacts, PeeringDB interconnection data, RIPEstat routing status and prefix visibility, RIPE Atlas anchors. Use when investigating an unfamiliar prefix or ASN, checking whether a BGP announcement is RPKI-valid, finding who owns address space or who to report abuse to, or determining what an AS announces and where it peers.
BGP and registry intelligence — RPKI origin validation (is this announcement authorised?), RDAP registry ownership and abuse contacts, PeeringDB interconnection data, RIPEstat routing status and prefix visibility, RIPE Atlas anchors. Use when investigating an unfamiliar prefix or ASN, checking whether a BGP announcement is RPKI-valid, finding who owns address space or who to report abuse to, or determining what an AS announces and where it peers.
Credentials: none. Every source is a public unauthenticated API
Mode: read-only. There is no write path
The one rule that matters most
RPKI not-found is NOT invalid.
Most of the internet has no ROA. Unsigned address space is the overwhelmingly common case, not an
anomaly. If you report not-found as a hijack, a misconfiguration, or a security finding, you will
generate false incidents at scale and the operator will stop trusting you.
State
Means
Actionable?
valid
A ROA authorises this origin AS
No — healthy
invalid + reason: as
A ROA covers this prefix; a different AS is authorised
Yes — possible hijack
invalid + reason: length
Correct AS, but the prefix is more specific than the ROA permits
Yes — usually a local misconfiguration, different fix
not_found
No ROA exists. RFC 6811 calls this NotFound
No — the normal case
The two invalid reasons are different findings. as means someone else is announcing your space;
length usually means you announced a /24 under a /22 ROA. Never collapse them.
validation_unavailable is not not_found. If the validator is unreachable you get the former, and
the RPKI state is genuinely unknown. Do not infer "unsigned" from "could not ask", and do not fall back to
guessing from routing or registry data.
Tools (10, all read-only)
Tool
Answers
rpki_validate
Is this prefix legitimately announced by this AS? Nothing else in NetClaw does this
registry_lookup
Who is this IP/prefix/ASN allocated to?
registry_abuse_contact
Who do I report abuse to?
routing_as_overview
Who holds this ASN; is it announced at all?
routing_announced_prefixes
What does this AS announce, and how visible is it?
peering_network
Network type, traffic profile, peering policy
peering_presence
Which IXPs and facilities?
atlas_anchors
Atlas anchors in a country (stable measurement targets)
atlas_probe_count
Can this AS be measured from inside?
resource_report
Everything about a resource, one call, per-section sourcing
Three more "this is not what you think it is"
Registry data is allocation, not routing. RDAP tells you who address space is registered to. It says
nothing about who is announcing it. Use routing_announced_prefixes for that. Treating an RDAP holder
as a routing fact is the same category error as treating FortiManager intent as device state.
PeeringDB is self-reported. No record means nobody filled in the form — not that the network does
not peer. Many networks peer extensively and publish nothing.
Visibility is RIPE's collectors, not the internet. Low visibility has legitimate causes: scoped
announcements, no-export, anycast, a recent change. The tool will never call it a leak, and neither should
you without more evidence.
caveats carries the statements above — read them, they are not decoration. resource_report gives each
section its own source; never attribute one section's data to another's origin.
Failures name the source that failed. source_unavailable is never "no record found" — a dead API and
an empty registry are different facts.
Workflow: an unfamiliar prefix appears
rpki_validate with the prefix and the origin AS. Validation is always of the pair.
Read the state carefully against the table above. If not_found, stop treating it as a problem.
registry_lookup — who holds it, and who to contact.
routing_announced_prefixes on the origin AS — is this consistent with what it normally announces?
peering_network — is this a transit provider, content network, or enterprise? It changes what "normal"
looks like.
Escalate only on invalid, and only after checking that the origin AS is what you think it is and the
ROA is current. This skill does not declare incidents — that is your judgement.
Workflow: who do I complain to?
registry_abuse_contact on the address.
If none is published, try the covering allocation with registry_lookup.
peering_network often has a technical contact when the registry does not.
Boundaries — which tool owns what
Question
Use
"Can the outside reach us? Measure from N countries"
globalping-external-checks (R8) — Globalping measures; this looks up
"Quick: who owns this traceroute hop, and where is it?"
gtrace-ip-enrichment — it owns ASN/geo/rDNS enrichment
"Is this software version vulnerable?"
nvd-cve / cisco-psirt — different plane entirely
"Is this routing legitimate?"
this skill
Those first two are load-bearing, not politeness. gtrace already does quick ASN and geolocation lookups
and this skill deliberately does not duplicate them (Principle VII). For general Atlas/Globalping probe
availability by location, or to run any measurement, go to Globalping.
Being a good citizen
RIPE NCC and PeeringDB are volunteer- and membership-funded. The server holds itself to ≤ 4 requests per
second per source, strictly serial — even resource_report runs its sections one after another.
Do not use these tools to enumerate, sweep, or bulk-harvest registry data. Look things up in service of
a specific operational question. The rate limiter enforces politeness mechanically; the judgement about
what to ask is yours.
Repeated lookups come from a cache with per-source lifetimes — RPKI 5 minutes, registry 24 hours — and a
cached answer says so and reports its age. Pass fresh=true when a ROA was just published and you need to
see through the cache.
Important rules
not_found is normal. Say so when you report it.
Keep the two invalid reasons apart. Different cause, different fix.
Never say hijack or attack. Report state and evidence; escalation is the operator's.
Private and reserved addresses are refused locally, before any request leaves — sending internal
addressing to a public registry is a disclosure even if the lookup fails.
Single validator. Results are never corroborated; they say so.
