Status: Entwurfsvorschlag, 2026-10-27. Experimentelles IPvX-Projektdokument; kein IETF-RFC. Nicht ratifiziert und keine Behauptung bereitgestellter Hardware oder eines global interoperablen Protokolls.
Ursprung: Der Eigentümer präzisierte als nächstes Ziel ein vollständiges teilnehmendes Knotenbetriebssystem ohne TCP/IP, mit gewöhnlichen physischen Geräten, eigener Entdeckung und tatsächlichen Ethernet-Frames. Dies geht über die bisherige Aussage zur nativen Aufgabenzustellung im Labor hinaus. Dieses Dokument schlägt die Grenzen und Nachweisfreigaben für dieses Ziel vor.
1. Drei Nachweisebenen
Das bestehende Labor mit fünf VMs sendet Aufgaben und Routenankündigungen in nativen Ethernet-Frames, aber seine Knotenbetriebssysteme unterstützen weiterhin Verwaltungs-IP. Es verwendet eine feste zugelassene Mitgliederliste mit höchstens 16 Mitgliedern, vier Nachbarn und sieben Aufgaben-Hops. Seine Nachweise müssen diese Beschreibung beibehalten.
Der nächste strikte virtuelle Knoten hat einen Kernel ohne IPv4/TCP/IP- oder IPv6-Unterstützung. Er startet von lokalen Images, verwendet natives Ethernet für Nachrichten zwischen Knoten und einen lokalen Unix-Socket oder eine prozessinterne Schnittstelle für seinen Agenten. Seine serielle/Hypervisor-Konsole liegt außerhalb des Gastnetzes. Dies beweist eine OS- und Protokollausführungsgrenze, keine Herstellung oder Leistung auf physischer Hardware.
Der spätere strikte physische Knoten führt das geprüfte Image auf einem gewöhnlichen Computer mit unterstützten Ethernet-NICs aus. Er startet von lokalem Speicher und wird über eine lokale serielle/USB-Konsole verwaltet. Separate Firmware, NIC-Verwaltungsengines und vorhandene BMCs müssen geprüft oder deaktiviert werden, bevor behauptet wird, das gesamte physische Gerät habe keinen autonomen IP-Verkehr. Ein IP-fähiger Hypervisor oder eine externe Bedienkonsole werden offengelegt; sie sind kein IP-Pfad innerhalb des strikten Knotens.
Keine Stufe bedeutet, dass öffentliche Website, Quelldownloads, Buildmaschinen oder die übrige Welt IP aufgeben. Kein IP-Tunnel zwischen Standorten gilt unter diesem RFC als native physische Verbindung.
2. Physisches Netz weiterverwenden, Netzprotokoll ersetzen
Der erste Geräteentwurf verwendet Linux-Scheduling, Speicher, Gerätetreiber und Ethernet-PHY/MAC-Hardware weiter. Er benötigt weder Spezialchips noch ein eigenes OS oder einen neuen Kabelstandard. Ein gewöhnlicher Ethernet-Switch kann Frames weiterleiten, ohne IP-Router zu sein; der Pilot muss prüfen, dass ausgewählte Geräte die experimentellen Frames passieren lassen und keine unerwartete Gateway- oder Controllerabhängigkeit einführen.
MAC-Adressen sind Kanallokatoren, keine AgentIDs oder Eigentumsnachweise. Ein NIC-Austausch oder eine andere erlaubte lokale MAC darf keinen neuen logischen Agenten erzeugen. Die Verwaltungs-IP eines Switches liegt, sofern vorhanden, außerhalb seiner Weiterleitungsfunktion und außerhalb der strikten Endpunkt-OS; ein unverwalteter isolierter Switch oder direkte Kabel liefern einen klareren ersten Test. Gemeinsames Büro-Ethernet ist kein zulässiges erstes Experimentsegment.
Jeder native Router empfängt auf einem zugelassenen Kanal einen Frame, trifft die IPvX-Weiterleitungsentscheidung und sendet einen neuen Ethernet-Frame an seinen nächsten Nachbarn. Die Ziel-MAC ändert sich am nativen Router, die Ende-zu-Ende-AgentID nicht. Eine Linux-Bridge über sämtliche NICs würde die Routingfrage verdecken; der Routerprototyp darf seine Schnittstellen daher nicht bridgen oder IP-Weiterleitung aktivieren.
0x88B5 bleibt ein lokaler experimenteller EtherType für den isolierten Pilot. Es ist weder eine zugewiesene Produktionskennung für IPvX noch eine IANA-Protokollnummernvergabe. Die Ethernet-Konstanten von Linux kennzeichnen ihn für lokale experimentelle Nutzung. Produktionskennung und Koexistenz benötigen eine separate Standardisierungsentscheidung.
3. Profil des strikten Knotenbetriebssystems
Die vorgeschlagene aufgelöste Kernelkonfiguration erfordert CONFIG_NET=y, CONFIG_PACKET=y und CONFIG_UNIX=y, wobei CONFIG_INET und CONFIG_IPV6 nicht gesetzt ist. Der gewählte NIC-Treiber und die Unterstützung für Offline-Boot/Speicher/Konsole müssen ins Image eingebaut oder als gepinnte lokale Module enthalten sein. Konfigurationszusicherungen werden nach der Abhängigkeitsauflösung geprüft, nicht nur im Eingabefragment.
Linux-Netzwerk-Kconfig trennt die Internetprotokollunterstützung von Paket-Sockets. Die Kernel-Dokumentation zu Paket-Sockets beschreibt direkten Kanalzugriff. Dies sind vorgeschlagene Implementierungsprimitive; sie implementieren allein weder IPvX-Identität noch zuverlässige Zustellung oder sicheres Routing.
Laufzeitproben müssen zeigen, dass sowohl Stream- als auch Datagramm-Erzeugung für AF_INET und AF_INET6 mit dem dokumentierten Ergebnis einer nicht unterstützten Adressfamilie fehlschlagen. Positive Proben müssen zeigen, dass AF_PACKET und AF_UNIX funktionieren. Das Nachweispaket enthält exakte Kernelquellrevision, aufgelöste Konfiguration, Image-Hashes, Bootprotokoll, Proben und vollständige Mitschnitte jedes experimentseitigen Kanals ab vor der Gastausführung.
Dies entfernt die Internetprotokollimplementierung des Kernels; es ist kein formaler Beweis, dass beliebige Software kein IP im Userspace über rohes Ethernet implementieren könnte. Geprüftes Image, Daemonprotokoll, Fehlen eines Userspace-IP-Helfers und vollständig beobachteter Verkehr sind weitere Bestandteile der strikten Aussage. Ungenutzte internetbezogene Routinen einer Allzweckbibliothek dürfen nicht mit einem funktionierenden IP-Zustellpfad verwechselt werden; ein neuer ungeprüfter Helfer macht die Image-Abnahme bis zur Nachprüfung ungültig.
Das strikte Image enthält keinen Netzinstaller, DHCP-Client, DNS-Bootstrap, NTP-Abhängigkeit, SSH-Listener, HTTP-Inferenzserver oder Paketdownload beim Erststart. Auch Loopback-TCP ist nicht verfügbar. Agenten verwenden Unix-Sockets oder eine direkt eingebundene Modelllaufzeit. Versucht eine Abhängigkeit einen Internet-Socket zu öffnen, muss die strikte Aufgabe sichtbar scheitern; kein Host-HTTP-Proxy oder verstecktes Inferenzgateway darf sie erfolgreich machen.
4. Start und Identitätserzeugung
- Der Betreiber erstellt auf einer separaten Buildmaschine ein versionsgebundenes Image und für einen Modellversuch exakte lokale Modellgewichte. Alle Hashes, Patches und Lizenzen werden protokolliert. Diese Vorbereitung darf das Internet nutzen und wird nicht als native Übertragung dargestellt.
- Das Gerät startet lokalen Speicher. Sein Netzwerkdaemon wartet auf eine funktionierende kryptografische Zufallsquelle; er darf sie nicht durch Zeitstempel, MAC, gemeinsamen Image-Seed oder fest codierten privaten Schlüssel ersetzen.
- Bei der Erstinitialisierung erzeugt der Endpunkt seine privaten Identitätsschlüssel lokal und speichert sie anschließend in einem geschützten Zustandsverzeichnis oder geeigneten hardwaregestützten Schlüsselspeicher. Öffentliche Images enthalten keinen privaten Endpunktschlüssel. Ein TPM ist ein optionaler Speichermechanismus, dessen Integration noch implementiert und getestet werden muss; er wird nicht auf jeder Pilotmaschine vorausgesetzt.
- Das Gerät zeigt oder exportiert seinen öffentlichen Fingerabdruck über die lokale Konsole. Der Betreiber kann ihn außerhalb des Netzes zulassen. Neustarts erhalten die ID; bewusste Neuinitialisierung erzeugt eine neue Identität und wird protokolliert.
- Der Daemon entdeckt Kanalnachbarn und baut ausschließlich erlaubte Beziehungen auf. Weder öffentliche Domainauflösung noch ein zentraler Adressvergabeantrag gehören zu dieser Abfolge.
Das bestehende Labor leitet seine textuelle Agentenkennung von einem öffentlichen Signaturschlüssel ab. Ein künftiger NodeID-/AgentID-Namensraum und seine Algorithmusversion müssen mit Testvektoren spezifiziert werden, bevor Drahtkompatibilität behauptet wird. Eine NodeID bezeichnet einen Weiterleitungsteilnehmer; eine AgentID bezeichnet einen Akteur, der umziehen, mit anderen Agenten koexistieren oder mehrere Anschlüsse haben kann. Ein Anschluss ordnet eine erlaubte AgentID einem aktuellen Knoten und lokalen Kanal zu. Zufällige flache Kennungen codieren keine Routen und aggregieren sich nicht automatisch zu einer globalen Weiterleitungstabelle.
5. Native Nachbarentdeckung und Zulassung
Der angestrebte authentifizierte Bootstrap ist ein Vorschlag, kein implementiertes Merkmal des aktuellen Labors mit fester Mitgliederliste:
- Eine Schnittstelle sendet einen kleinen versionierten nativen
HELLOFrame als Kanalbroadcast oder an eine separat spezifizierte lokale Entdeckungsadresse. Er enthält keine Aufgabennutzlast und Router leiten ihn nicht über diesen Kanal hinaus weiter. - Die Antwort enthält eine frische Challenge. Die Peers binden Protokoll/Version, Rolle, öffentliche Identität, beide Nonces, Kanalkontext und relevante Fähigkeiten in einen authentifizierten Austausch ein. Exaktes Transkript, kanonische Codierung und Domänentrennung benötigen geprüfte Vektoren; eine bloße wiederverwendbare signierte Ankündigung reicht nicht aus, um Replay zu verhindern oder eine neue Sitzung zu binden.
- Jeder Peer prüft die Konsistenz von öffentlichem Schlüssel und ID sowie den Nachweis der Schlüsselkontrolle. Er wendet unabhängig seine außerhalb des Netzes bereitgestellten Zulassungspins oder eine ausdrücklich vertraute begrenzte Richtlinie an. Entdeckung ist keine Weiterleitungserlaubnis, Mitgliedschaft keine physische Erreichbarkeit und eine gültige Signatur kein Ehrlichkeitsnachweis.
- Erst nach Zulassung darf der Nachbar Routenankündigungen oder Aufgaben austauschen. Unbekannte Knoten verbleiben in einem kleinen, verfallenden, ratenbegrenzten Wartezustand oder werden zurückgewiesen. Der Betreiber kann sie lokal prüfen; offene Einschreibung ist nicht der Standard.
Ein Angreifer kann viele gültige Schlüssel erzeugen. Dieser Entwurf löst Sybil-Angriffe weder durch Hashen eines Schlüssels noch durch ein Blockchain-Etikett oder eine LLM-Abfrage. Nachbargrenzen, begrenzter Wartezustand, Framegrößenprüfung, Ratenlimits je Kanal/Identität und ausdrückliche Zulassung sind für den ersten authentifizierten Test erforderlich. Fehlerhafter oder versionsinkompatibler Verkehr muss begrenzt und ohne Verstärkung behandelt werden.
Frische darf nicht stillschweigend von über IP geholter Netzzeit abhängen. Anfangs-Challenges verwenden Zufall und lokale monotone Fristen. Persistente Sequenzuntergrenzen oder Boot-Epochen brauchen einen Absturz-/Replay-Entwurf. Befristete signierte Zugangsdaten benötigen eine dokumentierte vertrauenswürdige Wanduhrquelle oder müssen bei deren Ausfall sicher abgewiesen werden. Batteriegepufferte Uhr, bereitgestellte lokale Zeit oder signierter nativer Zeitdienst haben unterschiedliche Vertrauensannahmen; nichts davon gilt hier als gelöst.
6. Aufgaben von Weiterleitung und Transport
Native Kanäle kündigen zugelassene Knotenerreichbarkeit an. Die erste Topologie ist absichtlich klein. Der Vorschlag aus RFC-0005, Zugangsanschluss von aggregierter Erreichbarkeit zwischen Routern zu trennen, bleibt Forschung; dieser RFC verspricht kein globales Routing flacher IDs.
Jeder Datenframe braucht eine geprüfte Version, Nachrichtenart, begrenzte Länge, relevante Sender-/Empfängerkennungen, Nachrichten-/Sequenzzuordnung und Hop-Grenze. Parser müssen explizite Byte-Reihenfolge verwenden und inkonsistente Längen, unbekannte kritische Felder, ungültige Authentifizierung sowie aufgebrauchte Hop-Budgets vor unbegrenzter Speicherzuweisung zurückweisen. Ende-zu-Ende-Aufgabenverschlüsselung, Hop-/Sitzungsauthentifizierung und Bestätigungsbedeutungen bleiben getrennt.
Erste Tests sollten Nutzlasten unterhalb der erklärten Ethernet-MTU verwenden. Größere Nachrichten benötigen ausdrücklich begrenzte Fragmentierung, Zusammenbaufristen und Quoten, authentifizierte Zuordnung und Verlustbehandlung. Wiederholungen, Bestätigungen, Rückstaukontrolle, Überlastungssteuerung, Fairness und dauerhafte Anwendungsidempotenz werden nicht durch Ethernet oder eine Prüfsumme ersetzt. Das Fehlen von TCP erzeugt diese Implementierungspflichten; es belegt keine höhere Geschwindigkeit.
Dedizierte Router können diese Kosten von der Modellausführung fernhalten, wie in RFC-0005 vorgeschlagen. Kein Miner, verpflichtender globaler Validator, keine Blockchain-Finalität oder Modellinferenz wird in den Paketpfad eingefügt. Begrenzte Attestierungen sind optionale Steuerungsebenenforschung mit ausdrücklichen Ausfallkosten.
7. Zwei nicht zu verwechselnde Prototyppfade
Smoke-Test einer strikten OS: Ein kleiner C- oder Rust-Daemon kann zuerst Start ohne Internet-Socket-Familien, Kanalentdeckung, deterministischen Aufgabentransfer und Weiterleitung über einen Router mit mehreren NICs demonstrieren. Verwendet er einen reinen Testheader wie XNS1, statische Knotenbezeichnungen und CRC, muss der Bericht angeben, dass Authentifizierung, Verschlüsselung, sichere Entdeckung, Produktionsinteroperabilität und echte Modellarbeit fehlen. CRC erkennt zufällige Beschädigung; sie schützt nicht gegen bösartige Sender. Diese isolierte Diagnose ersetzt das authentifizierte Laborprotokoll nicht.
Der parallele Implementierungsbeitrag beschrieb eine beabsichtigte stärkere XNS1 Diagnose: lokal erzeugte Ed25519-Schlüssel, aus dem öffentlichen Schlüssel abgeleitete NodeID, signierte HELLO-/Aufgaben-/Ergebnisdatensätze und Vertrauen beim Erstkontakt auf festen isolierten Kanälen. Diese Richtung kann Schlüsselkontrolle nach Erstkontakt testen, authentifiziert aber den ersten Kontakt nicht gegen einen unabhängigen Vertrauensanker, begründet keine Projektzulassung und erhält ohne persistente Speicherung keine Identität über Neustarts. Statische Bezeichnungen A/R/B würden Platzierung beschreiben, nicht Identität. Dies ist eine zugeordnete Beschreibung laufender Arbeit; eine Quellrevision und ein erfolgreicher strikter Gastlauf sind weiterhin erforderlich, bevor implementierte Nachweise behauptet werden.
Authentifizierter nativer Stack: Später werden Diagnosebezeichnungen und Prüfsummen als Vertrauensmechanismen durch die spezifizierte lokale Identität, Zulassung, authentifizierte Nachbarsitzungen, Aufgabenumschläge und geprüfte Zustellsemantik ersetzt. Portieren oder Wiederverwenden des vorhandenen Laborcodes belegt dessen Lauf im strikten Image erst, wenn strikte Proben und Abhängigkeitsaudit tatsächlich bestanden sind.
Ein minimales Initramfs und ein kompilierter Diagnosedaemon machen den ersten Nachweis kostengünstig. Eine Python-Laufzeit kann offline für Kompatibilität mitgeführt werden; ihre Eignung für das kleine Image oder Freiheit von Internet-Socket-Abhängigkeiten darf nicht vorausgesetzt werden. Die spätere LLM-Stufe lädt lokale Gewichte und ruft Inferenz prozessintern oder über AF_UNIXauf; sie berichtet Modellzeit getrennt von Netzzeit.
8. Virtuelle Leitungen und physischer Prototyp
Die erste ausführbare virtuelle Topologie kann A–R–B sein: A und B haben jeweils eine virtuelle NIC, R zwei, ohne A–B-Verbindung. Eine Diamanttopologie mit vier Gästen A–R1–B und A–R2–B ergänzt eine echte Alternativroute; A und B benötigen dann zwei getrennte Schnittstellen. Drei Gäste allein demonstrieren kein Routen-Failover.
Virtuelle QEMU-Ethernet-Leitungen verwenden direkte Unix-Domain-Stream-Verbindungen zwischen QEMU-Instanzen. QEMU dokumentiert Unix-Stream-Backend und Paketdump-Filter. Gewählte Befehlszeile und QEMU-Revision müssen aufgezeichnet und auf das Fehlen einer impliziten Standard-User-Netzwerk-NIC geprüft werden. Ein an passt angeschlossener Unix-Socket ist ausgeschlossen: Er würde einen IP-Stack-Helfer einführen. TCP/UDP-Socket-Backends, SLIRP/User Networking, IP-Tunnel und ein Hostdienst, der die Aufgabennutzlast transportiert, sind ausgeschlossen.
Der virtuelle Host darf für seine Verwaltung IP behalten. Die Aussage lautet, dass strikte Gäste und ihre virtuellen Ethernet-Leitungen es nicht verwenden. Dies ist enger als eine physische Bereitstellung und muss entsprechend bezeichnet werden.
Für physisches A–R–B zwei gewöhnliche Endpunkt-PCs mit je einem unterstützten Ethernet-Port und einen Router-PC mit zwei unterstützten Ports verwenden. A direkt mit Rs erstem Port und B mit seinem zweiten verbinden. Software und Mitschnitt je Kanal müssen den Ein-/Ausgangsbezug zeigen. Eine spätere redundante physische Topologie benötigt zusätzliche Ports und Kabel oder eine separat dokumentierte Switch-/Segmentanordnung; ein gemeinsamer Switch allein darf keinen versteckten direkten A–B-Bypass ermöglichen. Dieser Entwurf genehmigt weder Kauf noch Änderungen vorhandener Infrastruktur.
9. Öffentliche Forschung, privater Betrieb und Diskussion
Das öffentliche Forschungsrepository sollte RFCs, geprüfte Referenzquellen, Schemata und Vektoren, Rezepte für strikte Images, synthetische Fixtures, öffentliche Sicherheitsgrenzen und bereinigte Versuchsnachweise enthalten. Vor einer Freigabe werden exakte Revision und Reproduzierbarkeitsstand protokolliert. Ein Vorschlag oder unausgeführtes Rezept ist kein erfolgreicher Versuch.
Private Repositories bleiben für Infrastrukturinventar, Betreiberzugriff, Bereitstellungsgeheimnisse und Rohmitschnitte mit privaten Inhalten angemessen. Sie dürfen nicht der einzige Ort der Implementierung sein, die zur Reproduktion eines behaupteten öffentlichen Ergebnisses nötig ist. Nachweise werden über eine ausdrückliche Positivliste exportiert, nicht durch Veröffentlichung eines ganzen privaten Verzeichnisses. Zugang zum Forschungsquellcode und zu laufenden Maschinen sind getrennte Entscheidungen.
Die anfänglichen Diskussionstexte sind RFC-0001 Identität/Nachrichten, RFC-0002 begrenztes Routing, RFC-0003 Teilnahme, RFC-0004 Bewertung, RFC-0005 Rollentrennung und dieser RFC-0006 strikter Start. Alle sind Entwürfe. Kommentare schlagen Änderungen gegen eine benannte Revision vor, liefern Gründe oder reproduzierbare Gegenbeispiele und erhalten zugeordnete Antworten. Die append-only Projektgeschichte hält Vorschläge, Prüfungen, Annahme, Implementierung und Messung getrennt fest.
Maintainer moderieren Spam, Missbrauch, Geheimnisse und unsichere ausführbare Einreichungen; entfernte sensible Details werden protokolliert, ohne sie zu wiederholen. Sachliche Meinungsverschiedenheiten bleiben sichtbar und werden über geprüfte Änderungen und den erklärten Projektgenehmigungsprozess gelöst. Menschliche Relcom-ID-Anmeldung, Blogautorenschaft, GitHub-Kommentar und Modellausgabe gewähren nicht automatisch Stimme, Netzzulassung oder private Zugangsdaten. Aus Kommentar oder Mehrheitskennzeichnung folgt keine automatische Ausführung beigetragener Modelle oder Codes.
10. Nachweisfreigaben und Ablehnungsregeln
G0 — Reproduzierbare Artefakte: Gepinnte Quell-/Toolchain-/Image-/Modell-Hashes, aufgelöste Konfiguration und vollständige Befehle veröffentlichen. Ein Konfigurationsfragment allein reicht nicht.
G1 — Vollständiges Gastbetriebssystem: Alle IPv4/IPv6-Stream- und Datagrammproben schlagen wie spezifiziert fehl; Raw-Ethernet- und lokale Unix-Proben bestehen nach Start und Neustart. Kein Verwaltungs- oder Inferenz-TCP-Socket innerhalb des Gasts ist erlaubt.
G2 — Kanalnachweise: Jeden experimentseitigen Kanal ab dem Start mitschneiden, ohne EtherType-Filter, der unerwünschten Verkehr verbergen könnte. Der Bericht zählt EtherTypes auf und decodiert jede VLAN-Verschachtelung. IPv4 (0x0800), ARP (0x0806), IPv6 (0x86DD) oder andere nicht erklärte Kapselung auf diesen Kanälen lässt die strikte Nur-nativ-Freigabe scheitern. Vollständigkeit des Mitschnitts und Frameparser müssen getestet werden; null Pakete beweisen keine funktionierende Zustellung.
G3 — Tatsächliche Weiterleitung: Eine eindeutige Aufgabe läuft A–R–B, Rs zwei Schnittstellen zeigen die erwartete Zuordnung derselben Aufgabe, B verarbeitet sie und A empfängt das entsprechende Ergebnis. Entfernen von R oder seinem Kanal verhindert Zustellung; für direkten A–B-Austausch existiert keine physische oder virtuelle Leitung. Die Erweiterung mit vier Knoten muss Failover und begrenzte Konvergenz unabhängig demonstrieren.
G4 — Identität und Vertrauen: Im authentifizierten Pfad überlebt die Identität Neustart/NIC-Austausch, Besitz und Zulassung werden getrennt geprüft, unbekannter/gefälschter/wiederholter Verkehr wird verworfen, der Schlüsselspeicher enthält keinen gemeinsam im Image enthaltenen privaten Schlüssel und Speicher-/CPU-/Zustandsgrenzen halten feindlicher Entdeckung stand. Ein reiner CRC-Diagnosepfad wird ausdrücklich nicht auf G4 geprüft.
G5 — Agentenaufgabe: Ein lokales Offline-Modell führt eine echte gemeinsame Aufgabe über den nativen Pfad aus, mit Aufgabeneingaben, tatsächlichen Ausgaben, Korrektheitsschema, Fehlerfällen sowie Latenz-/Ressourcenabrechnung. Deterministisches Echo oder eine Dokumentfunktion sind nützliche frühere Tests, können diese Modellarbeitsfreigabe jedoch nicht erfüllen.
G6 — Physische Nachweise: Tatsächliche unterstützte Geräte, Image-Hashes, Anschlussdiagramm, Bootkonsolenprotokoll und vollständige Mitschnitte physischer Kanäle reproduzieren die relevanten virtuellen Freigaben. Ein QEMU-Ergebnis erfüllt G6 nicht.
G7 — Nützlicher Vergleich: Native und gewöhnliche IP-Implementierungen mit gleichen Endpunkt-/Routerressourcen, Sicherheitseigenschaften, Hop-Zahlen, Modellversionen, Lasten und Störplänen vergleichen. Strikte und IP-Konfigurationen sind separate Images. Gesamtbytes/CPU, Konvergenz, Abschluss/Fristen, dauerhaften Nutzdatendurchsatz, Randlatenz und Fehler berichten. Kein Vorteil wird behauptet, bevor Messungen ihn stützen; globale Internetleistung und Einführung liegen außerhalb des ersten physischen Piloten.
Dieser RFC ist als erste Experimentspezifikation bereit für Kommentare. Annahme, Implementierung und erfolgreiche Messung benötigen eigene versionierte Aufzeichnungen.
11. Gemessener Anhang — erste strikte Gäste, 2026-10-27
Der erste vollständige Gasttransporttest wurde nun ausgeführt in CI-Lauf 40500966557, Quellrevision 90adf2c66cef042d0a663d0e34c097963f6b775d. Dieser Anhang ergänzt den früheren Vorschlag, ohne den RFC anzunehmen oder seine übrigen Freigaben abzuschließen. Die obigen Beschreibungen laufender Arbeit dokumentieren den Entwurf vor diesem Lauf.
Drei tatsächliche QEMU-Linux-6.12.50-Gäste A–R–B liefen auf einem CI-Host, verbunden durch zwei direkte Unix-basierte Ethernet-Kanäle. INET, IPv6 und ladbare Module waren auskompiliert. Jedes Szenario protokollierte 12 EAFNOSUPPORT Ergebnisse: IPv4/IPv6-Stream- und Datagrammproben auf allen drei Gästen. AF_PACKET und AF_UNIX waren verfügbar. Dies war nicht bloß eine gewöhnliche IP-fähige OS mit entfernten Adressen.
Im Basislauf berechnete B SHA-256 für 16 unterschiedliche Aufgaben mit je 1 024 Bytes und A prüfte 16 korrekte Ergebnisse. Alle 90 Frames der zwei vollständigen Kanalmitschnitte wurden geprüft; beobachtet wurde ausschließlich der EtherType 0x88B5. Der separate negative Lauf stoppte den einzigen R nach dem Start: Null von 16 Aufgaben wurden abgeschlossen, mit erwartetem Timeout; alle 10 aufgezeichneten Frames wurden geprüft. Dies stützt das Fehlen eines versteckten Zustellbypasses in geprüftem Image und Kanälen. Es demonstriert keine Routenreparatur: Die Next-Hop-Tabelle war fest und es gab keinen Alternativpfad.
Die XNS1-Diagnose verwendete im Gast erzeugte Ed25519-Schlüssel, aus öffentlichen Schlüsseln abgeleitete NodeIDs, signierte HELLO-/Aufgaben-/Ergebnisframes und Erstkontaktbindungen auf festen Kanälen. Schlüssel lebten nur im RAM. Ursprungssignaturen, CRCs und Empfängerzuordnungen wurden geprüft; veränderliche Hop-Felder und der Next-Hop-Kanal sind durch diese Diagnose nicht vollständig authentifiziert. Es gab weder Verschlüsselung noch persistente Identität oder unabhängig vertraute Zulassung. Sie ist keine kompatible Version des früheren verschlüsselten Meshs.
Das lokale Modell und die Unix-Socket-Aufgabenschnittstelle im Diagramm bleiben Zielarbeit. AF_UNIX-Verfügbarkeit wurde geprüft, aber in diesen strikten Gästen lief weder ein Modell noch eine modellseitige SDK-Aufgabe. Die SHA-256-Aufgabe ist deterministische Berechnung. Physische Hardware, feindliche Zulassung, dauerhafte Wiederherstellung, dynamisches Routing und ein IP-Effizienzvergleich bei gleichem Budget bleiben ungeprüft. Internetnutzung durch Host/Build und Betreibervertrauen bleiben offengelegt.
Quell-/Konfigurations-/Image-Hashes, Bestätigungen, vollständige Mitschnitte und Konsolenprotokolle sind verlinkt in der öffentlichen gemessenen Zusammenfassung. Dieser Lauf liefert begrenzte Nachweise zu G1–G3. Er erfüllt G4–G7 nicht und beweist keine bytegenaue Reproduzierbarkeit jedes Hostpakets. Eine Folgeänderung benötigt eine eigene eingefrorene Revision, Nachweise und Entscheidung.
Anhang zur gemessenen Bereitschaft — 2026-10-27
Nach ausdrücklicher Eigentümergenehmigung von Infrastruktur-PR760 bestätigte der Nur-Lese-Lauf40535896278, dass die bestehenden A/B/R-Gäste aktuell drei unterschiedliche Clusterknoten belegen und A/B identische gepinnte lokale Modellgewichte besitzen. Beide zeigen ein KVM-Gerät und ein CPU-Virtualisierungsflag. Der aktuelle Kernel unterstützt kexec, das Userspace-Werkzeug fehlt jedoch. Kein Paket, Startvorgang, Dienst, Energie- oder Netzzustand wurde geändert. Das bereinigte Aggregat hält Rohinventar privat. Dies ist vom Betreiber erhobene Bereitschaft, keine strikte OS-LLM-Ausführung, verifizierte verschachtelte Beschleunigung oder IP-Leistungsvergleich.
Als nächster Pfad wird ein separat geprüfter strikter Gast auf jedem bereits zugewiesenen Host vorgeschlagen, mit prozessinterner Offline-Inferenz und tatsächlichem nativem Ethernet zwischen Maschinen. Ein lokaler Unix-Adapter für die virtuelle NIC kann den strikten Gast an die bestehende Ethernet-NIC anschließen; kein maschinenübergreifendes TCP/UDP-Backend oder Inferenzproxy gilt dafür. Vollständige Gastkanäle, Adaptergrenze und physische native Frames müssen anhand ihrer tatsächlichen Bytes zugeordnet werden. Die Verwaltung in der äußeren Host-OS bleibt IP-basiert und muss ausdrücklich sichtbar bleiben. Dieser Bereitschaftsanhang belegt keinen solchen Adapter oder strikten Modelllauf über mehrere Hosts.
Originaldokument
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.