FD&F: the network built from shared state.
Farinacci, Day & Fawcett combines RINA’s names and scope, LISP’s separation of identity from location, and Network Shared RAM. The result is a network whose members publish the facts from which its shape is derived.
The network is one of the applications.
The hybrid grew out of converting lispers.net and RINA to the shared-memory programming model. It is an implementation built from those ideas and algorithms. It does not claim that unmodified LISP and RINA stacks were merely connected together.
Network Shared RAM remains the programming proposition. FD&F shows that network construction itself can use it: publish current truth, derive the plan, apply your part, and repeat when the state changes.
| Component | Owns | Published or consumed contract |
|---|---|---|
| RINA lineage | Names, scope, enrollment and scoped relationships | A named pond and its membership context. |
| LISP lineage | Identity separated from location; mapping concepts | Identity resolution and signed mappings in the hybrid implementation. |
| Ribbit / RAM manager | Shared state, member sessions and region operations | Participants, facts, mappings, world and event watches. |
| fdf-facts + fdf-client | A node’s own observations and publication | Addresses, DHCP lease pairs, uplink and tunnel facts, capability and generation. |
| fdf_graph + FrogNet daemon | Derived topology and local application of the plan | Routes, defaults, names, elections and the node’s announced plan state. |
| fdf-hub | Packet relay and present peer configuration | WireGuard allowed-ips from the graph and verified mappings. |
| Windows / Android bridge | Device membership, placement, reach and aliases | One session per pond; a forward pond; one packet device per reached scope. |
One world read, then the local plan.
Each node publishes its own facts. The region’s world operation returns participants and mappings together. A watch is registered before the initial world read, so a join during startup cannot disappear in a gap between read and watch.
Nodes run the same graph rules over the published rows. The daemon applies the slice for its own identity in-process. The hub computes the peers and allowed prefixes it needs now. It does not keep an absent participant parked as a remembered route.
In r19, member aliveness comes from the RAM session. Lease pairs supply LAN adjacency; the applier does not echo-probe a member that the region already identifies as alive. Hub usability still depends on the tunnel’s handshake, and loss of the region withdraws its routes, names and tunnels.
Several ponds on one device.
A device keeps a session to every configured pond. One pond is forward. Other ponds may permit reach under their own policy. Bringing a pond forward changes the announced roles on the open sessions and moves the forward path.
Each reached pond has its own packet device. The bridge maps overlapping private destinations to 1:1 aliases from 100.64.0.0/10. Its TUN address stays fixed; the address assigned by a pond is used on packets inside that pond. Reach is not an instruction to merge the address spaces.
Resolve by identity rather than by choosing a network in application code. Exactly one pond may answer. Two answers are refused and named as ambiguous. Released aliases are reserved for the same use during a 600-second quarantine.
Membership and packet carriage have different jobs.
A member connects out to the RAM manager. Shared RAM gives it membership and the information needed to construct its path. For an off-mesh device, the current bridge carries ordinary IP traffic through a WireGuard hub path. On Windows it uses Wintun; on Android it uses VpnService and protects the WireGuard sockets from the tunnel.
The application does not configure the tunnel’s address, key or peer. That is the useful difference demonstrated here. The implementation nevertheless uses WireGuard, a TUN, routing and a relay hub. “No VPN technology” would be an inaccurate description of the current packet path.
What has actually been exercised.
The r19-a14 acceptance record reports fdf-tun 20/20, reach 68/68, region-loop 20/20, graph 17/17, hub 25/25, leaf-tunnel 10/10 and placement 18/18. These are separate suites with their own topologies, not one total test count.
r19-a15 adds a red-first region-loop check that a runMerge does not remove leaf names from /etc/hosts. The October 12 Windows demo records membership, ping, SSH, the monitor and live topology map, plus a Windows–Android call. The observed call reports 1280×720 at 20 fps; the displayed receive rate is roughly 1.2–1.5 Mb/s.
Read the qualification boundaries →