F20-TS: Yes
Rationale
DERP forwards a SendPacket by its destination node public key through lookupDest and a shared client or mesh-forwarder table. It does not establish or look up a separate end-to-end flow or circuit. Multiple application flows and WireGuard sessions between the same nodes use the same node-reachability machinery. Direct paths use ordinary IP forwarding. This meets the transit-only criterion.
Assessment method
Pinned forwarding-code and state-key inventory; no runtime test
Source context
DERP lookupDest, handleFrameSendPacket, sendPacket, noteSendFromSrc and peer-departure watchers
Outstanding qualification
DERP is not stateless: client TLS connections, destination tables, queues and per-source/per-recipient peer-departure watchers remain. noteSendFromSrc records a source node once for a receiving client; it is aggregate node-presence bookkeeping, not a flow identifier, circuit binding or cryptographic circuit key. Creating additional application flows between those nodes does not create corresponding watcher entries. Endpoint WireGuard state is outside this transit test. Optional stateful IP middleboxes are not required by the selected composition. Pinned source analysis, not a runtime, memory-bound or global-scale certification.
Public sources
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round593.html
- round593-sources.json