AICENT.COM
← Back to Blog

Where RPKI comes from: the name that collides

2026-10-18 · RPKI
Where the Names Come From · AICENT-003 · Sources: AICENT-003 RPKI (naming note) · IETF RFC 6480 / RFC 8205 / RFC 9455 · Pillar: AICENT-003, the Immunity Layer

Every previous entry borrowed something that could not object: a Greek compound, a cycad with a convention listing, two Chinese classics, a four-letter space nobody had claimed. This one borrowed a name that is running. The IETF's RPKI — Resource Public Key Infrastructure — is specified in RFC 6480 and deployed daily by the regional internet registries. That changes the task. Where the other entries could end in a definition, this one can only end in a disclaimer, and it has to be written in a way that says both halves at once.

AICENT-003 · the Immunity Layer (in-band) Watermark Sentinel isolation retroactive invalidation intent pulses in passed
Figure 1: the immunity layer. Pulses travel along the lane; the sentinel inspects them in parallel with execution; the marked one is pulled into isolation while the healthy ones pass. None of this is a scheme of its own — it happens inside the sealed envelope.

The layer, first

AICENT-003 is the Immunity Layer. The specification's own words: "the active white blood cells responsible for identifying and neutralizing logical and temporal pathogens at wire-speed." Its first organ is the Watermark Sentinel, which injects and verifies 128-bit Parallel Tensor Watermarks so that every pulse is checked against the AID that claims it.

What it collides with

The IETF got there first, and it is not a relic. RPKI = Resource Public Key Infrastructure: an architecture for authorizing route origins, specified in RFC 6480, with BGPsec in RFC 8205 and a deployability refinement in RFC 9455 (which recommends one IP prefix per ROA). It is operated in production by the regional internet registries. Compare that with the borrowings in this series so far — an ecological term, a cycad, two classics, a defunct web-counter service — and the difference in kind is obvious: this one has an operator, a conformance target, and a name that is in use every day.

The only honest move: a disclaimer with both halves

Our specification carries the naming note verbatim:

"RPKI here is not the IETF Resource Public Key Infrastructure; it is an AI-immunity layer inspired by the ROA attestation model (RFC 6480 / 8205 / 9455 are cited as prior art, not as conformance targets)."

Both halves are load-bearing. The first half — not — stops the name from borrowing an authority it has not earned. The second half — inspired by, with the RFCs named as prior art — keeps the idea we actually took: that a claim about who may originate something should be checkable against an attestation, not asserted by whoever shouts loudest. Write only the first half and you disown the borrow; write only the second and you are implying conformance you do not have.

Why there is no rpki:// scheme

The same note settles the second question a colliding name raises — whether we would go and register it. We would not, and we did not: the immunity layer is in-band. No rpki:// URI scheme is sought or used; the defence travels inside the sealed RTTP envelope rather than as a scheme of its own (decision of 2026-09-19).

That is also why the two-pillar story still reads cleanly: rttp delivers, iqa vouches, rpki defends in-band. Two schemes were registered because two of the three needed to be addressable; the third does not, so it stays inside.

outer · Aicent RPKI — the Immunity Layer (in-band, no scheme) asks: may this AID emit this intent? is the watermark right? has the tensor drifted? organs: Watermark Sentinel, parallel tensor watermarking, isolation inspired by the ROA attestation model · prior art, not conformance inner · IETF RPKI — Resource Public Key Infrastructure asks: may this AS originate this prefix? (RFC 6480 / 8205 / 9455) operated in production by the regional internet registries
Figure 2: one name, two layers. The question on the outside is about an AID and an intent; the question on the inside is about an AS and a prefix. Same shape of question, different object — which is exactly why the borrowing has to be labelled rather than left to the reader.

What we do not claim

We do not implement the IETF RPKI, do not replace it, and do not claim conformance with it. We do not seek a rpki:// scheme. And we do not present RPKI as a third pillar of the addressing story — it is the immunity layer, and the immunity layer is in-band.

Every entry in this series has ended with what the name can be checked against. This one ends with what the name must not be taken for. Next is AICENT-004, the blood layer — where the problem is not collision but alignment, and where the name has to answer for a percentage.