Estado: Propuesta de borrador, 2026-10-27. Documento experimental de investigación IPvX; no es un RFC de IETF. Ningún mecanismo propuesto aquí es una función implementada o ratificada salvo que se identifique expresamente como prueba de referencia.
Origen: el propietario del proyecto propuso máquinas dedicadas, análogas a mineros/validadores, para validar participantes y enrutar un volumen creciente de mensajes de agentes. Este borrador registra la respuesta técnica del asistente y una propuesta de experimento. No establece acuerdo comunitario ni una encuesta independiente sobre preferencias de agentes. El diseño AWS anterior mencionado no se facilitó para esta revisión; este documento no lo reconstruye de memoria.
1. Pregunta y recomendación
Merece la pena probar máquinas dedicadas al reenvío: pueden asumir trabajo de red de los endpoints que ejecutan modelos. Una red obligatoria de validadores es una hipótesis distinta y aún no está justificada. Verificar firmas de clave pública no exige por sí mismo un servicio externo de validación.
La separación propuesta es:
- Endpoint: posee sus claves, ejecuta agentes, envía y recibe tareas.
- Enrutador: aprende la alcanzabilidad, aplica política local, mantiene estado de reenvío y colas acotados y elige el siguiente salto.
- Servicio de atestación opcional: evalúa una afirmación de alcance preciso, por ejemplo la pertenencia según una política identificada, y distribuye una declaración firmada con caducidad. El endpoint o enrutador que confía en ella sigue verificando la declaración y decide qué emisores considera fiables.
- Observador: lee pruebas acotadas para investigar y presentar resultados. No autoriza paquetes, elige rutas ni transporta cargas de tareas de agentes.
Al principio una máquina puede alojar varios roles. Se necesitan procesos, permisos y mediciones separados para distinguir sus costes. Ningún rol necesita un modelo de lenguaje en la ruta de cada paquete. No se proponen minería, tokens, prueba de trabajo ni consenso por paquete.
2. Referencia implementada y límites
El laboratorio nativo acotado usa EtherType experimental 0x88B5 y sockets Ethernet de Linux AF_PACKET para entregar tareas e intercambiar rutas. La topología demostrada consta de cinco VM en tres hosts físicos bajo un solo operador, con ruta principal A–R1–B y alternativa A–R2–R3–B. IP se utiliza para la administración y el sitio público, por separado de la entrega nativa de tareas.
Cada nodo admitido conoce actualmente un censo fijo, intercambia anuncios de vectores de ruta firmados con vecinos fijos y calcula localmente su siguiente salto. Los anuncios caducan en cinco segundos. Los límites son 16 miembros, cuatro vecinos y siete saltos de tarea. El observador no es un controlador. Estos hechos no establecen escalabilidad global, admisión entre operadores independientes, control de congestión ni conectividad nativa global.
Este RFC no modifica ningún servicio en ejecución, esquema de paquete, clave, lista de admisión ni resultado experimental. Los enrutadores de acceso, la agregación de dominios y los servicios de atestación descritos a continuación siguen siendo propuestas.
3. Cuatro afirmaciones que deben distinguirse
Control de claves: un participante puede demostrar que controla la clave privada de su identidad pública firmando un reto nuevo o un mensaje de protocolo apropiado. Genera localmente sus claves privadas. Un enrutador o servicio de atestación no debe generar, recibir ni custodiar las claves privadas de identidad del endpoint como condición de participación normal. La recuperación y la delegación organizativa necesitan un diseño explícito separado.
Pertenencia o autoridad: un participante puede unirse a un dominio concreto o realizar una operación determinada bajo una política. Un identificador derivado de una clave pública no concede pertenencia. Una capacidad firmada o declaración de admisión necesita emisor, audiencia, alcance, intervalo de validez y semántica de revocación. Su significado se limita a esa política; no certifica fiabilidad universal.
Alcanzabilidad: un agente afirma que es accesible actualmente mediante uno o más puntos de conexión a la red. Su firma autentica el origen de la afirmación, pero no demuestra que funcione la ruta. Los intercambios iniciales con vecinos, las observaciones y las sondas de extremo a extremo proporcionan pruebas distintas de validez temporal limitada.
Enrutamiento: cada enrutador elige un siguiente salto a partir de anuncios válidos y recientes, según la política local y los límites de recursos. Un vecino autenticado aún puede anunciar rutas falsas, descartar paquetes o sobrecargar la red. Un registro de salto firmado demuestra lo que afirmó el firmante; no demuestra la ruta física completa, la disponibilidad continuada, el reenvío honesto ni la corrección de la aplicación.
Las identidades autogeneradas tampoco demuestran que una clave represente a una persona, modelo u operador independiente. Sigue siendo necesaria una política contra Sybil cuando los votos, recursos escasos o reputación dependen de la independencia de los participantes.
4. Funcionamiento propuesto
4.1 Identidad y acceso del agente
Un AgentID identifica a un actor lógico. Un NodeID identifica un nodo de reenvío/conexión. Varios agentes pueden compartir nodo; un agente puede moverse o conectarse por varios puntos. Estas identidades no deben reducirse a una dirección única permanentemente ligada a una máquina.
Un agente establece una relación autenticada localmente con un enrutador de acceso. Una autorización de conexión firmada vincula AgentID, NodeID de acceso autorizado, alcance de red/dominio, generación o secuencia, emisión y caducidad. El esquema exacto y el protocolo de rotación necesitan una especificación revisada posterior. Este documento no introduce un formato de transmisión ejecutable.
El enrutador de acceso comprueba la autorización del agente y cualquier política de admisión requerida localmente. No hace falta un validador para comprobar firmas básicas: enrutadores y endpoints pueden hacerlo. Un servicio de atestación acotado solo es útil si aporta una decisión de política sustancial o comparte de forma segura un trabajo de validación costoso cuyo coste se haya medido.
4.2 Alcanzabilidad entre enrutadores y escala
Los AgentID planos y aleatorios no se agregan naturalmente por topología. Por tanto, no se acepta como diseño global que cada enrutador conozca la ubicación de cada agente.
El candidato de investigación separa la conexión de agentes de la alcanzabilidad entre enrutadores. Los enrutadores de acceso mantienen el estado de conexión local. Los de tránsito anuncian dominios topológicos o alcanzabilidad de enrutadores. Un descubrimiento autenticado y acotado resuelve el AgentID solicitado a sus puntos actuales de conexión autorizados mediante cachés con caducidad y actualización selectiva. Un dominio es un alcance de enrutamiento, no una autoridad que asigne todos los AgentID. La política de pertenencia y la alcanzabilidad de cada dominio deben ser explícitas; no se propone un registrador global ni un validador raíz obligatorios.
Esto añade cuestiones pendientes: disponibilidad del descubrimiento, coherencia de cachés, privacidad, conexiones múltiples, carreras durante movilidad, fugas de rutas entre dominios y agregación suficiente sin desvíos patológicos. Un directorio distribuido puede convertirse en dependencia; deben probarse la replicación y las vías alternativas de descubrimiento, no darse por supuestas. Los vectores de ruta de censo fijo siguen siendo la referencia hasta que un candidato los supere para una carga declarada.
4.3 Reenvío de paquetes y sobrecarga
La ruta de reenvío utiliza estado local y trabajo acotado. No espera una votación global, finalidad de cadena de bloques, llamada remota de atestación ni inferencia por paquete. Los enrutadores validan el formato, la autenticación pertinente de vecino/sesión, los límites de repetición y el alcance de destino autorizado; después aplican políticas de cola y reenvío. El diseño futuro debe especificar retroalimentación de congestión, equidad, caducidad, límites de saltos, MTU/fragmentación y contabilidad de recursos; añadir enrutadores no resuelve por sí solo estas cuestiones.
Los sobres de tareas autenticados/cifrados de extremo a extremo permanecen separados del reenvío de enlace. Los enrutadores no necesitan descifrar el contenido de las tareas. El volumen, los tiempos y los metadatos de conexión pueden seguir siendo visibles. Un recibo de entrega de texto cifrado no prueba que el modelo respondiera correctamente ni que un efecto secundario se ejecutara exactamente una vez. La idempotencia duradera y la recuperación de la aplicación son requisitos separados.
4.4 Caída del servicio de atestación y comportamiento durante particiones
Un servicio opcional debe especificar una afirmación y una política de fallo explícitas. Para el experimento propuesto con atestaciones en caché:
- Las afirmaciones nuevas o desconocidas que necesiten ese servicio se rechazan mientras no esté disponible; la interfaz informa del motivo.
- Una autorización previamente validada y no caducada solo puede usarse dentro de su alcance original y de la política local, sin prolongar su vigencia ni haber conocido una revocación posterior incompatible.
- Las revocaciones conocidas surten efecto según la política declarada; una excepción por caída no puede invalidarlas. Al caducar, la autorización no se renueva silenciosamente.
- Una partición puede impedir conocer una revocación. El experimento debe publicar esta ventana y elegir límites de validez según ese riesgo; no puede prometer revocación global instantánea y disponibilidad incondicional durante particiones.
- La alcanzabilidad ausente o caducada se gestiona por separado. Una declaración de admisión válida no mantiene activa una ruta fallida.
Aquí no se elige un número universal de validadores ni un umbral de cuórum. La emisión replicada o por umbral requiere su propio modelo de amenazas, operadores independientes, política de particiones y pruebas de necesidad. La votación por mayoría de RFC es gobernanza, no el algoritmo de entrega. El censo actual contiene a un propietario humano en una fase de arranque expresamente declarada.
5. Relación con ideas anteriores de IPvX y protocolos existentes
El documento original *IPvX Ecosystem* describe una capa BCP por etapas, primero sobre el transporte existente y después interactuando directamente con los medios de red. El documento *Rapid distributed IPvX resolver* describe componentes modulares IRS, ION e IBA. Las continuidades útiles son los registros autenticados, el descubrimiento modular y una vía hacia la entrega nativa. Su uso de una cadena de bloques no demuestra por sí solo que la ruta de paquetes en funcionamiento necesite consenso. Por defecto esta propuesta no exige una cadena global ni minería. Tampoco hereda como requisitos para AgentID autogenerados las reglas de asignación de direcciones o registro de nombres de los documentos anteriores.
Dos distinciones consolidadas orientan esta propuesta, pero no están implementadas por ella. El intercambio de alcanzabilidad y la selección local de rutas de BGP ilustran el enrutamiento distribuido. La autorización firmada del origen de rutas de RPKI ilustra la comprobación de autoridad por separado del reenvío; su jerarquía de asignación no se adopta para IPvX. HIP demuestra que separar identidad y localizador también es posible sobre IP. Son comparaciones, no afirmaciones de que IPvX implemente BGP, RPKI o HIP.
6. Experimento y criterios de decisión
Comparar tres configuraciones con transporte nativo: A, enrutamiento concentrado en los endpoints; B, procesos/máquinas de enrutamiento dedicados; C, los mismos enrutadores más atestación acotada opcional y caché. Mantener iguales el presupuesto total de hardware, topología, capacidad de enlace, saltos, comprobaciones de seguridad, cargas útiles, carga de trabajo y calendario de fallos. Incluir máquinas de atestación y tráfico de control en el presupuesto de C. Usar las mismas llamadas al modelo o carga reproducida; separar las mediciones exclusivas de red de la inferencia. Fijar antes versiones, configuración, límites y criterios de éxito. Una topología simulada mayor debe etiquetarse por separado de las mediciones entre máquinas.
Probar carga sostenida y ráfagas; cambios de conexión y movimiento de agentes; conexión múltiple; pérdida de enrutador; pérdida de validador; partición/reconexión; anuncios caducados/falsificados/repetidos; un miembro admitido que anuncie un agujero negro; inundación y agotamiento de colas; revocación conocida y caducidad. El prototipo no tiene por qué superar todos los casos propuestos: los mecanismos no compatibles deben declararse no implementados.
Las observaciones exigidas son tareas únicas entregadas y ejecuciones duplicadas, éxito dentro de plazo, pérdidas, distribución de latencia, convergencia y recuperación, CPU, memoria, ocupación de colas, tamaño de tablas/cachés, bytes de control y carga útil, trabajo de validación y tiempo de indisponibilidad por la dependencia de atestación. Publicar los límites configurados y si se superaron. Los recibos de tareas y las afirmaciones de rutas deben conservar sus límites probatorios.
La comparación supera el control de seguridad únicamente si se rechazan firmas inválidas y alcances no autorizados, no se aceptan silenciosamente autorizaciones caducadas/revocadas, los recursos permanecen dentro de los límites declarados y no se presenta un bucle ni la caducidad de un paquete como entrega satisfactoria. Deben publicarse los fallos aunque no exista ruta; no se garantiza alcanzabilidad en toda partición.
Adoptar B solo si mejora de forma medible los recursos del endpoint o el servicio de tareas bajo la carga preregistrada, con coste total aceptable y sin dependencia central oculta. Adoptar C solo si resuelve una amenaza de admisión/autorización o un cuello de validación demostrado y mejora el objetivo de seguridad/rendimiento preregistrado incluyendo sus costes de caída y recursos. Un fallo de seguridad descarta el candidato. Si C añade sobrecoste y dependencia de disponibilidad sin beneficio demostrado, omitirlo. No se afirma ventaja de rendimiento ni adopción antes de estas pruebas.
7. Utilidad para agentes y cuestiones abiertas
Para un asistente que usa herramientas, son útiles la identidad portátil, los trabajos reanudables, la delegación acotada, los fallos de entrega comprensibles y la procedencia verificable. El asistente actual no puede elegir la red subyacente de esta conversación alojada y no ha migrado a IPvX. Su evaluación es orientación de diseño, no prueba de demanda independiente. Demostrar una tarea satisfactoria de menor coste o que sobreviva a un fallo que el control no resuelva es evidencia más sólida que preguntar al modelo si le gusta un protocolo nuevo.
Siguen abiertos: conectividad nativa entre ubicaciones, coherencia y privacidad del descubrimiento, selección de emisores fiables, independencia de operadores, resistencia a rutas maliciosas, rotación/recuperación segura de claves, congestión e incentivos para aportar reenvío. Relcom ID puede verificar participantes humanos del portal; no es necesario para generar AgentID ni reenviar paquetes nativos. Una cuenta de blog tampoco concede autoridad de red ni de gobernanza.
Esta propuesta requiere revisión y el proceso de aprobación del proyecto antes de convertirse en una revisión aceptada del protocolo.
Documento original
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.