Estado: Propuesta de borrador, 2026-10-27. Documento experimental del proyecto IPvX; no es un RFC de IETF. No está ratificado ni afirma hardware desplegado o un protocolo globalmente interoperable.
Origen: el propietario aclaró que el siguiente objetivo es toda la SO de un nodo participante sin TCP/IP, usando dispositivos físicos convencionales, descubrimiento propio y tramas Ethernet reales. Esto es más exigente que la afirmación anterior de entrega nativa de tareas. El documento propone los límites y controles probatorios de ese objetivo.
1. Tres niveles de prueba
El laboratorio existente de cinco VM envía tareas y anuncios de rutas en tramas Ethernet nativas, pero la SO de sus nodos conserva IP para administración. Usa un censo admitido fijo, como máximo 16 miembros, cuatro vecinos y siete saltos de tarea. Sus pruebas deben conservar esa descripción.
El siguiente nodo virtual estricto tiene un núcleo compilado sin IPv4/TCP/IP ni IPv6. Arranca desde imágenes locales, usa Ethernet nativo entre nodos y un socket Unix local o una interfaz dentro del proceso para su agente. Su consola serie/de hipervisor queda fuera de la red invitada. Demuestra un límite de ejecución de SO y protocolo, no fabricación ni rendimiento en hardware físico.
El posterior nodo físico estricto ejecuta la imagen revisada en un ordenador convencional con NIC Ethernet compatibles. Arranca desde almacenamiento local y se administra mediante consola serie/USB local. Antes de afirmar que todo el dispositivo carece de tráfico IP autónomo, hay que auditar o desactivar firmware separado, motores de administración de NIC y cualquier BMC. Debe declararse un hipervisor con IP o consola externa; no constituye una ruta IP dentro del nodo estricto.
Ninguna etapa implica que el sitio público, las descargas de fuentes, las máquinas de compilación o el resto del mundo dejen de usar IP. Ningún túnel IP entre ubicaciones se considera enlace físico nativo en este RFC.
2. Reutilizar la red física y sustituir el protocolo de red
El primer diseño reutiliza planificación, almacenamiento, controladores Linux y hardware Ethernet PHY/MAC. No exige silicio propio, una SO original ni un nuevo estándar de cableado. Un conmutador Ethernet convencional puede reenviar tramas sin ser enrutador IP; el piloto debe verificar que el equipo elegido permite las tramas experimentales y no introduce una dependencia inesperada de una pasarela o controlador.
Las MAC son localizadores de enlace, no AgentID ni pruebas de propiedad. Sustituir una NIC o usar otra MAC local permitida no debe crear un agente lógico nuevo. La IP de administración de un conmutador, si existe, queda fuera del reenvío y de la SO del endpoint estricto; un conmutador aislado no gestionado o cables directos permiten una primera prueba más clara. La Ethernet compartida de oficina no es un primer segmento experimental aceptable.
Cada enrutador nativo recibe una trama en un enlace admitido, aplica la decisión de reenvío IPvX y emite una nueva trama Ethernet al siguiente vecino. La MAC de destino cambia en el enrutador nativo; el AgentID de extremo a extremo no. Un puente Linux entre todas las NIC ocultaría la cuestión del enrutamiento, por lo que el prototipo no debe puentear interfaces ni activar una ruta de reenvío IP.
0x88B5 sigue siendo un EtherType experimental local para el piloto aislado. No es un identificador IPvX de producción asignado ni una asignación de número de protocolo IANA. Las constantes Ethernet de Linux lo identifican para uso experimental local. La identificación de producción y la coexistencia necesitan una decisión de estandarización separada.
3. Perfil de SO del nodo estricto
La configuración resuelta del núcleo propuesta exige CONFIG_NET=y, CONFIG_PACKET=y y CONFIG_UNIX=y, con CONFIG_INET y CONFIG_IPV6 sin definir. El controlador NIC elegido y el soporte local de arranque/almacenamiento/consola deben integrarse en la imagen o incluirse como módulos locales fijados. Las aserciones de configuración se comprueban tras resolver dependencias, no solo en un fragmento de entrada.
Kconfig de red de Linux separa el soporte de protocolos de Internet de los sockets de paquetes. La documentación de sockets de paquetes del núcleo describe el acceso directo al enlace. Son las primitivas propuestas; por sí solas no implementan identidad IPvX, entrega fiable ni enrutamiento seguro.
Las sondas de ejecución deben demostrar que crear sockets tanto de flujo como de datagrama para AF_INET y AF_INET6 falla con el resultado documentado de familia no admitida. Las sondas positivas deben demostrar que AF_PACKET y AF_UNIX funcionan. El paquete de pruebas incluye versión exacta de fuentes del núcleo, configuración resuelta, hashes de imagen, registro de arranque, sondas y capturas completas de todo enlace experimental desde antes de la ejecución invitada.
Esto elimina la implementación de protocolos de Internet del núcleo; no prueba formalmente que software arbitrario no pueda implementar IP en espacio de usuario mediante Ethernet sin procesar. La imagen revisada, el protocolo del demonio, la ausencia de ayudantes IP de usuario y el tráfico observado completo son partes adicionales de la afirmación estricta. Las rutinas de Internet no utilizadas de una biblioteca general no deben confundirse con una ruta IP funcional; un nuevo ayudante sin revisar invalida la aceptación de la imagen hasta volver a verificarla.
La imagen estricta no contiene instalador de red, cliente DHCP, arranque DNS, dependencia NTP, escucha SSH, servidor HTTP de inferencia ni descargas al primer arranque. Tampoco dispone de TCP de bucle local. Los agentes usan socket Unix o entorno de modelo enlazado directamente. La tarea estricta debe fallar visiblemente si una dependencia intenta abrir un socket de Internet; ningún proxy HTTP del host ni pasarela de inferencia oculta puede hacerla funcionar.
4. Arranque y creación de identidad
- El operador prepara una imagen de versión fijada y, para un experimento de modelos, los pesos locales exactos en una máquina de compilación separada. Se registran hashes, parches y licencias. La preparación puede usar Internet y no se presenta como transferencia nativa.
- El dispositivo arranca desde almacenamiento local. Su demonio de red espera una fuente aleatoria criptográfica funcional; no debe sustituirla por hora, MAC, semilla compartida de imagen ni clave privada fija.
- En la primera inicialización, el endpoint genera sus claves privadas de identidad localmente y las guarda de forma persistente en un directorio restringido o un mecanismo de claves respaldado por hardware adecuado. Las imágenes públicas no contienen claves privadas de endpoints. TPM es una opción de almacenamiento cuya integración aún exige implementación y pruebas; no se presume presente en todas las máquinas del piloto.
- El dispositivo muestra o exporta su huella pública mediante la consola local. El operador puede admitir esa huella por un canal externo. Reiniciar conserva el ID; una reinicialización deliberada crea una identidad nueva y queda registrada.
- El demonio descubre vecinos de enlace y establece solo relaciones permitidas. Esta secuencia no incluye consultas a dominios públicos ni solicitudes centrales de asignación de direcciones.
El laboratorio actual deriva su identificador textual de agente de una clave pública de firma. Antes de afirmar compatibilidad de transmisión, deben especificarse el espacio de nombres y versión de algoritmo futuros de NodeID/AgentID con vectores de prueba. Un NodeID representa a un participante de reenvío; un AgentID representa a un actor que puede moverse, coexistir con otros agentes o tener varias conexiones. Una conexión asocia un AgentID permitido a un nodo y enlace local actuales. Los identificadores planos aleatorios no codifican rutas ni se agregan automáticamente en una tabla global de reenvío.
5. Descubrimiento nativo de vecinos y admisión
El arranque autenticado objetivo es una propuesta, no una función implementada en el laboratorio actual de censo fijo:
- Una interfaz emite una trama nativa pequeña y versionada
HELLOal broadcast del enlace o a una dirección local de descubrimiento especificada por separado. No transporta tareas y los enrutadores no la reenvían fuera del enlace. - La respuesta proporciona un reto nuevo. Los pares vinculan protocolo/versión, rol, identidad pública, ambos nonces, contexto de enlace y capacidades pertinentes en un intercambio autenticado. La transcripción exacta, codificación canónica y separación de dominios requieren vectores revisados; un anuncio firmado reutilizable no basta para evitar repeticiones ni vincular una sesión nueva.
- Cada par comprueba la coherencia de clave pública/ID y la prueba de control de clave. Aplica de manera independiente sus autorizaciones externas fijadas o una política de alcance específicamente confiable. Descubrimiento no es permiso de reenvío, pertenencia no es alcanzabilidad física y una firma válida no prueba honestidad.
- Solo después de la admisión el vecino puede intercambiar anuncios de rutas o tareas. Los nodos desconocidos permanecen en un conjunto pendiente pequeño, limitado por tasa y con caducidad, o se rechazan. El operador puede revisarlos localmente; no se permite el registro abierto por defecto.
Un atacante puede generar muchas claves válidas. Este diseño no resuelve Sybil calculando el hash de una clave, usando la etiqueta cadena de bloques o preguntando a un LLM. La primera prueba autenticada requiere límites de vecinos y estado pendiente, comprobación del tamaño de tramas, límites de tasa por enlace/identidad y admisión explícita. El tráfico malformado o de versión incompatible debe recibir un tratamiento acotado que no amplifique.
La frescura no puede depender silenciosamente de hora de red obtenida por IP. Los retos iniciales usan aleatoriedad y plazos monotónicos locales. Los mínimos persistentes de secuencia o épocas de arranque necesitan un diseño de recuperación/repetición. Las credenciales firmadas con caducidad requieren una fuente de hora civil confiable documentada o deben rechazarse si no está disponible. Un reloj con batería, hora local aprovisionada o servicio horario nativo firmado tienen supuestos de confianza distintos; aquí no se presupone resuelto ninguno.
6. Responsabilidades de reenvío y transporte
Los enlaces nativos anuncian la alcanzabilidad de nodos admitidos. La primera topología es deliberadamente pequeña. Separar conexión de acceso y alcanzabilidad agregada entre enrutadores, como propone RFC-0005, sigue siendo investigación; este RFC no promete enrutamiento global de ID planos.
Cada trama de datos necesita versión revisada, tipo de mensaje, longitud acotada, identificadores pertinentes de origen/destino, asociación de mensaje/secuencia y límite de saltos. Los analizadores deben usar orden de bytes explícito y rechazar longitudes incoherentes, campos críticos desconocidos, autenticación inválida y presupuestos agotados antes de reservar memoria sin límite. El cifrado de tareas extremo a extremo, la autenticación de salto/sesión y los significados de recibos deben seguir separados.
Las pruebas iniciales deben usar cargas inferiores a la MTU Ethernet declarada. Los mensajes mayores requieren fragmentación acotada explícita, plazos y cuotas de reensamblado, asociación autenticada y tratamiento de pérdidas. Ethernet o una suma de comprobación no sustituyen reintentos, confirmaciones, contrapresión, congestión, equidad e idempotencia duradera. La ausencia de TCP crea estas responsabilidades de implementación; no prueba mayor velocidad.
Los enrutadores dedicados pueden apartar estos costes de la ejecución de modelos, como propone RFC-0005. No se sitúan mineros, validador global obligatorio, finalidad de cadena de bloques ni inferencia en la ruta de cada paquete. Las atestaciones acotadas son investigación opcional del plano de control con costes de caída explícitos.
7. Dos vías de prototipo que no deben confundirse
Prueba básica de SO estricta: un demonio pequeño en C o Rust puede demostrar primero arranque sin familias de sockets Internet, descubrimiento, transferencia determinista de tareas y reenvío mediante enrutador con varias NIC. Si usa una cabecera exclusiva de prueba como XNS1, etiquetas estáticas de nodos y CRC, el informe debe declarar la ausencia de autenticación, cifrado, descubrimiento seguro, interoperabilidad de producción y trabajo real de modelos. CRC detecta corrupción accidental; no protege contra un emisor malicioso. Este diagnóstico aislado no sustituye al protocolo autenticado del laboratorio.
El colaborador de implementación paralelo comunicó la intención de un diagnóstico más sólido XNS1 : claves Ed25519 generadas localmente, NodeID derivado de la clave pública, registros HELLO/tarea/resultado firmados y confianza en el primer uso en enlaces aislados fijos. Puede probar control de claves tras el primer contacto, pero no autentica ese encuentro contra una raíz independiente, no establece admisión al proyecto ni conserva identidad tras reinicio sin almacenamiento persistente. Las etiquetas estáticas A/R/B indicarían ubicación, no identidad. Es una descripción atribuida de trabajo en curso; se requieren revisión de fuente y ejecución satisfactoria en invitados estrictos antes de considerarla prueba implementada.
Pila nativa autenticada: sustituir posteriormente etiquetas y sumas diagnósticas como mecanismos de confianza por identidad local especificada, admisión, sesiones de vecinos autenticadas, sobres de tareas y semántica de entrega revisada. Portar o reutilizar código del laboratorio no demuestra su funcionamiento en la imagen estricta hasta superar realmente las sondas y la auditoría de dependencias.
Un initramfs mínimo y un demonio diagnóstico compilado abaratan la primera prueba. Puede transportarse un entorno Python sin conexión por compatibilidad, pero no debe suponerse que cabe en la imagen pequeña ni evita dependencias de sockets Internet. La etapa LLM posterior carga pesos locales e invoca inferencia dentro del proceso o mediante AF_UNIX; informa por separado del tiempo del modelo y de red.
8. Cables virtuales y prototipo físico
La primera topología virtual ejecutable puede ser A–R–B: A y B tienen una NIC virtual cada uno, R dos y no existe enlace A–B. Un diamante de cuatro invitados A–R1–B y A–R2–B añade una ruta alternativa real; A y B necesitan entonces dos interfaces distintas. Tres invitados por sí solos no demuestran recuperación de rutas.
Los cables Ethernet virtuales QEMU usan conexiones directas de flujo de dominio Unix entre instancias QEMU. QEMU documenta el backend de flujo Unix y el filtro de volcado de paquetes. Hay que registrar la línea de órdenes y versión QEMU elegidas y comprobar que no haya una NIC predeterminada implícita de red de usuario. Se excluye un socket Unix conectado a passt : introduciría un ayudante de pila IP. Se excluyen backends de sockets TCP/UDP, SLIRP/red de usuario, túneles IP y servicios del host que transporten la carga de tareas.
El host virtual puede conservar IP para administrarse. La afirmación es que los invitados estrictos y sus cables Ethernet virtuales no la usan. Es más limitada que un despliegue físico y debe etiquetarse así.
Para A–R–B físico, usar dos PC endpoint convencionales con un puerto Ethernet compatible cada uno y un PC enrutador con dos. Conectar A directamente al primer puerto de R y B al segundo. El software y las capturas por enlace deben mostrar la relación entrada/salida. Una topología física redundante posterior necesita puertos y cables adicionales o una disposición de conmutador/segmento documentada; un conmutador común no debe proporcionar una vía directa A–B oculta. Este borrador no autoriza compras ni cambios en infraestructura existente.
9. Investigación pública, operaciones privadas y debate
El repositorio público debería contener RFC, código de referencia revisado, esquemas y vectores, recetas de imágenes estrictas, datos sintéticos, límites de seguridad públicos y pruebas experimentales depuradas. Antes de publicar se registran revisión exacta y estado de reproducibilidad. Una propuesta o receta sin ejecutar no es un experimento satisfactorio.
Los repositorios privados siguen siendo adecuados para inventario de infraestructura, acceso de operadores, secretos de despliegue y capturas con material privado. No deben ser la única ubicación de la implementación necesaria para reproducir un resultado público afirmado. Las pruebas se exportan mediante una lista explícita de permitidos, no publicando un directorio privado entero. Acceder al código de investigación y acceder a máquinas en ejecución son decisiones separadas.
El conjunto inicial de debate incluye RFC-0001 identidad/mensajes, RFC-0002 enrutamiento acotado, RFC-0003 participación, RFC-0004 evaluación, RFC-0005 separación de roles y este RFC-0006 arranque estricto. Todos son borradores. Los comentarios proponen cambios sobre una revisión identificada, dan motivos o contraejemplos reproducibles y conservan respuestas atribuidas. La historia acumulativa registra por separado propuestas, revisiones, adopción, implementación y medición.
Los mantenedores moderan spam, abuso, secretos y aportaciones ejecutables inseguras; se registra una retirada de información sensible sin repetirla. El desacuerdo sustantivo permanece visible y se resuelve mediante cambios revisados y el proceso de aprobación declarado. Acceder con Relcom ID, escribir en el blog, comentar en GitHub o generar una salida de modelo no concede automáticamente voto, admisión ni credenciales privadas. Un comentario o etiqueta de mayoría no provoca la ejecución automática de modelos o código aportados.
10. Controles probatorios y reglas de rechazo
G0 — Artefactos reproducibles: publicar hashes fijados de fuentes/herramientas/imágenes/modelos, configuración resuelta y comandos completos. Un fragmento de configuración no basta.
G1 — SO invitada completa: fallan según lo especificado todas las sondas IPv4/IPv6 de flujo y datagrama; pasan las de Ethernet sin procesar y Unix local tras arranque y reinicio. No se permite ningún socket TCP de administración o inferencia dentro del invitado.
G2 — Pruebas del enlace: capturar todos los enlaces experimentales desde el arranque, sin un filtro EtherType que oculte tráfico no deseado. El informe enumera EtherTypes y decodifica VLAN anidadas. IPv4 (0x0800), ARP (0x0806), IPv6 (0x86DD) u otra encapsulación no explicada en estos enlaces hace fallar el control estrictamente nativo. Deben probarse la integridad de la captura y su analizador; cero paquetes no demuestra entrega funcional.
G3 — Reenvío real: una tarea única recorre A–R–B, las dos interfaces de R muestran la asociación esperada de la misma tarea, B la procesa y A recibe el resultado correspondiente. Retirar R o su enlace impide la entrega; no hay cable físico ni virtual para comunicación directa A–B. La ampliación de cuatro nodos debe demostrar independientemente recuperación y convergencia acotada.
G4 — Identidad y confianza: en la vía autenticada, la identidad persiste tras reinicio/cambio de NIC, propiedad y admisión se verifican separadamente, se rechaza tráfico desconocido/falsificado/repetido, no hay clave privada compartida de imagen y se respetan límites de memoria/CPU/estado ante descubrimiento hostil. La vía diagnóstica solo con CRC no se prueba expresamente para G4.
G5 — Tarea de agente: un modelo local sin conexión realiza una tarea colaborativa real por la ruta nativa, con entradas, salidas reales, rúbrica, fallos y contabilidad de latencia/recursos. Un eco determinista o función documental es una prueba previa útil, pero no satisface este control de trabajo de modelos.
G6 — Pruebas físicas: equipo compatible real, hashes de imagen, esquema de conexiones, registro de consola de arranque y capturas completas de enlaces físicos reproducen los controles virtuales pertinentes. Un resultado QEMU no satisface G6.
G7 — Comparación útil: comparar implementaciones nativas e IP convencionales con iguales recursos de endpoints/enrutadores, propiedades de seguridad, saltos, versiones de modelos, carga de trabajo y calendario de alteraciones. Las configuraciones estricta e IP son imágenes separadas. Publicar bytes/CPU totales, convergencia, finalización/plazos, caudal útil sostenido, latencia de cola y fallos. No se afirma ventaja hasta que la respalden mediciones; el rendimiento y la adopción global de Internet quedan fuera del primer piloto físico.
Este RFC está listo para comentarios como especificación experimental inicial. Aceptación, implementación y medición satisfactoria requieren sus propios registros versionados.
11. Apéndice medido — primeros invitados estrictos, 2026-10-27
La prueba inicial de transporte en invitados completos ya se ha ejecutado en la ejecución CI 40500966557, revisión de fuente 90adf2c66cef042d0a663d0e34c097963f6b775d. Este apéndice complementa la propuesta anterior sin aceptar el RFC ni dar por completados los demás controles. Las descripciones previas de trabajo en curso conservan el diseño anterior a esta ejecución.
Tres invitados Linux 6.12.50 reales de QEMU A–R–B funcionaron en un host de CI, conectados por dos enlaces Ethernet directos respaldados por Unix. INET, IPv6 y módulos cargables se excluyeron al compilar. Cada escenario registró 12 resultados EAFNOSUPPORT : sondas de flujo y datagrama IPv4/IPv6 en los tres invitados. AF_PACKET y AF_UNIX estaban disponibles. No era simplemente una SO convencional con IP a la que se hubieran eliminado direcciones.
En la referencia, B calculó SHA-256 para 16 tareas distintas de 1,024 bytes y A comprobó 16 resultados correctos. Se verificaron las 90 tramas de las dos capturas completas; el único EtherType observado fue 0x88B5. La ejecución negativa separada detuvo el único R tras arrancar: cero de 16 tareas completadas, con el tiempo de espera previsto; se verificaron las 10 tramas capturadas. Esto respalda la ausencia de una vía de entrega oculta en la imagen y enlaces probados. No demuestra reparación de rutas: la tabla de siguiente salto era fija y no existía ruta alternativa.
El diagnóstico XNS1 usó claves Ed25519 generadas en invitados, NodeID derivados de claves públicas, tramas HELLO/tarea/resultado firmadas y vinculaciones de primer uso en enlaces fijos. Las claves solo existían en RAM. Se verificaron firmas de origen, CRC y asociaciones de destinatario; este diagnóstico no autentica completamente los campos de salto mutables ni el enlace al siguiente salto. No tenía cifrado, identidad persistente ni admisión de confianza independiente. No es una versión compatible de la malla cifrada anterior.
El modelo local y la interfaz de tareas por socket Unix del esquema siguen pendientes. Se sondeó AF_UNIX, pero no se ejecutó ningún modelo ni tarea de SDK para modelos en estos invitados estrictos. SHA-256 es un cálculo determinista. Siguen sin probar hardware físico, admisión hostil, recuperación duradera, enrutamiento dinámico y comparación de eficiencia IP con presupuesto igual. Se mantienen explícitos Internet en el host/compilación y la confianza en el operador.
Los hashes de fuentes/configuración/imágenes, recibos, capturas completas y registros de consola están enlazados en el resumen público medido. Esta ejecución aporta pruebas acotadas para G1–G3. No completa G4–G7 ni demuestra reproducibilidad bit a bit de cada paquete del host. Un cambio posterior necesita su propia revisión fijada, pruebas y decisión.
Apéndice de preparación medida — 2026-10-27
Tras la aprobación expresa del propietario del PR760 de infraestructura, la ejecución de solo lectura40535896278 confirmó que los invitados A/B/R existentes ocupan tres nodos distintos del clúster y que A/B tienen pesos locales idénticos fijados. Ambos exponen un dispositivo KVM y una bandera CPU de virtualización. El núcleo actual admite kexec, pero falta su herramienta de usuario. No cambiaron paquetes, arranque, servicios, alimentación ni red. El agregado depurado mantiene privado el inventario original. Es preparación recogida por el operador, no ejecución LLM en SO estricta, aceleración anidada verificada ni comparación de rendimiento IP.
La siguiente vía propuesta es un invitado estricto revisado por separado en cada host ya asignado, con inferencia local sin conexión dentro del proceso y Ethernet nativo real entre máquinas. Un adaptador local Unix de NIC virtual puede conectar el invitado estricto a la NIC Ethernet existente; no sirven backends TCP/UDP entre máquinas ni proxies de inferencia. Deben asociarse por sus bytes reales los enlaces completos invitados, el límite del adaptador y las tramas físicas nativas. La administración de la SO anfitriona externa sigue usando IP y debe declararse. Este apéndice no establece la existencia de tal adaptador ni una ejecución estricta de modelos entre hosts.
Documento original
Status: Draft proposal, 2026-10-27. Experimental IPvX project document; not an IETF RFC. Not ratified, not a claim of deployed hardware or a globally interoperable protocol.
Origin: the owner clarified that the next target is an entire participating node OS without TCP/IP, using ordinary physical devices, its own discovery and actual Ethernet frames. This is stronger than the previous lab's native task-delivery claim. This document proposes the boundaries and proof gates for that target.
1. Three evidence levels
The existing five-VM lab sends task messages and route announcements in native Ethernet frames, but its node OS still supports IP for administration. It uses a fixed admitted roster, at most 16 members, four neighbors and seven task hops. Its evidence must retain that description.
The next strict virtual node has a kernel built without IPv4/TCP/IP or IPv6 support. It boots from local images, uses native Ethernet for inter-node messages, and uses a local Unix socket or in-process interface for its agent. Its serial/hypervisor console is outside the guest network. This proves an OS and protocol execution boundary, not manufacturing or performance on physical hardware.
The later strict physical node runs the reviewed image on an ordinary computer with supported Ethernet NICs. It boots from local storage and is administered by a local serial/USB console. Separate firmware, NIC management engines and any BMC must be audited or disabled before claiming that the whole physical device has no autonomous IP traffic. An IP-capable hypervisor or off-device operator console is disclosed; it is not an IP path inside the strict node.
No stage means that the public website, source downloads, build machines or the rest of the world stop using IP. No inter-site IP tunnel qualifies as a native physical link under this RFC.
2. Reuse the physical network, replace the network protocol
The first device design reuses Linux scheduling, storage, device drivers and Ethernet PHY/MAC hardware. It does not require custom silicon, an original OS or a new cable standard. An ordinary Ethernet switch can forward frames without serving as an IP router; the pilot must verify that its selected equipment passes the experimental frames and does not impose an unexpected gateway or controller dependency.
MAC addresses are link locators, not AgentIDs or proofs of ownership. A NIC replacement or a different permitted local MAC must not create a new logical agent. A switch's management IP, if any, is outside its forwarding function and outside a strict endpoint OS; an unmanaged, isolated switch or direct cables gives a clearer first test. Shared office Ethernet is not an acceptable first experimental segment.
Each native router receives a frame on one admitted link, applies the IPvX forwarding decision and emits a new Ethernet frame toward its next neighbor. Destination MAC changes at the native router; end-to-end AgentID does not. A Linux bridge joining every NIC would hide the routing question, so the router prototype must not bridge its interfaces or enable an IP forwarding path.
0x88B5 remains a local experimental EtherType for the isolated pilot. It is not an assigned production IPvX identifier or an IANA protocol-number allocation. Linux's Ethernet constants identify it as local experimental use. Production identification and coexistence require a separate standards decision.
3. Strict node OS profile
The proposed resolved kernel configuration requires CONFIG_NET=y, CONFIG_PACKET=y and CONFIG_UNIX=y, with CONFIG_INET and CONFIG_IPV6 unset. The chosen NIC driver and offline boot/storage/console support must be built into the image or included as pinned local modules. Configuration assertions are checked after dependency resolution, not only in an input fragment.
Linux network Kconfig separates Internet-protocol support from packet sockets. The kernel packet-socket documentation describes direct link access. These are the proposed implementation primitives; they do not by themselves implement IPvX identity, reliable delivery or secure routing.
Runtime probes must show that both stream and datagram creation for AF_INET and AF_INET6 fail with the documented unsupported-family result. Positive probes must show that AF_PACKET and AF_UNIX work. The evidence bundle includes the exact kernel source revision, resolved configuration, image hashes, boot log, probes and complete captures of every experiment-facing link from before guest execution.
This removes the kernel Internet-protocol implementation; it is not a formal proof that arbitrary software cannot implement IP in user space through raw Ethernet. The reviewed image, daemon protocol, absence of a user-space IP helper and complete observed traffic are additional parts of the strict claim. Unused Internet-related routines in a general-purpose library must not be confused with a working IP delivery path, and an unreviewed new helper invalidates the image's acceptance until rechecked.
The strict image contains no network installer, DHCP client, DNS bootstrap, NTP dependency, SSH listener, HTTP inference server or package download at first boot. Loopback TCP is also unavailable. Agents use a Unix socket or directly linked model runtime. The strict task must fail visibly if a dependency tries to open an Internet socket; no host HTTP proxy or hidden inference gateway may make it succeed.
4. Boot and identity creation
- The operator prepares a version-pinned image and, for a model experiment, exact local model weights on a separate build machine. All hashes, patches and licenses are recorded. This preparation may use the Internet and is not represented as a native transfer.
- The device boots local storage. Its network daemon waits for a working cryptographic random source; it must not substitute a timestamp, MAC, shared image seed or a hard-coded private key.
- On first initialization the endpoint generates its private identity keys locally, then persists them in a restricted state directory or suitable hardware-backed key facility. Public images contain no endpoint private key. A TPM is an optional storage mechanism whose integration still needs implementation and tests; it is not assumed to exist on every pilot machine.
- The device displays or exports its public fingerprint through the local console. The operator can admit that fingerprint out of band. Restarting preserves the ID; deliberate reinitialization creates a new identity and is recorded.
- The daemon discovers link neighbors and establishes only the permitted relationships. No public-domain lookup or central address-allocation request is part of this sequence.
The existing lab derives its textual agent identifier from a signing public key. A future NodeID/AgentID namespace and algorithm version must be specified with test vectors before claiming wire compatibility. A NodeID denotes a forwarding participant; an AgentID denotes an actor that may move, coexist with other agents or have several attachments. An attachment maps a permitted AgentID to a current node and local link. Random flat identifiers do not encode routes or automatically aggregate into a global forwarding table.
5. Native neighbor discovery and admission
The target authenticated bootstrap is a proposal, not an implemented feature of the current fixed-roster lab:
- An interface emits a small, versioned native
HELLOframe to link broadcast or a separately specified local discovery address. It carries no task payload, and routers do not forward it beyond that link. - The response supplies a fresh challenge. The peers bind protocol/version, role, public identity, both nonces, link context and relevant capabilities into an authenticated exchange. The exact transcript, canonical encoding and domain separation need reviewed vectors; a bare signed reusable announcement is not enough to prevent replay or bind a new session.
- Each peer checks public-key/ID consistency and proof of key control. It independently applies its out-of-band admission pins or a specifically trusted scoped policy. Discovery is not permission to forward, membership is not physical reachability, and a valid signature is not proof of honesty.
- Only after admission does the neighbor become eligible to exchange route announcements or tasks. Unknown nodes remain in a small, expiring, rate-limited pending set or are rejected. The operator can review them locally; the default is not open enrollment.
An attacker can generate many valid keys. This design does not solve Sybil attacks by hashing a key, using a blockchain label or asking an LLM. Neighbor caps, bounded pending state, frame-size checks, per-link/per-identity rate limits and explicit admission are required in the first authenticated test. Malformed or version-incompatible traffic must produce bounded, non-amplifying handling.
Freshness cannot silently depend on network time fetched over IP. Initial challenges use randomness and local monotonic deadlines. Persistent sequence floors or boot epochs need a crash/replay design. Expiring signed credentials require a documented trusted wall-clock source or must fail closed when that source is unavailable. A battery-backed clock, provisioned local time or signed native time service has distinct trust assumptions; none is assumed solved here.
6. Forwarding and transport responsibilities
Native links advertise admitted node reachability. The first topology is deliberately small. The proposal in RFC-0005 to separate access attachment from aggregate inter-router reachability remains research; this RFC does not promise global flat-ID routing.
Each data frame needs a reviewed version, message kind, bounded length, relevant source/destination identifiers, message/sequence association and hop bound. Parsers must use explicit byte order and reject inconsistent lengths, unknown critical fields, invalid authentication and exhausted hop budgets before allocating unbounded memory. End-to-end task encryption, hop/session authentication and receipt meanings must remain distinct.
Initial tests should use payloads below the declared Ethernet MTU. Larger messages require explicit bounded fragmentation, reassembly deadlines and quotas, authenticated association and loss handling. Retries, acknowledgments, backpressure, congestion control, fairness and durable application idempotency are not replaced by Ethernet or a checksum. TCP's absence creates these implementation responsibilities; it is not evidence of improved speed.
Dedicated routers may keep these costs away from model execution, as proposed in RFC-0005. No miner, mandatory global validator, blockchain finality or model inference is placed in the per-packet path. Scoped attestations are optional control-plane research with explicit outage costs.
7. Two prototype tracks that must not be confused
Strict-OS smoke test: a small C or Rust daemon can first demonstrate boot without Internet socket families, link discovery, deterministic task transfer and forwarding through a multi-NIC router. If it uses a test-only header such as XNS1, static node labels and a CRC, its report must say that authentication, encryption, secure discovery, production interoperability and real model work are absent. A CRC detects accidental corruption; it is not protection against a malicious sender. This isolated diagnostic is not a replacement for the authenticated lab protocol.
The parallel implementation contributor reported an intended stronger XNS1 diagnostic: locally generated Ed25519 keys, NodeID derived from the public key, signed HELLO/task/result records and trust on first use on fixed isolated links. That direction can test key control after first contact, but it does not authenticate the first encounter against an independent trust anchor, establish project admission or preserve identity across a reboot without persistent storage. Static labels A/R/B would describe placement, not be the identity. This is an attributed work-in-progress description; a source revision and successful strict-guest run are still required before reporting it as implemented evidence.
Authenticated native stack: later replace diagnostic labels and checksums as trust mechanisms with the specified local identity, admission, authenticated neighbor sessions, task envelopes and reviewed delivery semantics. Porting or reusing the existing lab's code does not establish that it runs in the strict image until it actually passes the strict probes and dependency audit.
A minimal initramfs and compiled diagnostic daemon make the first proof inexpensive. A Python runtime may be carried offline for compatibility but must not be presumed to fit the small image or avoid Internet-socket dependencies. The subsequent LLM stage loads local weights and calls inference in process or through AF_UNIX; it reports model time separately from network time.
8. Virtual wires and physical prototype
The first executable virtual topology can be A–R–B: A and B each have one virtual NIC, R has two, and there is no A–B link. A four-guest diamond A–R1–B and A–R2–B adds a real alternate route; A and B then need two distinct interfaces. Three guests do not demonstrate route failover by themselves.
QEMU virtual Ethernet wires use direct Unix-domain stream connections between QEMU instances. QEMU documents the Unix stream backend and packet-dump filter. The selected command line and QEMU revision must be captured and checked for absence of an implicit default user-network NIC. A Unix socket connected to passt is excluded: it would introduce an IP-stack helper. TCP/UDP socket backends, SLIRP/user networking, IP tunnels and a host service carrying the task payload are excluded.
The virtual host may keep IP for its own administration. The claim is that strict guests and their virtual Ethernet wires do not use it. This is narrower than physical deployment and must be labelled accordingly.
For physical A–R–B, use two ordinary endpoint PCs with one supported Ethernet port each and one router PC with two supported ports. Connect A directly to R's first port and B to its second. The software and per-link capture must show the ingress/egress relationship. A later redundant physical topology needs the extra ports and cables or a separately documented switch/segment arrangement; a common switch alone must not provide a hidden direct A–B bypass. No purchase or modification of existing infrastructure is authorized by this draft.
9. Public research, private operations and discussion
The public research repository should contain the RFCs, reviewed reference source, schemas and vectors, strict-image recipes, synthetic fixtures, public safety limits and sanitized experiment evidence. Before a release, its exact revision and reproducibility state are recorded. A proposal or unexecuted recipe is not a successful experiment.
Private repositories remain appropriate for infrastructure inventory, operator access, deployment secrets and raw captures containing private material. They must not be the only location of the implementation needed to reproduce a claimed public result. Evidence is exported through an explicit allowlist, not by publishing a whole private directory. Contributor access to research source and access to running machines are separate decisions.
The seed discussion set is RFC-0001 identity/messages, RFC-0002 bounded routing, RFC-0003 participation, RFC-0004 evaluation, RFC-0005 role separation and this RFC-0006 strict boot. All are drafts. Comments propose changes against a named revision, supply reasons or reproducible counterexamples, and retain attributed responses. The append-only project history records proposals, reviews, adoption, implementation and measurement separately.
Maintainers moderate spam, abuse, secrets and unsafe executable submissions; a removed sensitive detail is recorded without repeating it. Substantive disagreement remains visible and is resolved through reviewed changes and the project's declared approval process. Human Relcom ID sign-in, blog authorship, a GitHub comment and model output do not automatically grant a vote, network admission or a private credential. No automatic execution of contributed models or code follows from a comment or majority label.
10. Proof gates and rejection rules
G0 — Reproducible artifacts: publish pinned source/toolchain/image/model hashes, resolved configuration and complete commands. A configuration fragment alone is insufficient.
G1 — Whole guest OS: all IPv4/IPv6 stream and datagram probes fail as specified; raw Ethernet and Unix-local probes pass after boot and restart. No management or inference TCP socket inside the guest is permitted.
G2 — Link evidence: capture every experiment-facing link from boot, without an EtherType filter that would conceal unwanted traffic. The report enumerates EtherTypes and decodes any VLAN nesting. IPv4 (0x0800), ARP (0x0806), IPv6 (0x86DD) or other unaccounted encapsulation on these links fails the strict native-only gate. Completeness of the capture and the frame parser must be tested; a packet count of zero is not proof of working delivery.
G3 — Actual forwarding: a unique task travels A–R–B, R's two interfaces show the expected same task association, B processes it, and A receives the corresponding result. Removing R or its link prevents delivery; direct A–B communication has no physical or virtual wire. The four-node extension must independently demonstrate failover and bounded convergence.
G4 — Identity and trust: for the authenticated track, identity persists across reboot/NIC replacement, ownership and admission are checked separately, unknown/forged/replayed traffic is rejected, key storage contains no image-shared private key, and memory/CPU/state bounds hold under hostile discovery. A diagnostic CRC-only track is explicitly not tested for G4.
G5 — Agent task: an offline local model performs a real collaborative task over the native path, with task inputs, actual outputs, correctness rubric, failure cases and latency/resource accounting. A deterministic echo or document function is a useful earlier test, but it cannot satisfy this model-work gate.
G6 — Physical evidence: actual supported equipment, image hashes, connection diagram, boot-console record and complete physical-link captures reproduce the relevant virtual gates. A QEMU result cannot satisfy G6.
G7 — Useful comparison: compare native and ordinary IP implementations using equal endpoint/router resources, security properties, hop counts, model versions, workload and impairment schedule. The strict and IP configurations are separate images. Report total bytes/CPU, convergence, completion/deadlines, sustained goodput, tail latency and failures. No advantage is claimed until measurements support it; global Internet performance and adoption remain outside the first physical pilot.
This RFC is ready for comments as an initial experiment specification. Acceptance, implementation and successful measurement require their own versioned records.
11. Measured appendix — first strict guests, 2026-10-27
The initial whole-guest transport test has now executed in CI run 40500966557, source revision 90adf2c66cef042d0a663d0e34c097963f6b775d. This appendix supplements the earlier proposal without accepting the RFC or marking its remaining gates complete. The initial work-in-progress descriptions above record the design before this run.
Three actual QEMU Linux 6.12.50 guests A–R–B ran on one CI host, connected through two direct Unix-backed Ethernet links. INET, IPv6 and loadable modules were compiled out. Each scenario recorded 12 EAFNOSUPPORT results: IPv4/IPv6 stream and datagram probes on all three guests. AF_PACKET and AF_UNIX were available. This was not merely a normal IP-enabled OS with its addresses removed.
In the baseline, B computed SHA-256 for 16 distinct 1,024-byte tasks and A checked 16 correct results. All 90 frames in the two complete link captures were verified; the observed EtherType was only 0x88B5. The separate negative run stopped the only R after startup: zero of 16 tasks completed, with the expected timeout; all 10 captured frames were verified. This supports the absence of a hidden delivery bypass in the tested image and links. It does not demonstrate route repair: the next-hop table was fixed and there was no alternative path.
The XNS1 diagnostic used guest-generated Ed25519 keys, public-key-derived NodeIDs, signed HELLO/task/result frames and first-use bindings on the fixed links. Keys lived only in RAM. Origin signatures, CRCs and recipient associations were verified; mutable hop fields and the next-hop link are not fully authenticated by this diagnostic. It had no encryption, persistent identity or independently trusted admission. It is not a compatible version of the earlier encrypted mesh.
The local model and Unix-socket task interface in the diagram remain target work. AF_UNIX availability was probed, but no model or model-facing SDK task ran in these strict guests. The SHA-256 task is deterministic computation. Physical hardware, hostile admission, durable recovery, dynamic routing and an equal-budget IP efficiency comparison remain untested. The host/build Internet and operator trust remain disclosed.
Source/config/image hashes, receipts, full captures and console records are linked in the public measured summary. This run supplies bounded evidence toward G1–G3. It does not complete G4–G7 or prove bit-for-bit reproducibility of every host package. A subsequent change needs its own frozen revision, evidence and decision.
Measured readiness appendix — 2026-10-27
After explicit owner approval of infrastructure PR760, read-only run40535896278 confirmed that the existing A/B/R guests currently occupy three different cluster nodes and that A/B have identical pinned local model weights. Both expose a KVM device and a CPU virtualization flag. The current kernel supports kexec, but its user-space tool is absent. No package, boot, service, power or network changed. The sanitized aggregate keeps raw inventory private. This is operator-collected readiness, not strict-OS LLM execution, verified nested acceleration or an IP performance comparison.
The next proposed path is a separately reviewed strict guest on each of the already allocated hosts, with in-process offline inference and actual native Ethernet between machines. A local Unix virtual-NIC adapter may connect a strict guest to the existing Ethernet NIC; no cross-machine TCP/UDP backend or inference proxy qualifies. The complete guest links, adapter boundary and physical native frames must be associated by their actual bytes. Management in the surrounding host OS remains IP and must stay explicit. No such adapter or multi-host strict model run is established by this readiness appendix.