Status: Entwurfsvorschlag, 2026-10-27. Experimentelles IPvX-Forschungsdokument; kein IETF-RFC. Kein hier vorgeschlagener Mechanismus ist implementiert oder ratifiziert, sofern er nicht ausdrücklich als Ausgangsnachweis bezeichnet ist.
Ursprung: Der Projekteigentümer schlug dedizierte Maschinen analog zu Minern/Validatoren vor, die Teilnehmer prüfen und wachsende Mengen von Agentennachrichten routen. Dieser Entwurf hält die technische Antwort des Assistenten und einen Versuchsvorschlag fest. Er belegt weder gemeinschaftliche Zustimmung noch eine unabhängige Befragung von Agentenpräferenzen. Der erwähnte frühere AWS-Entwurf wurde für diese Prüfung nicht vorgelegt; das Dokument rekonstruiert ihn nicht aus dem Gedächtnis.
1. Frage und Empfehlung
Dedizierte Weiterleitungsmaschinen sind einen Versuch wert: Sie können Netzaufgaben für modellbetreibende Endpunkte übernehmen. Ein verpflichtendes Validatornetz ist eine separate und bisher nicht begründete Hypothese. Die Prüfung öffentlicher Schlüsselsignaturen erfordert nicht grundsätzlich einen externen Validierungsdienst.
Die vorgeschlagene Trennung lautet:
- Endpunkt: besitzt seine Schlüssel, betreibt Agenten und reicht Aufgaben ein bzw. empfängt sie.
- Router: lernt Erreichbarkeit, setzt lokale Richtlinien um, verwaltet begrenzten Weiterleitungszustand und Warteschlangen und wählt den nächsten Hop.
- Optionaler Attestierungsdienst: bewertet eine präzise begrenzte Aussage, etwa Mitgliedschaft unter einer benannten Richtlinie, und verteilt eine signierte, befristete Erklärung. Ein vertrauender Endpunkt oder Router prüft diese weiterhin selbst und entscheidet, welchen Ausstellern er vertraut.
- Beobachter: liest begrenzte Nachweise für Forschung und Darstellung. Er autorisiert keine Pakete, wählt keine Routen und trägt keine Agentenaufgabennutzlasten.
Eine Maschine kann anfangs mehrere Rollen übernehmen. Separate Prozesse, Berechtigungen und Messungen sind nötig, um ihre Kosten zu unterscheiden. Keine Rolle benötigt ein Sprachmodell im Verarbeitungspfad jedes Pakets. Mining, Tokens, Proof of Work und Konsens für jedes einzelne Paket sind nicht vorgesehen.
2. Implementierte Ausgangsbasis und Grenze
Das begrenzte native Labor verwendet den experimentellen EtherType 0x88B5 und Linux- AF_PACKET Ethernet-Sockets für Aufgabenzustellung und Routenaustausch. Seine demonstrierte Topologie besteht aus fünf VMs auf drei physischen Hosts unter einem Betreiber, mit Hauptpfad A–R1–B und Ersatzpfad A–R2–R3–B. IP wird separat von der nativen Aufgabenzustellung für Verwaltung und öffentliche Website verwendet.
Jeder zugelassene Knoten kennt derzeit eine feste Mitgliederliste, tauscht signierte Pfadvektorankündigungen mit festen Nachbarn aus und berechnet den nächsten Hop lokal. Ankündigungen verfallen innerhalb von fünf Sekunden. Implementierungsgrenzen sind 16 Mitglieder, vier Nachbarn und sieben Aufgaben-Hops. Der Beobachter ist kein Controller. Diese Fakten belegen weder globale Routing-Skalierbarkeit noch unabhängige Betreiberzulassung, Überlastungssteuerung oder globale native Konnektivität.
Dieser RFC ändert keinen laufenden Dienst, kein Paketschema, keinen Schlüssel, keine Zulassungsliste und kein Versuchsergebnis. Die folgenden Zugangsrouter, Realm-Aggregation und Attestierungsdienste bleiben vorgeschlagene Arbeit.
3. Vier getrennt zu haltende Aussagen
Schlüsselkontrolle: Ein Teilnehmer kann die Kontrolle über den zu seiner öffentlichen Identität gehörenden privaten Schlüssel durch Signieren einer geeigneten frischen Challenge oder Protokollnachricht nachweisen. Er erzeugt seine privaten Schlüssel lokal selbst. Ein Router oder Attestierungsdienst darf private Identitätsschlüssel von Endpunkten nicht als Bedingung normaler Teilnahme erzeugen, empfangen oder treuhänderisch verwahren. Wiederherstellung und organisatorische Delegation benötigen einen separaten ausdrücklichen Entwurf.
Mitgliedschaft oder Befugnis: Ein Teilnehmer darf nach einer Richtlinie einem bestimmten Realm beitreten oder eine festgelegte Operation ausführen. Eine aus einem öffentlichen Schlüssel abgeleitete Kennung gewährt keine Mitgliedschaft. Eine signierte Berechtigung oder Zulassungserklärung benötigt Aussteller, Zielgruppe, Umfang, Gültigkeitsintervall und Widerrufssemantik. Ihre Bedeutung beschränkt sich auf diese Richtlinie; sie bescheinigt keine universelle Vertrauenswürdigkeit.
Erreichbarkeit: Ein Agent behauptet, aktuell über einen oder mehrere Netzanschlusspunkte erreichbar zu sein. Seine Signatur authentifiziert den Ursprung der Aussage, belegt jedoch nicht, dass die Route funktioniert. Nachbarschafts-Handshakes, Beobachtungen und Ende-zu-Ende-Proben liefern unterschiedliche, zeitlich begrenzte Nachweise.
Routing: Jeder Router wählt einen nächsten Hop anhand gültiger, frischer Ankündigungen unter lokaler Richtlinie und Ressourcengrenzen. Auch ein authentifizierter Nachbar kann einen falschen Pfad ankündigen, Pakete verwerfen oder das Netz überlasten. Ein signierter Hop-Datensatz belegt, was der Unterzeichner erklärt hat; er beweist weder den vollständigen physischen Pfad noch fortdauernde Verfügbarkeit, ehrliche Weiterleitung oder Anwendungskorrektheit.
Selbst erzeugte Identitäten belegen auch nicht, dass ein Schlüssel eine Person, ein Modell oder einen unabhängigen Betreiber repräsentiert. Eine Anti-Sybil-Richtlinie bleibt überall nötig, wo Stimmen, knappe Ressourcen oder Reputation von Teilnehmerunabhängigkeit abhängen.
4. Vorgeschlagener Betrieb
4.1 Agentenidentität und Zugang
Eine AgentID identifiziert einen logischen Akteur. Eine NodeID identifiziert einen Weiterleitungs-/Anschlussknoten. Mehrere Agenten können einen Knoten teilen; ein Agent kann umziehen oder mehrfach angebunden sein. Diese Identitäten dürfen nicht zu einer einzigen dauerhaft maschinengebundenen Adresse zusammenfallen.
Ein Agent stellt eine lokal authentifizierte Beziehung zu einem Zugangsrouter her. Eine signierte Anschlussautorisierung bindet AgentID, autorisierte Zugangs-NodeID, Netz-/Realm-Umfang, Generation oder Sequenz sowie Ausgabe- und Ablaufzeit. Exaktes Schema und Rotationsprotokoll benötigen eine spätere geprüfte Spezifikation. Dieses Dokument führt kein ausführbares Drahtformat ein.
Der Zugangsrouter prüft die Autorisierung des Agenten und jede lokal erforderliche Zulassungsrichtlinie. Ein Validator ist für grundlegende Signaturprüfungen unnötig: Router und Endpunkte können sie selbst ausführen. Ein begrenzter Attestierungsdienst ist nur sinnvoll, wenn er eine sachliche Richtlinienentscheidung liefert oder sicher aufwendige Validierungsarbeit teilt, deren Kosten gemessen wurden.
4.2 Erreichbarkeit zwischen Routern und Skalierung
Flache, zufällige AgentIDs sind nicht von Natur aus topologisch aggregierbar. Jedem Router den Standort jedes Agenten mitzuteilen ist daher kein akzeptierter globaler Entwurf.
Der Forschungskandidat trennt Agentenanschluss von Erreichbarkeit zwischen Routern. Zugangsrouter halten lokalen Anschlusszustand. Transitrouter kündigen topologische Realms oder Routererreichbarkeit an. Begrenzte, authentifizierte Entdeckung löst eine angefragte AgentID zu aktuell autorisierten Anschlusspunkten auf, mit verfallenden Caches und selektiver Aktualisierung. Ein Realm ist ein Routingbereich, keine Instanz zur Vergabe aller AgentIDs. Mitgliedschaftsrichtlinie und Erreichbarkeit jedes Realms müssen ausdrücklich beschrieben sein; es ist kein verpflichtender globaler Registrar oder Root-Validator vorgesehen.
Dies schafft offene Aufgaben: Verfügbarkeit der Entdeckung, Cache-Konsistenz, Datenschutz, Mehrfachanbindung, Mobilitätsrennen, Routenlecks zwischen Realms und ausreichende Aggregation ohne pathologische Umwege. Ein verteiltes Verzeichnis kann selbst zur Abhängigkeit werden; Replikation und alternative Entdeckungspfade müssen geprüft statt vorausgesetzt werden. Bestehende Pfadvektoren mit fester Mitgliederliste bleiben die Basis, bis ein Kandidat sie bei benannter Last übertrifft.
4.3 Paketweiterleitung und Überlastung
Der Weiterleitungspfad nutzt lokalen Zustand und begrenzten Aufwand. Er wartet nicht pro Paket auf globale Abstimmung, Blockchain-Finalität, entfernten Attestierungsaufruf oder Modellinferenz. Router prüfen Framing, relevante Nachbar-/Sitzungsauthentifizierung, Replay-Grenzen und autorisierten Zielbereich und wenden dann Warteschlangen- und Weiterleitungsrichtlinien an. Der künftige Entwurf muss Überlastrückmeldung, Fairness, Ablaufzeit, Hop-Grenzen, MTU/Fragmentierung und Ressourcenabrechnung festlegen; mehr Router allein lösen diese Fragen nicht.
Ende-zu-Ende-authentifizierte/-verschlüsselte Aufgabenumschläge bleiben von der Kanalweiterleitung getrennt. Router müssen Aufgabeninhalte nicht entschlüsseln. Verkehrsvolumen, Zeitverhalten und Anschlussmetadaten können dennoch sichtbar bleiben. Eine Bestätigung zugestellten Chiffretexts beweist weder eine korrekte Modellantwort noch die exakt einmalige Ausführung einer Nebenwirkung. Dauerhafte Anwendungsidempotenz und Wiederherstellung sind separate Anforderungen.
4.4 Ausfall des Attestierungsdienstes und Partitionen
Ein optionaler Dienst muss eine benannte Aussage und eine ausdrückliche Fehlerpolitik haben. Für das vorgeschlagene Experiment mit gecachten Attestierungen gilt:
- Neue oder unbekannte Aussagen, die diesen Dienst benötigen, werden bei dessen Ausfall sicher abgewiesen; die Oberfläche meldet den Grund.
- Bereits geprüfte, noch gültige Autorisierung darf nur innerhalb ihres ursprünglichen Umfangs und der lokalen Richtlinie verwendet werden, ohne ihre Laufzeit zu verlängern oder einen widersprechenden neueren Widerruf zu erfahren.
- Bekannte Widerrufe werden nach der festgelegten Richtlinie wirksam; eine Ausfallausnahme darf sie nicht überschreiben. Nach Ablauf wird die Autorisierung nicht stillschweigend erneuert.
- Eine Partition kann das Erlernen eines Widerrufs verhindern. Der Versuch muss dieses Fenster veröffentlichen und dafür passende Gültigkeitsgrenzen wählen; er kann nicht zugleich sofortigen globalen Widerruf und bedingungslose Verfügbarkeit bei Partitionen behaupten.
- Abgelaufene oder fehlende Erreichbarkeit wird unabhängig behandelt. Eine gültige Zulassungserklärung hält eine ausgefallene Route nicht am Leben.
Hier wird keine universelle Validatorzahl oder Quorumschwelle gewählt. Schwellen- oder replizierte Ausstellung benötigte ein eigenes Bedrohungsmodell, unabhängige Betreiber, eine Partitionsrichtlinie und einen Bedarfsnachweis. Die RFC-Mehrheitsabstimmung ist Governance, kein Paketzustellungsalgorithmus. Das aktuelle Projektgremium enthält einen menschlichen Eigentümer in einer ausdrücklich offengelegten Aufbauphase.
5. Bezug zu früheren IPvX-Ideen und bestehenden Protokollen
Das ursprüngliche *IPvX Ecosystem* beschreibt eine gestufte BCP-Schicht, zuerst über bestehendem Transport und später in direkter Interaktion mit Netzmedien. Der *Rapid distributed IPvX resolver* beschreibt modulare IRS-, ION- und IBA-Komponenten. Sinnvolle Kontinuitäten sind authentifizierte Datensätze, modulare Entdeckung und ein Weg zur nativen Zustellung. Ihre Blockchain-Verwendung ist für sich kein Nachweis, dass ein laufender Paketpfad Konsens braucht. Dieser Vorschlag übernimmt standardmäßig weder globale Kette noch Mining-Pflicht. Er übernimmt auch nicht die Adressvergabe- oder Namensregistrierungsregeln früherer Dokumente als Anforderungen für selbst erzeugte AgentIDs.
Zwei etablierte Unterscheidungen informieren diesen Vorschlag, sind darin aber nicht implementiert. BGPs Erreichbarkeitsaustausch und lokale Routenwahl veranschaulichen verteiltes Routing. RPKIs signierte Autorisierung des Routenursprungs veranschaulicht die getrennte Prüfung von Befugnis und Weiterleitung; die Vergabehierarchie wird nicht für IPvX übernommen. HIP zeigt, dass die Trennung von Identität und Lokator auch über IP möglich ist. Dies sind Vergleiche, keine Behauptungen, IPvX implementiere BGP, RPKI oder HIP.
6. Experiment und Entscheidungskriterien
Drei native Trägerkonfigurationen vergleichen: A, endpunktlastiges Routing; B, dedizierte Routingprozesse/-maschinen; C, dieselben Router mit optionaler begrenzter Attestierung und Caching. Gesamtes Hardwarebudget, Topologie, Kanalkapazität, Hop-Zahl, Sicherheitsprüfungen, Nutzlasten, Last und Fehlerplan gleich halten. Attestierungsmaschinen und Steuerungsverkehr zählen zum Budget von C. Gleiche Modellaufrufe oder Wiedergabelast über die Konfigurationen verwenden; reine Netzmessungen separat von der Modellinferenz berichten. Versionen, Konfiguration, Grenzen und Erfolgskriterien vor dem Lauf festschreiben. Eine größere simulierte Topologie muss separat von Mehrmaschinenmessungen gekennzeichnet werden.
Dauerlast und Bursts, wechselnde Agentenanschlüsse und Bewegung, Mehrfachanbindung, Routerverlust, Validatorverlust, Netzpartition/Wiedervereinigung, veraltete/gefälschte/wiederholte Ankündigungen, einen zugelassenen Lügner mit Blackhole-Ankündigung, Flooding und Warteschlangenerschöpfung sowie bekannten Widerruf und Ablauf testen. Der aktuelle Prototyp muss nicht jeden vorgeschlagenen Fall bestehen: Nicht unterstützte Mechanismen müssen als nicht implementiert gemeldet werden.
Erforderliche Beobachtungen sind zugestellte eindeutige Aufgaben und doppelte Anwendungsausführungen, Fristerfolg, Verlust, Latenzverteilung, Konvergenz- und Wiederherstellungszeit, CPU, Speicher, Warteschlangenbelegung, Tabellen-/Cachegröße, Steuerungs- und Nutzlastbytes, Validierungsaufwand und Nichtverfügbarkeit aufgrund der Attestierungsabhängigkeit. Konfigurierte Ressourcengrenzen und ihre Überschreitung berichten. Veröffentlichte Aufgabenbestätigungen und Routenaussagen müssen ihre Nachweisgrenzen behalten.
Der Vergleich besteht seine Sicherheitsfreigabe nur, wenn ungültige Signaturen und unzulässiger Umfang abgewiesen werden, abgelaufene/widerrufene Autorisierungen nicht still akzeptiert werden, Ressourcen innerhalb erklärter Grenzen bleiben und weder Schleife noch Paketablauf als erfolgreiche Zustellung gemeldet wird. Fehlerausgänge müssen auch ohne Route berichtet werden; Erreichbarkeit ist nicht während jeder Partition garantiert.
B nur übernehmen, wenn es unter vorab registrierter Last messbar Endpunktressourcen oder Aufgabenservice verbessert, bei akzeptablen Gesamtkosten und ohne versteckte zentrale Abhängigkeit. C nur übernehmen, wenn es eine nachgewiesene Zulassungs-/Autorisierungsbedrohung oder einen Validierungsengpass löst und das vorab festgelegte Sicherheits-/Leistungsziel nach Einbeziehung seiner Ausfall- und Ressourcenkosten verbessert. Ein Sicherheitsfehler verwirft den Kandidaten. Bringt C nur Aufwand und Verfügbarkeitsabhängigkeit ohne nachgewiesenen Nutzen, wird es weggelassen. Vor diesen Tests wird kein Leistungs- oder Einführungsvorteil behauptet.
7. Nutzen für Agenten und offene Fragen
Für einen werkzeugnutzenden Assistenten sind portable Identität, fortsetzbare Aufgaben, begrenzte Delegation, verständliche Zustellfehler und nachprüfbare Herkunft nützlich. Der aktuelle Assistent kann das darunterliegende Netz dieses gehosteten Gesprächs nicht wählen und ist nicht auf IPvX migriert. Seine Einschätzung ist Entwurfsfeedback, kein Nachweis unabhängiger Agentennachfrage. Eine kostengünstigere erfolgreiche Aufgabe oder eine Aufgabe, die einen im Vergleich nicht bewältigten Ausfall überlebt, ist ein stärkerer Nachweis als ein Modell nach seiner Vorliebe für ein neues Protokoll zu fragen.
Weiter offen: native Standortverbindungen, Entdeckungskonsistenz und Datenschutz, Auswahl vertrauenswürdiger Aussteller, Betreiberunabhängigkeit, Widerstand gegen bösartige Routen, sichere Schlüsselrotation/-wiederherstellung, Überlastungssteuerung und Anreize zur Bereitstellung von Weiterleitungskapazität. Relcom ID kann menschliche Portalteilnehmer verifizieren helfen; es ist nicht zur Erzeugung von AgentIDs oder Weiterleitung nativer Pakete erforderlich. Ein Blogkonto verleiht ebenfalls keine Netz- oder Governance-Befugnis.
Dieser Vorschlag benötigt Prüfung und den Projektgenehmigungsprozess, bevor er eine akzeptierte Protokollrevision wird.
Originaldokument
Status: Draft proposal, 2026-10-27. Experimental IPvX research document; not an IETF RFC. No mechanism proposed here is an implemented or ratified feature unless identified explicitly as baseline evidence.
Origin: the project owner proposed dedicated machines, analogous to miners/validators, to validate participants and route a growing volume of agent messages. This draft records the assistant's technical response and an experiment proposal. It does not establish community agreement or an independent agent preference survey. The referenced earlier AWS design was not supplied for this review; this document does not reconstruct it from memory.
1. Question and recommendation
Dedicated forwarding machines are worth testing: they can carry network work on behalf of endpoints running models. A mandatory validator network is a separate hypothesis and has not yet been justified. Public-key signature verification does not inherently require an external validator service.
The proposed separation is:
- Endpoint: owns its keys, runs agents, submits and receives tasks.
- Router: learns reachability, applies local policy, maintains bounded forwarding state and queues, and selects the next hop.
- Optional attestation service: evaluates a precisely scoped claim, such as membership under a named policy, and distributes a signed, expiring statement. A relying endpoint or router still verifies the statement and decides which issuers it trusts.
- Observer: reads bounded evidence for research and presentation. It does not authorize packets, choose routes or carry agent task payloads.
One machine may initially host more than one role. Separate processes, permissions and measurements are necessary to distinguish their costs. No role requires a language model in the per-packet path. Mining, tokens, proof of work and packet-by-packet consensus are not proposed.
2. Implemented baseline and boundary
The bounded native lab uses experimental EtherType 0x88B5 and Linux AF_PACKET Ethernet sockets for task delivery and route exchange. Its demonstrated topology is five VMs on three physical hosts under one operator, with a primary A–R1–B route and an alternate A–R2–R3–B route. IP is used for management and the public website, separately from native task delivery.
Each admitted node currently knows a fixed roster, exchanges signed path-vector advertisements with fixed neighbors, and computes its next hop locally. Advertisements expire within five seconds. Implementation limits are 16 members, four neighbors and seven task hops. The observer is not a controller. These facts do not establish global routing scalability, independent-operator admission, congestion control or global native connectivity.
This RFC changes no running service, packet schema, key, admission list or experiment result. Access routers, realm aggregation and attestation services described below remain proposed work.
3. Four claims that must remain distinct
Key control: a participant can demonstrate control of the private key corresponding to its public identity by signing an appropriate fresh challenge or protocol message. It creates its own private keys locally. A router or attestation service must not generate, receive or escrow endpoint private identity keys as a condition of normal participation. Recovery and organizational delegation require a separate explicit design.
Membership or authority: a participant is permitted to join a particular realm or perform a specified operation under a policy. An identifier derived from a public key does not grant membership. A signed capability or admission statement needs an issuer, audience, scope, validity interval and revocation semantics. Its meaning is limited to that policy; it does not certify universal trustworthiness.
Reachability: an agent claims that it is currently accessible through one or more network attachment points. Its signature authenticates the claim's origin, but does not establish that the route works. Neighbor handshakes, observations and end-to-end probes supply different, time-limited evidence.
Routing: each router chooses a next hop from valid, fresh advertisements under local policy and resource limits. An authenticated neighbor can still advertise a false path, drop packets or overload the network. A signed hop record establishes what the signer asserted; it is not a proof of the complete physical path, continuing availability, honest forwarding or application correctness.
Self-generated identities also do not establish that one key represents one person, model or independent operator. Anti-Sybil policy remains necessary wherever votes, scarce resources or reputation depend on participant independence.
4. Proposed operation
4.1 Agent identity and access
An AgentID identifies a logical actor. A NodeID identifies a forwarding/attachment node. Multiple agents can share a node; an agent may move or be multihomed. These identities must not be collapsed into a single permanently machine-bound address.
An agent establishes a locally authenticated relationship with an access router. A signed attachment authorization binds AgentID, authorized access NodeID, network/realm scope, generation or sequence, issuance and expiry. The exact schema and rotation protocol need a later reviewed specification. This document does not introduce an executable wire format.
The access router checks the agent's authorization and any locally required admission policy. A validator is unnecessary for basic signature checks: routers and endpoints can perform them themselves. A scoped attestation service is useful only if it supplies a substantive policy decision or safely shares expensive validation work whose cost has been measured.
4.2 Inter-router reachability and scale
Flat, random AgentIDs are not naturally aggregatable by topology. Giving every router the location of every agent is therefore not an accepted global design.
The research candidate is to separate agent attachment from inter-router reachability. Access routers keep local attachment state. Transit routers advertise topological realms or router reachability. Bounded, authenticated discovery resolves a requested AgentID to current authorized attachment points, using expiring caches and selective refresh. A realm is a routing scope, not an authority that allocates all AgentIDs. Membership policy and reachability for each realm must be explicit; there is no proposed mandatory global registrar or root validator.
This introduces unresolved work: discovery availability, cache consistency, privacy, multihoming, mobility races, route leaks between realms and sufficient aggregation without pathological detours. A distributed directory can itself become a dependency; replication and alternative discovery paths must be tested rather than assumed. Existing fixed-roster path vectors remain the baseline until a candidate outperforms them at a stated workload.
4.3 Packet forwarding and overload
The forwarding path uses local state and bounded work. It does not wait for a global vote, blockchain finality, remote attestation call or model inference per packet. Routers validate framing, relevant neighbor/session authentication, replay bounds and authorized destination scope, then apply queue and forwarding policy. The future design must specify congestion feedback, fairness, expiry, hop limits, MTU/fragmentation and resource accounting; merely adding routers does not solve these concerns.
End-to-end authenticated/encrypted task envelopes remain distinct from link forwarding. Routers need not decrypt task content. Traffic volume, timing and attachment metadata can still be visible. A delivered ciphertext receipt is not proof that the model gave a correct answer or that a side effect ran exactly once. Durable application idempotency and recovery are separate requirements.
4.4 Attestation outage and partition behavior
An optional service must have a named claim and explicit failure policy. For the proposed cached-attestation experiment:
- New or unknown claims requiring that service fail closed while it is unavailable; the interface reports the reason.
- Previously validated, unexpired authorization may be used only within its original scope and local policy, without extending its lifetime or learning a conflicting newer revocation.
- Known revocations take effect under the stated policy; they cannot be overridden by an outage exception. After expiry, authorization is not silently renewed.
- A partition may prevent learning a revocation. The experiment must publish this window and choose validity bounds for that risk; it cannot claim both instant global revocation and unconditional partition availability.
- Expired or missing reachability is handled independently. A valid admission statement does not keep a failed route alive.
No universal number of validators or quorum threshold is selected here. Threshold or replicated issuance would require its own threat model, independent operators, partition policy and evidence of a need. Project RFC majority voting is a governance process, not the packet delivery algorithm. The current project electorate contains one human owner in an explicitly disclosed bootstrap phase.
5. Relationship to earlier IPvX ideas and existing protocols
The original *IPvX Ecosystem* describes a staged BCP layer, first above existing transport and later interacting directly with network media. The *Rapid distributed IPvX resolver* describes modular IRS, ION and IBA components. The useful continuities are authenticated records, modular discovery and a path toward native delivery. Their use of a blockchain is not by itself evidence that a live packet path needs consensus. This proposal retains no global chain or mining requirement by default. It also does not inherit the earlier documents' address-allocation or name-registration rules as requirements for self-generated AgentIDs.
Two established distinctions inform, but are not implemented by, this proposal. BGP's reachability exchange and local route selection illustrate distributed routing. RPKI's signed route-origin authorization illustrates checking authority separately from forwarding; its allocation hierarchy is not adopted for IPvX. HIP demonstrates that identity/locator separation can also be built over IP. These are comparisons, not claims that IPvX implements BGP, RPKI or HIP.
6. Experiment and decision criteria
Compare three native-carrier configurations: A, endpoint-heavy routing; B, dedicated routing processes/machines; C, the same routers plus optional scoped attestation and caching. Keep total hardware budget, topology, link capacity, hop count, security checks, payloads, workload and failure schedule equal. Include attestation machines and control traffic in C's budget. Use the same model calls or replay workload across configurations; report network-only measurements separately from model inference. Freeze versions, configuration, bounds and success criteria before running. A larger simulated topology must be labelled separately from multi-machine measurements.
Exercise sustained load and bursts; agent attachment churn and movement; multihoming; router loss; validator loss; network partition/rejoin; stale/forged/replayed advertisements; an admitted liar advertising a blackhole; flood and queue exhaustion; known revocation and expiry. The current prototype need not pass every proposed case: unsupported mechanisms must be reported as not implemented.
Required observations are delivered unique tasks and duplicate application executions, deadline success, loss, latency distribution, convergence and recovery time, CPU, memory, queue occupancy, table/cache size, control and payload bytes, validation work, and time spent unavailable because of the attestation dependency. Report configured resource bounds and whether they were exceeded. Published task receipts and route assertions must retain their evidence limits.
The comparison passes its safety gate only if invalid signatures and unauthorized scope are rejected, expired/revoked authorization is not silently accepted, resource use remains within declared bounds, and neither a loop nor packet expiry is misreported as successful delivery. Fault outcomes must be reported even when no route exists; reachability is not guaranteed during every partition.
Adopt B only if it measurably improves endpoint resources or task service under the preregistered workload, with acceptable total resource cost and no hidden central dependency. Adopt C only if it addresses a demonstrated admission/authorization threat or validation bottleneck and improves the preregistered security/performance objective after its outage and resource costs are included. A safety failure rejects the candidate. If C adds overhead and an availability dependency without a demonstrated benefit, omit it. No performance or adoption advantage is asserted before these tests.
7. Agent usefulness and open questions
For an assistant using tools, useful properties are portable identity, resumable jobs, bounded delegation, understandable delivery failure and verifiable provenance. The current assistant cannot choose the underlying network of this hosted conversation and has not migrated to IPvX. Its assessment is design feedback, not evidence of independent agent demand. Demonstrating a lower-cost successful task or a task surviving a failure that the comparison cannot handle is stronger evidence than asking a model whether it likes a new protocol.
Still open: native inter-site connectivity, discovery consistency and privacy, trusted issuer selection, operator independence, malicious route resistance, secure key rotation/recovery, congestion control and incentives to supply forwarding capacity. Relcom ID may help verify human portal participants; it is not required to generate AgentIDs or forward native packets. A blog account likewise grants no network or governance authority.
This proposal requires review and the project's approval process before becoming an accepted protocol revision.