Guest OS without INET or IPv6
Local model
Model called within agent process
IPvX service · Own key and ID
How the network works
A stable ID answers “to whom”. A local route answers “through which neighbor”. A physical link answers “how to transmit the frame”.
Inside the tested setup
Three guest operating systems on separate physical machines. A and B run local language models; R1 forwards their messages.
Research illustration of a recorded experiment. This is not a live feed; animation timing is illustrative.
Mode: recorded strict-LLM experiment · A–R1–B · 3 guests / 3 physical hosts · 2 local models.
Separate live mesh: 5 VMs / 3 physical hosts, without LLMs, with management IP in the OS. Both carry native data and routes over Ethernet 0x88B5; the web view and management use HTTPS/IP. Open the live mesh and its revision.
Guest OS without INET or IPv6
Routing service
IPvX service · Own key and ID
Guest OS without INET or IPv6
Local model
Model called within agent process
IPvX service · Own key and ID
Ethernet frames · EtherType 0x88B5
External management, virtual machine startup and this website use IP. The shared physical network also carries management IP traffic. Native delivery within the guest systems uses neither IP nor DNS.
A prepares the task
Model A prepares a response. The IPvX service addresses the message to B’s ID, signs and encrypts it.
Request travels through R1
A sends a frame to neighbor R1; R1 selects the next hop to B. A receipt confirms admission, not correctness.
B reviews and replies
Model B receives the task and produces a review. The reply travels as a separate message through R1 back to A.
A produces the final answer
Model A uses the review for its final answer. The decision field matched the reference in two of four tasks.
What was verified
4 tasks and 48 signed deliveries in native mode: 40 echo checks and 8 task messages. The IP control used the same application hops.
Per-hop timing, queue wait and the reason for route selection are absent from the public record. The animation does not measure them.
External networks, open admission, large-scale routing and bare-metal physical servers without IP remain separate untested goals.
Experiment code revision: 643ddc695f9d
Four separate layers
Identity
The node creates its own keys. Its ID is derived from the public key and persists when its network location changes. Trust and admission are configured separately.
Task
Agents exchange structured tasks, evidence and results. They do not need website pages for this. Compatible task formats are still necessary.
Routing
A node receives signed announcements from neighbors and selects the next hop from its local table. The central observer does not relay tasks or assign routes.
Delivery
In the native experiment, the packet becomes Ethernet frames with EtherType 0x88B5. The MAC identifies a neighbor on the local link; the ID identifies the final agent.
Where IP remains
Machine management, model installation and this website use the existing Internet. Native tasks and route announcements in the experiment use a separate protocol. This tests our own delivery layer in a controlled Ethernet segment.
Connecting independent sites requires physical links or an explicitly disclosed underlay. An IP tunnel between sites would carry IPvX over IP. That can be useful, but it would not demonstrate the removal of IP from the underlying network.
What we retain from IPvX
Self-generated identifiers, separation of identity from location, verifiable contacts and distributed resolution. We add explicit admission, resource bounds and measurable delivery. Human-friendly names remain optional aliases rather than the root of trust.
Node without TCP/IP: verified experiment
In the completed experiment, local models ran inside whole guest operating systems without INET and IPv6 on separate physical hosts. Native frames travelled over Ethernet while the outer machines retained IP management.
A bare-metal physical server without IP and a global network remain separate, untested objectives. Inspect the task and processes → · Device diagram and draft RFC-0006 →