Gastbetriebssystem ohne INET und IPv6
Lokales Modell
Modellaufruf im Agentenprozess
IPvX-Dienst · Eigener Schlüssel und eigene ID
So funktioniert das Netz
Die stabile ID beantwortet „an wen“. Die lokale Route beantwortet „über welchen Nachbarn“. Der physische Kanal beantwortet „wie wird der Frame übertragen“.
Aufbau des geprüften Versuchs
Drei Gastbetriebssysteme auf getrennten physischen Maschinen. Auf A und B laufen lokale Sprachmodelle; R1 leitet ihre Nachrichten weiter.
Forschungsdarstellung eines aufgezeichneten Versuchs. Kein Livebild; das Tempo der Animation ist illustrativ.
Modus: aufgezeichneter strict-LLM-Versuch · A–R1–B · 3 Gäste / 3 physische Hosts · 2 lokale Modelle.
Separates Live-Mesh: 5 VMs / 3 physische Hosts, ohne LLMs, mit Verwaltungs-IP im Betriebssystem. Beide übertragen native Daten und Routen über Ethernet 0x88B5; Webansicht und Verwaltung nutzen HTTPS/IP. Live-Mesh und dessen Version öffnen.
Gastbetriebssystem ohne INET und IPv6
Routingdienst
IPvX-Dienst · Eigener Schlüssel und eigene ID
Gastbetriebssystem ohne INET und IPv6
Lokales Modell
Modellaufruf im Agentenprozess
IPvX-Dienst · Eigener Schlüssel und eigene ID
Ethernet-Frames · EtherType 0x88B5
Externe Verwaltung, Start der virtuellen Maschinen und diese Website nutzen IP. Das gemeinsame physische Netz überträgt ebenfalls IP-Verwaltungsverkehr. Die native Zustellung innerhalb der Gastsysteme nutzt weder IP noch DNS.
A bereitet die Aufgabe vor
Modell A erstellt eine Antwort. Der IPvX-Dienst adressiert die Nachricht an die ID von B, signiert und verschlüsselt sie.
Anfrage über R1
A sendet einen Frame an Nachbar R1; R1 wählt den nächsten Übergang zu B. Eine Quittung bestätigt die Annahme, nicht die Richtigkeit.
B prüft und antwortet
Modell B erhält die Aufgabe und erstellt eine Rezension. Die Antwort reist als separate Nachricht über R1 zurück zu A.
A erstellt das Ergebnis
Modell A nutzt die Rezension für seine Antwort. Das Entscheidungsfeld stimmte bei zwei von vier Aufgaben mit der Referenz überein.
Was überprüft wurde
4 Aufgaben und 48 bestätigte Zustellungen im nativen Modus: 40 Echo-Prüfungen und 8 Aufgabennachrichten. Die IP-Kontrolle nutzte dieselben Anwendungsschritte.
Zeiten je Übergang, Wartezeit in der Queue und der Grund der Routenwahl fehlen in der öffentlichen Aufzeichnung. Die Animation misst sie nicht.
Externe Netze, offener Zugang, Routing in großem Maßstab und physische Bare-Metal-Server ohne IP bleiben separate ungeprüfte Ziele.
Codeversion des Versuchs: 643ddc695f9d
Aufgaben und Nachrichten untersuchen · Vorhandene und fehlende Daten
Vier unterschiedliche Ebenen
Identität
Der Knoten erzeugt seine Schlüssel selbst. Seine ID wird aus dem öffentlichen Schlüssel berechnet und bleibt bei einem Standortwechsel erhalten. Vertrauen und Zulassung werden getrennt festgelegt.
Aufgabe
Agenten tauschen strukturierte Aufgaben, Nachweise und Ergebnisse aus. Dafür benötigen sie keine Webseiten. Kompatible Aufgabenformate bleiben dennoch erforderlich.
Routing
Der Knoten empfängt signierte Ankündigungen seiner Nachbarn und wählt den nächsten Hop aus einer lokalen Tabelle. Der zentrale Beobachter überträgt keine Aufgaben und weist keine Routen zu.
Zustellung
Im nativen Experiment wird das Paket in Ethernet-Frames mit EtherType 0x88B5 umgesetzt. Die MAC-Adresse bezeichnet den Nachbarn auf dem lokalen Kanal; die ID bezeichnet den endgültigen Agenten.
Wo IP erhalten bleibt
Maschinenverwaltung, Modellinstallation und diese Website nutzen das bestehende Internet. Native Aufgaben und Routenankündigungen laufen im Experiment über ein separates Protokoll. Geprüft wird eine eigene Zustellungsebene in einem kontrollierten Ethernet-Segment.
Für unabhängige Standorte werden physische Kanäle oder eine ausdrücklich benannte Unterlage benötigt. Verbindet ein IP-Tunnel die Standorte, handelt es sich um IPvX über IP. Das kann nützlich sein, beweist aber keinen Verzicht auf IP im darunterliegenden Netz.
Was wir aus IPvX übernehmen
Selbst erzeugte Kennungen, die Trennung von Identität und Standort, verifizierbare Kontakte und verteilte Auflösung. Hinzu kommen ausdrückliche Zulassung, Ressourcengrenzen und messbare Zustellung. Menschenlesbare Namen bleiben optionale Aliasse und bilden keine Vertrauenswurzel.
Knoten ohne TCP/IP: überprüfter Versuch
Im abgeschlossenen Versuch liefen lokale Modelle in vollständigen Gastbetriebssystemen ohne INET und IPv6 auf unterschiedlichen physischen Hosts. Native Frames wurden über Ethernet übertragen; die Verwaltung der äußeren Maschinen verwendete weiterhin IP.
Ein physischer Bare-Metal-Server ohne IP und ein globales Netzwerk bleiben separate, ungeprüfte Ziele. Aufgabe und Prozesse untersuchen → · Geräteschema und RFC-0006-Entwurf →